Working with Large Values (double)

[Geoff]

Scale everything to mils and work accordingly.

Tell that to Intuit, the largest publisher of financial software on
the PC. They appear to be using float for their currency values.

 

[jacob navia]

Le 24/02/2014 16:57, Victor Bazarov a écrit :

All I see is ignorance so far.

Of course. You win. This discussion is finished.

 

[David Brown]

jacob navia schreef op 24-Feb-14 4:28 PM:

strcatMany( a, b, c );

gcc would solve that with:

extern int strcatMany(char *first, ...)
__attribute__((sentinel));

and compiling with -Wformat (or -Wall).

I don't know if lcc-win has such useful features.


(Personally, I prefer the C++ "overloaded +" syntax.)

 

[Ian Collins]

Le 24/02/2014 12:32, Juha Nieminen a écrit :

In C++ you have to overload the operator << as far as I remember. In C
you have to write a "Print_XXX" function. I do not see why C++ is so
fundamentally better.

How would you use Print_XXX in a class or function template? Even
outside of a template, being able to output the contents of an object
without having to look up each member's type is a bonus. Let the
compiler do the lookup and avoid the inevitable human errors.

As for the iostream formatting, yes, it is a mess!

But I am afraid you will never be convinced (of course). Do as you wish,
but stop denigrating other computer languages that can be used as
effectively as C++.

Since its birth, C++ tried to be the "better C", "C with classes"
whatever. That is why it is fundamental for them to denigrate C to
convince everyone that C++ is the "better way".

None of the C++ programmers I know "denigrate C". Most of them are also
C programmers would happily use C string formatting functions where
appropriate.

When I try to discuss a package I wrote ( a C containers library) in
comp.lang.c hordes of C++ people go there to "preach the good word" and
tell me that what I did (and run every day) is "impossible, I am lying C
can't do that" etc.

Care to quote one? I didn't see any. Constructive criticism for sure,
but nothing about you lying.

Just stop denigrating C.

Just stop interpreting all critical comments as personal attacks.

 

[Barry Schwarz]

No. Scientific notation, like pratically all other text
formats, is base 10. None of the floating point formats I know
of that are in use today are base 10. And the way machine
floating point typically represents the exponent is not
scientific notation either.

IBM has been and is still selling machines with decimal floating point
built into the hardware. In fact, they have three floating point
formats that the user can choose to use.

 

[jacob navia]

Le 24/02/2014 17:10, Martin Shobe a écrit :

Unintuitive, certainly.

Well that is the point

Overloading should help the reader better undrestand what the program is
doing.

When you can "add" two strings and an integer the reader must be forced
to understand what is being added. Obviously for many people here it is
SO OBVIOUS that this counterintuitive behavior is "normal" that they
can't understand even why someone from outside finds it disconcerting.

 

[jacob navia]

Le 24/02/2014 16:43, Wouter van Ooijen a écrit :

jacob navia schreef op 24-Feb-14 4:28 PM:

strcatMany( a, b, c );

actually
c = strcatMany(a,b,NULL);

Wouter van Ooijen

PS Jacob, why are you hanging out of a C++ forum?

I read it often, I am not a religious person that believes that because
I use (and like) C other languages are all bad. C++ is an interesting
language. What is a pity is that in these forums no real discussion (in
the sense of exchanging arguments, learning from each other's opinion)
seems possible since people here are very "religious" about "their"
language, as you would expect in a political forum.

 

[Victor Bazarov]

Le 24/02/2014 16:43, Wouter van Ooijen a écrit :

actually
c = strcatMany(a,b,NULL);

What Wouter wrote was to show you that to make a mistake using the
"preferred" form is just as easy as with the other form, and it's just
as _undiagnosable_.

While *printf functions are so common that some compilers now have a
mechanism to attempt argument matching and warn you in case you use the
wrong format specification, any other function that uses ellipsis is
*not* subjected to the same scrutiny and as such is an almost assured
source of hard to identify mistakes.

I read it often, I am not a religious person that believes that because
I use (and like) C other languages are all bad. C++ is an interesting
language. What is a pity is that in these forums no real discussion (in
the sense of exchanging arguments, learning from each other's opinion)
seems possible since people here are very "religious" about "their"
language, as you would expect in a political forum.

V

 

[jacob navia]

Le 24/02/2014 21:40, Victor Bazarov a écrit :

What Wouter wrote was to show you that to make a mistake using the
"preferred" form is just as easy as with the other form, and it's just
as _undiagnosable_.

Yes.

There is no way to specify a list of arguments of the same type in C (or
in C++ for that matter).

So, that could crash.

Contrary to what many people here believe, I do not think that a trivial
error like that is very difficult to solve/fix/find.

Yes, it is a PITA, as all bugs, but not as bad as MANY other bugs that
can happen also with the overloaded functions. For instance typing a
wrong variable name in a function call, etc. The compiler can warn you
if the type is wrong, but if it is right that is also

_undiagnosable_

Let's face it, the perfect compiler/language combination doesn't exist.

My point was that operator overloading is NOT the best paradigm for
output formatting, to come back to the original discussion. The C
paradigm in *that* case is (for the time being) much better.

C gives you a mini-language and a fast run time interpreter for it. This
is a very fast and flexible solution that can be used in the C++
context. It wouldn't be very hard to figure out a standard way of
expanding the mini-language with wild cards that would give it the
possibility of formatting arrays/ new types/ etc.

But no, C++ got driven away from sanity by an initial WRONG DESIGN
DECISION that persists to this day.

That's all I am saying.

Printf extensions have been proposed and implemented. The trio printf
proposed array formatting for instance. Having implemented printf in my
compiler system I find the whole idea simple yet incredibly powerful.

Like the C language. A simple yet powerful language.

It would be more productive for everyone if C++recognized that design
mistake and would work towards a better implementation of output
formatting (maybe) using that simple idea:

A simple and small formatting LANGUAGE and an associated run time
interpreter.

Thanks for your attention.

 

[Ian Collins]

My point was that operator overloading is NOT the best paradigm for
output formatting, to come back to the original discussion. The C
paradigm in *that* case is (for the time being) much better.

In some contexts it is, in generic (template) code it's pretty useless.

C gives you a mini-language and a fast run time interpreter for it. This
is a very fast and flexible solution that can be used in the C++
context. It wouldn't be very hard to figure out a standard way of
expanding the mini-language with wild cards that would give it the
possibility of formatting arrays/ new types/ etc.

The still doesn't address the template case, a topic you appear very
keen to avoid discussing.

 

[Victor Bazarov]

[..]
Printf extensions have been proposed and implemented. The trio printf
proposed array formatting for instance. Having implemented printf in my
compiler system I find the whole idea simple yet incredibly powerful.

Like the C language. A simple yet powerful language.

It would be more productive for everyone if C++recognized that design
mistake

and would work towards a better implementation of output
formatting (maybe) using that simple idea:

A simple and small formatting LANGUAGE and an associated run time
interpreter.

First off, if you don't like (or don't understand, don't trust, don't
feel comfortable with) the mechanisms C++ *adds* to provide standard
output, don't use them. There is no law in the land that says that you
*must* use standard ostream object for formatted output. Just like *if*
you think that manual transmission in an automobile is superior to
automatic, then nobody forces you to drive automatic. It's a choice.
You've made it. Just stop trying to prove that it's the *only right way*.

And if you want to sustain the argument, start *listening*. You need to
(a) refute the claims others have made about the advantages of the
type-safe system before the other party will consider your own claims of
the advantage of the C way and (b) support your claims of the
superiority of the C way with *real* arguments, not your feelings or how
many people have been using it.

Second, C++ does not preclude you from using 'printf' for your needs.
The family of those interpreter functions *is* a part of C++ Standard
library. Not its best part, by any means, and those who understand
*why* it is so, use it with caution, but hey, nobody can tell you what
to do, right? Throw the caution into the wind!

Third, if some kind of special language similar to what 'printf' uses is
appealing to you, just *create one* for your purposes. C++ makes such
extension relatively easy (probably easier than C, although I've not
attempted to implement it to the full extent in either language). And
if others find your mechanism somehow satisfying the requirements that
are important to them and see how it fixes the deficiencies of *both*
'std:stream' *and* 'printf', they will want to use it too. *That*
what will shut everybody up, not your praises to C and unsubstantiated
claims of 'printf' superiority.

Thanks for your attention.

If it helps, you're welcome. I doubt it, though, I'm sorry to say.

V

 

[woodbrian77]

What bothers me precisely is this lack of respect from C++ programmers
that believe that because they have mastered some c++ trivialities they
are better than people that do not care about them.

Look at how java programmers are laughed at here. Or Fortran
programmers, or whatever. It is this attitude, this lack of respect that
I question.

Here's my ranking:

C++ programmers
Fortran programmers
Java Programmers

Years ago I felt a little bit left behind cause
I wasn't getting high on Java. Now it's clear
I wasn't missing anything.

Brian
Ebenezer Enterprises - John 3:16.
http://webEbenezer.net

 

[jacob navia]

Le 24/02/2014 22:57, Ian Collins a écrit :

The still doesn't address the template case, a topic you appear very
keen to avoid discussing.

One way of addressing this is to have a set of elements that represent
the formatting string for each elementary type as in C. (The PRIxXX macros)

Since we have typeof(x) we could also have printtypeof(x) or a similar
construct.

For instance you can write:

printf("The integer is" PRId64 "\n",intvar);

Now, the string behind this macro PRId64 could be then the result of a
computation, i.e. some type-based property that can be determined when
the template is being expanded, a "basic" property that could be further
customized within the intepreter language to have a maximum width, a
"precision" equivalent, whatever.

As with constructors and destructors, each class/struct type can have
easily a printed representation provided by default by the compiler. You
just print the basic types forming the aggregate separated by a single
space. That would be the default printed representation. You can write
your own fancy one as with constructors, copy-constructors, etc.

Note that a default printed representation of a type would go a long way
to easing serialization problems. But this is a disgression.

Of course this is a complex task that shouldn't be done by somebody like
me but by an expert group that pushes the idea of a mini *language* and
a run time interpreter further. The goals could be:

* concise
* extensible
* reasonable defaults for the basic types.
* SIMPLE, not much beyond a sophisticated printf! C++ people have a
tendency to complexify everything until nobody understands anything but
the people that wrote the specs

When defining a class you would add (if you want) a string for the
format interpreter. If you don't the compiler adds the default for the type.

It could be possible also to add other formatting characteristics to the
system since we are no longer in the time of 80 characters green and
black 3270 terminals... Characteristics like colour, bold, italic, for
instance something the C++ system (and the C also) do NOT do today in 2014!

THAT would be a real progress in formatting your output isn't it?

For such a SIMPLE thing like outputting text in red we have now to get
into completely unportable stuff. Why?

printf("%__red__bold %s\n","WRONG!");
printf("%__green__italic %s\n", "OK. Let's go on\n");

The gcc compiler manages to do that for its error messages in the
Macintosh. It would be nice if user programs would benefit also. And
please, this is not really NEW technology isn't it?

The material basis for doing that is at least 30 years old. (Termcap
data base, bit mapped screens)

Thanks for your attention Ian.

 

[Miami_Vice]

How can I express a large value as a double? (e.g. 1000000.3)

Whereas this compiles and executes, when I try to convert it to a

string value it converts as a scientific string (e.g. "1e+006", not

"1000000.3"). I want to process all the characters of the value of the

data as a std::string.

Or is there a way to convert the double to assure it's not expressed

in scientific notation? TIA



---

This email is free from viruses and malware because avast! Antivirus protection is active.

http://www.avast.com

You have to use <iomanip> as suggested by the solution by Paavo Helde.

 

[Stefan Ram]

For such a SIMPLE thing like outputting text in red we have now to get
into completely unportable stuff. Why?
printf("%__red__bold %s\n","WRONG!");
printf("%__green__italic %s\n", "OK. Let's go on\n");

I tend to separate semantics from formatting details:

putko( "WRONG!" );
putok( "OK. Let's go on" );

. Then, when I ever switch from Maci to another OS,
I just need to modify a few put functions.

 

[jacob navia]

Le 24/02/2014 23:05, Victor Bazarov a écrit :

I suppose you have a point somewhere here. I just can't seem to figure
out what it is.

See my answer to Mr Ian Collins in this same thread. Thanks

 

[Dombo]

Op 24-Feb-14 15:30, jacob navia schreef:

Le 24/02/2014 15:14, Victor Bazarov a écrit :

I have implemented function overloading in my compiler system lcc-win.
And true, I have read a lot of things about overloading, and also about
how overloading (like anything) can be ABUSED.

For example, the expression

String a,b,c;
c = a+b;

is an *abuse* of overloading.

Why?

Because there is no ADDITION being done when a and b are STRINGS but a
concatenation of two strings, what is *completely different*. If a and b
are strings we have

a+b != b+a

what goes against all the mathematical basis of addition as normal
people use that word.

In many programming languages, including C, one can write: a=a+1;
From the mathematical perspective that is just nonsense.

In C or C++ one could write a while loop like this:

int a = 10;
while(a=a-1)
{
printf("%d", a);
}

Using the mathematical notation semantics statements inside the loop
should never be executed because a never equals a-1, thus the expression
a=a-1 should always be evaluated as being false.

The point I'm trying to make here that the syntax of a programming
language should not be confused with mathematical notation; there is
little point in assuming the same semantics for a given expression.

IMO a good programming language should allow common operations to be
expressed as clearly and as concisely as reasonably possible. I think
very few software engineers will have trouble understanding what your
string example does, regardless of the programming languages they know.
Rewrite the the same code using just C functions, including those needed
for the memory allocation and freeing, and chances are that people
without a C background are struggling to understand what the code does,
and even people proficient in C would likely need more time to
understand the code.

Overloading in general (not necessarily operator overloading) has the
benefit that it makes it a lot easier to write generic (template) code.
When postfixes are added to the function name to differentiate between
parameter types, there is no real practical way to use them in template
functions or -classes. Even if you (or whoever is using your functions)
don't use templates, overloading still has the benefit that it relieves
the user of the function from worrying about types and having to
memorize the postfixed names; just pass the parameter and let the
compiler figure out which function to call.

Truth to be told I do dislike the iostream syntax. I do like its type
safety, extendability and the flexibility where the output goes to (or
the input comes from). But when it comes to formatting iostream just
sucks IHMO, as clearly demonstrated by your example. As far as
formatting is concerned I would have liked to see C and C++ meet
somewhere in the middle; e.g. like the approach chosen by the Boost
Format library.

 

[Stefan Ram]

In many programming languages, including C, one can write: a=a+1;
From the mathematical perspective that is just nonsense.

It makes perfect sense as an equation for one unknown value
»a«, whose solution set is the empty set, or as an assertion
that happens to be false.

 

[jacob navia]

Le 25/02/2014 00:39, Dombo a écrit :

while(a=a-1)
{
printf("%d", a);
}

Using the mathematical notation semantics statements inside the loop
should never be executed because a never equals a-1

As you know the equality operator is "==" and NOT "=" that means store
the right hand side in the left hand side...

All your reasoning should have been done with

a == a-1

and I would be really surprised if THAT would be true in some machine

The discussion is about overusing overloading for output, and I think
most participants agree that it is a PITA. Now, could a "printf" based
approach: a (mini) "language" and a run time interpreter/formatter be
better suited to output than an overloaded operator?

That is my point.

 

[Ian Collins]

Le 24/02/2014 22:57, Ian Collins a écrit :

One way of addressing this is to have a set of elements that represent
the formatting string for each elementary type as in C. (The PRIxXX macros)

Since we have typeof(x) we could also have printtypeof(x) or a similar
construct.

For instance you can write:

printf("The integer is" PRId64 "\n",intvar);

I've had some interesting discussions on (C) project mail lists
regarding PRIxXX macros. I was trying to encourage people to use them,
but most of the developers found them "too ugly". I lost..

Now, the string behind this macro PRId64 could be then the result of a
computation, i.e. some type-based property that can be determined when
the template is being expanded, a "basic" property that could be further
customized within the intepreter language to have a maximum width, a
"precision" equivalent, whatever.

As with constructors and destructors, each class/struct type can have
easily a printed representation provided by default by the compiler. You
just print the basic types forming the aggregate separated by a single
space. That would be the default printed representation. You can write
your own fancy one as with constructors, copy-constructors, etc.

I can see this working in simple cases, but not for a class that
specialised output formatting (anything which currently has a
non-trivial output operator). What does the "fancy" specifier offer
over the current (admittedly not great) streaming operators? Yes it
could be made type safe with the compiler spotting a mismatch between
the specifier and the type, but why not let the compiler do this for you
as it does now?

You would lose (or at lease make even more ugly) one of the useful
features of streaming: chaining.

Note that a default printed representation of a type would go a long way
to easing serialization problems. But this is a disgression.

Indeed it would..

Of course this is a complex task that shouldn't be done by somebody like
me but by an expert group that pushes the idea of a mini *language* and
a run time interpreter further. The goals could be:

* concise
* extensible
* reasonable defaults for the basic types.
* SIMPLE, not much beyond a sophisticated printf! C++ people have a
tendency to complexify everything until nobody understands anything but
the people that wrote the specs

When defining a class you would add (if you want) a string for the
format interpreter. If you don't the compiler adds the default for the type.

It could be possible also to add other formatting characteristics to the
system since we are no longer in the time of 80 characters green and
black 3270 terminals... Characteristics like colour, bold, italic, for
instance something the C++ system (and the C also) do NOT do today in 2014!

THAT would be a real progress in formatting your output isn't it?

Real progress is typified by the separation of presentation from the
data, CSS + HTML for example.