comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Working with Large Values (double) - 24 messages, 14 authors
http://groups.google.com/group/comp.lang.c++/t/e42843c9cdf13724?hl=en
* Iterator pair as a function argument? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/d7a4099890dfa4ed?hl=en
* OT: Problem building libc++ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/177ee9b847d7540f?hl=en
==============================================================================
TOPIC: Working with Large Values (double)
http://groups.google.com/group/comp.lang.c++/t/e42843c9cdf13724?hl=en
==============================================================================
== 1 of 24 ==
Date: Mon, Feb 24 2014 8:23 am
From: Martin Shobe
On 2/24/2014 9:28 AM, jacob navia wrote:
> Le 24/02/2014 16:14, Wouter van Ooijen a écrit :
>> jacob navia schreef op 24-Feb-14 3:30 PM:> For example, the expression
>> >
>> > String a,b,c;
>> > c = a+b;
>> >
>> > is an *abuse* of overloading.
>>
>> Maybe, but a maybe-not-so-pretty solution must be compared to the
>> alternatives. How would you prefer to add a lot of strings?
>>
>> // C++, overloading +
>> msg = "M name[" + x.name + "],address[" + x.address + "] END";
>>
>> // Python, with compile-time support for checking the format string
>> msg = "M [name[%s],address[%s] END" % ( x.name, x.address )
>>
>> // No tricks, using nested concatenate function (LISP style??)
>> msg = concatenate(
>> "M name["
>> concatenate(
>> x.name
>> concatenate(
>> "],address["
>> concatenate(
>> x.address,
>> "] END")))));
>>
>> // sequence of append calls (C style??)
>> msg = ""
>> append( msg, "M name[" );
>> append( msg, x.name );
>> append( msg, "],address[" );
>> append( msg, x.address );
>> append( msg, "] END" );
>>
>
> Please, this is beginner level question
>
>
> Solution 1: (preferred)
> -----------------------
> int strcatMany(char *first,...);
>
> calling sequence:
>
> strcatMany(a,b,c,NULL);
>
> or another:
>
> Solution 2
> ----------
> strcatMany(int n,...);
>
> calling sequence:
>
> strcatMany(4,"1","2,"3","4");
> This is not so good because you can make a mistake counting the strings.
>
> jacob
Aside from using names that have been reserved, this is silently
undefined behavior if we try the following (a situation you used to
denigrate overloading +):
strcatMany(a, b, 12);
Even that aside, the only way you've left to get the concatenated string
is through a global variable. I find that to be a serious deficiency,
though one that can be fixed.
int Concatenate(char * dest, char const * first, ...);
int ConcatenateN(char * dest, int n, ...);
Martin Shobe
== 2 of 24 ==
Date: Mon, Feb 24 2014 8:40 am
From: Geoff
On Mon, 24 Feb 2014 14:47:39 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:
>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.
== 3 of 24 ==
Date: Mon, Feb 24 2014 8:57 am
From: 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.
== 4 of 24 ==
Date: Mon, Feb 24 2014 9:03 am
From: Paavo Helde
Wouter van Ooijen <wouter@voti.nl> wrote in news:530b61cd$0$25294
$e4fe514c@dreader34.news.xs4all.nl:
> jacob navia schreef op 24-Feb-14 3:30 PM:> For example, the expression
> >
> > String a,b,c;
> > c = a+b;
> >
> > is an *abuse* of overloading.
>
> Maybe, but a maybe-not-so-pretty solution must be compared to the
> alternatives. How would you prefer to add a lot of strings?
>
> // C++, overloading +
> msg = "M name[" + x.name + "],address[" + x.address + "] END";
One could argue this is not the best way to do this in C++. On one hand
it may be unnecessarily slow and on the other hand the structure of the
result is not readily visible. So, depending on circumstances I would
write this in different ways in C++. In performance-critical code:
std::string msg = "M name[";
msg += x.name;
msg += "],address[";
msg += x.address;
msg += "] END";
If the speed is not critical, I would use my nifty typesafe wrapper of
snprintf(), which checks the format string and converts the arguments as
needed:
std::string msg = Sprintf("M [name[%s],address[%s] END")(x.name)
(x.address);
Cheers
Paavo
== 5 of 24 ==
Date: Mon, Feb 24 2014 9:07 am
From: David Brown
On 24/02/14 16:43, Wouter van Ooijen wrote:
> jacob navia schreef op 24-Feb-14 4:28 PM:
>> Solution 1: (preferred)
>> -----------------------
>> int strcatMany(char *first,...);
>>
>> calling sequence:
>>
>> strcatMany(a,b,c,NULL);
>
> 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.)
>
> Wouter van Ooijen
>
> PS Jacob, why are you hanging out of a C++ forum?
>
== 6 of 24 ==
Date: Mon, Feb 24 2014 9:41 am
From: scott@slp53.sl.home (Scott Lurndal)
Wouter van Ooijen <wouter@voti.nl> writes:
>jacob navia schreef op 24-Feb-14 3:30 PM:> For example, the expression
> >
> > String a,b,c;
> > c = a+b;
> >
> > is an *abuse* of overloading.
>
>Maybe, but a maybe-not-so-pretty solution must be compared to the
>alternatives. How would you prefer to add a lot of strings?
>
>// C++, overloading +
>msg = "M name[" + x.name + "],address[" + x.address + "] END";
>
>// Python, with compile-time support for checking the format string
>msg = "M [name[%s],address[%s] END" % ( x.name, x.address )
>
>// No tricks, using nested concatenate function (LISP style??)
>msg = concatenate(
> "M name["
> concatenate(
> x.name
> concatenate(
> "],address["
> concatenate(
> x.address,
> "] END")))));
>
>// sequence of append calls (C style??)
>msg = ""
>append( msg, "M name[" );
>append( msg, x.name );
>append( msg, "],address[" );
>append( msg, x.address );
>append( msg, "] END" );
>
snprintf(msg, sizeof(msg), "M name[%s],address[%s] END", x.name, x.address);
Even avoids buffer overflow regardless of the length of x.name or x.address.
scott
== 7 of 24 ==
Date: Mon, Feb 24 2014 9:44 am
From: scott@slp53.sl.home (Scott Lurndal)
Wouter van Ooijen <wouter@voti.nl> writes:
>Scott Lurndal schreef op 24-Feb-14 3:56 PM:
>> Modern compilers are good at warning about varargs argument mismatches
>> with the format string.
>
>That might be the case, but it is a mechanism that is closed to the
>programmer (or library developer).
Not in the gcc, wherein __attribute__((format)) can be used by both.
>
>> Modern C++ has become almost unreadable.
>
>Y ain't seen nothing yet! Try template metaprogramming :)
I have. Between templates and lambdas, the language has become
unreadable :-)
scott
== 8 of 24 ==
Date: Mon, Feb 24 2014 10:53 am
From: Ian Collins
jacob navia wrote:
> Le 24/02/2014 12:32, Juha Nieminen a écrit :
>> The C version is not type safe, cannot be expanded with new types,
>
> 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.
--
Ian Collins
== 9 of 24 ==
Date: Mon, Feb 24 2014 11:25 am
From: Barry Schwarz
On Sun, 23 Feb 2014 05:57:28 -0800 (PST), James Kanze
<james.kanze@gmail.com> wrote:
>On Friday, February 21, 2014 6:00:10 AM UTC, robert...@yahoo.com wrote:
>> On Thu, 20 Feb 2014 17:25:50 -0700, mrc2323@cox.net (Mike Copeland)
>> wrote:
>
>> > 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
>
>> Doubles are floating point and are inherently "in" scientific
>> notation.
>
>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.
--
Remove del for email
== 10 of 24 ==
Date: Mon, Feb 24 2014 12:14 pm
From: 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.
== 11 of 24 ==
Date: Mon, Feb 24 2014 12:18 pm
From: jacob navia
Le 24/02/2014 16:43, Wouter van Ooijen a écrit :
> jacob navia schreef op 24-Feb-14 4:28 PM:
> > Solution 1: (preferred)
> > -----------------------
> > int strcatMany(char *first,...);
> >
> > calling sequence:
> >
> > strcatMany(a,b,c,NULL);
>
> 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.
== 12 of 24 ==
Date: Mon, Feb 24 2014 12:40 pm
From: Victor Bazarov
On 2/24/2014 3:18 PM, jacob navia wrote:
> Le 24/02/2014 16:43, Wouter van Ooijen a écrit :
>> jacob navia schreef op 24-Feb-14 4:28 PM:
>> > Solution 1: (preferred)
>> > -----------------------
>> > int strcatMany(char *first,...);
>> >
>> > calling sequence:
>> >
>> > strcatMany(a,b,c,NULL);
>>
>> strcatMany( a, b, c );
>
> 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.
>>
>> :(
>>
>> 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.
>
V
--
I do not respond to top-posted replies, please don't ask
== 13 of 24 ==
Date: Mon, Feb 24 2014 1:05 pm
From: 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.
== 14 of 24 ==
Date: Mon, Feb 24 2014 1:34 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)
jacob navia <jacob@spamsink.net> writes:
>There is no way to specify a list of arguments of the same type in C (or
>in C++ for that matter).
Do you refer to a function that is kind of varargs,
but requires all arguments to be of the same type?
#include <initializer_list>
#include <string>
template< typename T >void f( ::std::initializer_list< T >const ){}
int main()
{ f( { 2, 3 });
f( { ::std::string{ "a" }, ::std::string{ "b" }});
f( { 2, ::std::string{ "b" }}); }
== 15 of 24 ==
Date: Mon, Feb 24 2014 1:49 pm
From: Robert Wessel
On Mon, 24 Feb 2014 14:47:39 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:
>James Kanze <james.kanze@gmail.com> writes:
>>On Saturday, February 22, 2014 1:28:32 AM UTC, robert...@yahoo.com wrote:
>>
>>> Attempting to use FP to represent currency is fundamentally doomed to
>>> failure.
>>
>>That depends on what you are doing. If you're doing
>>risk analysis on futures contracts, for example, it's
>>perfectly appropriate (and you probably can't afford
>>the loss of performance a decimal solution would cost
>
>Actually, scaled binary integers are probably the best
>bet for this (given 64-bit integers). Performs better
>than FP and no binary FP nonrepresentability issues.
>
>Scale everything to mils and work accordingly.
While 64 bit are enough for almost all stored currency values, they're
not enough for intermediate results. Consider multiplying a dollar
amount (stored in pennies) by a percentage with three digits in front
of, and four digits after, the decimal point. You'll overflow your
intermediate results somewhere around a billion dollars.
The Cobol folks, who, if nothing else, care about currency, have long
required longer intermediates. And FWIW, recent standards have
increased the minimum number of decimal digits supported in a number
from 18 to 36 (and those limits are independent of representation - an
implementation could implement 128 bit binary numbers, or 19 byte
packed numbers, or both, to support that).
>>you). After all, any rounding errors will be much
>>less than the variance of the Monte Carlo simulation
>>anyway.
>>
>>If you're doing anything even closely related to
>>legally required bookkeeping, however (and I would
>>imagine writing checks comes into that providence),
>>then using machine floating point is probably illegal,
>>and could, in many jurisdictions, send you to jail.
>>
>>Note that I say "machine floating point", and not just
>
>Note that several (now rare) processor architectures
>included hardware support for decimal floating point. These
>were the architectures used by banks and other financial
>institutions (Burroughs (V-series), IBM (zSeries, pSeries),
>et alia.)
I think there were a couple of *really* old IBM architectures that
supported decimal FP, but most of IBM's pre-360 machines were either
binary FP or decimal fixed point (depending on their target market).
S/360 has always supported fixed point decimal. Z and POWER have
fairly recently added IEEE decimal FP support. Fujitsu recently
announced SPARC 64 X also adds IEEE decimal FP.
IEEE binary FP is defined in such a way that you can actually use it
in a mostly non-FP way so long as the values don't get too large.
== 16 of 24 ==
Date: Mon, Feb 24 2014 1:57 pm
From: Ian Collins
jacob navia wrote:
>
> 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.
--
Ian Collins
== 17 of 24 ==
Date: Mon, Feb 24 2014 2:04 pm
From: Robert Wessel
On Mon, 24 Feb 2014 22:05:44 +0100, jacob navia <jacob@spamsink.net>
wrote:
>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.
I don't think anyone really thinks C++ streams are pretty. IMO,
they're darn ugly. And overloading the shift operators is at least a
little perverse. OTOH, the shift operators as such are fairly rare in
code, so while a new operator might have been a bit better, it's
really not that big a deal.
OTOH, streams *are* type safe and extensible (please don't bother
reiterating your argument that many compilers add partial type safety
to the printf functions, I've heard you, and, IMO, the argument is
insufficient, but we're unlikely to convince each other).
But type safety and extensibility are important, and better mechanism
needs to support both, or it will pretty much be flatly rejected. That
makes it difficult to hand too much function off to a runtime format
interpreter. Something like boost::format is likely to get a much
better reception.
== 18 of 24 ==
Date: Mon, Feb 24 2014 2:05 pm
From: Victor Bazarov
On 2/24/2014 4:05 PM, jacob navia wrote:
> [..]
> 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.
<sigh> I suppose you have a point somewhere here. I just can't seem to
figure out what it is.
> It would be more productive for everyone if C++recognized that design
> mistake
<shrug> You keep saying it as if repeating it somehow makes it true.
> 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::ostream' *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
--
I do not respond to top-posted replies, please don't ask
== 19 of 24 ==
Date: Mon, Feb 24 2014 2:08 pm
From: woodbrian77@gmail.com
On Monday, February 24, 2014 8:14:03 AM UTC-6, jacob navia wrote:
>
> 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
== 20 of 24 ==
Date: Mon, Feb 24 2014 2:39 pm
From: 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.
== 21 of 24 ==
Date: Mon, Feb 24 2014 2:44 pm
From: Miami_Vice
On Friday, February 21, 2014 12:25:50 AM UTC, Mike Copeland wrote:
> 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.
== 22 of 24 ==
Date: Mon, Feb 24 2014 2:50 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)
jacob navia <jacob@spamsink.net> writes:
>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.
== 23 of 24 ==
Date: Mon, Feb 24 2014 2:50 pm
From: 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
== 24 of 24 ==
Date: Mon, Feb 24 2014 3:39 pm
From: Dombo
Op 24-Feb-14 15:30, jacob navia schreef:
> Le 24/02/2014 15:14, Victor Bazarov a écrit :
>> Perhaps you can read more about overloading, it's one important feature
>> of C++ that sets it aside from C.
>
> 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.
==============================================================================
TOPIC: Iterator pair as a function argument?
http://groups.google.com/group/comp.lang.c++/t/d7a4099890dfa4ed?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Feb 24 2014 9:55 am
From: Jorgen Grahn
On Mon, 2014-02-24, Drew Lawson wrote:
> In article <lef9ed$2hos$1@adenine.netfront.net>
> Juha Nieminen <nospam@thanks.invalid> writes:
>>nvangogh <nvangogh@pcexpert.net> wrote:
>>> The first problem I have is to question if it is possible to pass
>>> iterators as distinct arguments to a function?
>>
>>Why wouldn't it be? What exactly is the problem you are envisioning
>>with it?
>
> It has been a while, but I recall iterators being a little puzzling
> when I first encountered them. It took a little while to click
> that foo::iterator is just another type. I can't say what I thought
> they were, but they were mildly confusing.
I recall being confused because I assumed my code would automatically
be generic (work with any container) because I used containers and
iterators. And yet I had to pick /one/ type -- unless I wrote a
template function, which sounded too advanced for me.
After a while I realized genericity of /my/ code wasn't the goal.
And that most code can choose one suitable container (often
std::vector) and stick to it.
> This was from the context of learn-by-using. If I'd started with
> a good explanation/description, that confusion might not have been
> there.
I used a book on STL, but I would probably have been better off
reading the online SGI STL manual. That one was very good (for me).
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
==============================================================================
TOPIC: OT: Problem building libc++
http://groups.google.com/group/comp.lang.c++/t/177ee9b847d7540f?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Feb 24 2014 1:21 pm
From: woodbrian77@gmail.com
On Monday, February 24, 2014 9:19:02 AM UTC-6, Scott Lurndal wrote:
> woodbrian77@gmail.com writes:
>
> >Tomorrow I may try installing gcc 4.9. Previously
> >when installing a gcc snapshot, I'd install gmp,
> >mpfr and mpc. Now it looks like there's another
> >library called "elf" that needs to be installed?
> gcc and binutils should go together, generally.
>
> I believe most of the ELF stuff (Extensible Linking Format)
> is part of elfutils package(s). You also might find the dwarves
> package useful (pahole, in particular, as you seem to be
> obsessive about the size of your binary).
>
I'm not the only one who cares about these things.
> pahole will display the layout in memory of a class, showing holes
> caused by alignment. It may lead you to group all your 'bool'
> variables together (uint64_t, bool, uint64_t, bool, uint64_t) will
> waste 14 bytes in every object containing those 5 fields, for example,
> while (uint64_t, uint64_t, uint64_t, bool, bool) won't.
>
You're preaching to the choir on that. Birds of a
feather flock together. I know also that Andrei A.
talks about putting "hot" members (members that are
used a lot) close to each other so they will fit in
a few cachelines. That seems like something to
consider also.
I downloaded the gcc 4.9 snapshot and built and
installed it on the same machine I have clang 3.4 on.
Gcc seems to be working fine, but I can only get
clang to work when I specify -stdlib=libc++ and
-lc++abi.
Previously all I had to do to switch from gcc to
clang was uncomment this line:
#CXX=clang++
So it was easy to switch between the two. Now it's
kind of troublesome.
Brian
Ebenezer Enterprises
http:/webEbenezer.net
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en
To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment