comp.lang.c++ - 26 new messages in 3 topics - digest

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

comp.lang.c++ - 26 new messages in 2 topics - digest

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) - 25 messages, 12 authors
http://groups.google.com/group/comp.lang.c++/t/e42843c9cdf13724?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 25 ==
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




== 2 of 25 ==
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.




== 3 of 25 ==
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




== 4 of 25 ==
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




== 5 of 25 ==
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.








== 6 of 25 ==
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.




== 7 of 25 ==
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.







== 8 of 25 ==
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




== 9 of 25 ==
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.









== 10 of 25 ==
Date: Mon, Feb 24 2014 3:46 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)


Dombo <dombo@disposable.invalid> writes:
>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.





== 11 of 25 ==
Date: Mon, Feb 24 2014 3:52 pm
From: 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.




== 12 of 25 ==
Date: Mon, Feb 24 2014 4:08 pm
From: Robert Wessel


On Tue, 25 Feb 2014 00:52:13 +0100, jacob navia <jacob@spamsink.net>
wrote:

>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 :-)


On most implementations:

double a=1e30;
if (a == a-1)
printf("would be true!\n");





== 13 of 25 ==
Date: Mon, Feb 24 2014 5:09 pm
From: Ian Collins


jacob navia wrote:
> 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);

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.

--
Ian Collins




== 14 of 25 ==
Date: Mon, Feb 24 2014 10:45 pm
From: Ike Naar


On 2014-02-24, jacob navia <jacob@spamsink.net> 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's the type of c in the line above?
(Note that strcatMany returns an int).




== 15 of 25 ==
Date: Tues, Feb 25 2014 6:41 am
From: scott@slp53.sl.home (Scott Lurndal)


Robert Wessel <robertwessel2@yahoo.com> writes:
>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).

I think one might argue that type-safety is a red-herring in the
snprintf case, but YMMV.





== 16 of 25 ==
Date: Tues, Feb 25 2014 6:45 am
From: scott@slp53.sl.home (Scott Lurndal)


Robert Wessel <robertwessel2@yahoo.com> writes:
>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).

The system that I first did OS development work on supported 100 digit
intermediaries for COBOL (hardware BCD, addressed to the digit/nibble).

http://vseries.lurndal.org/doku.php

Isn't your example (233.5555%) a bit contrived?


>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

Well, most of them supported decimal _fixed point_, not floating point.

They were business machines after all, not scientific (although the 360's
were abused for that purpose - which is why IBM had optional binary
floating point functionality).





== 17 of 25 ==
Date: Tues, Feb 25 2014 6:49 am
From: scott@slp53.sl.home (Scott Lurndal)


woodbrian77@gmail.com writes:
>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
>

That's pretty silly, ranking programmers by language instead of by
ability to produce a viable program regardless of the language. Good
programmers don't really care which language they use, they use the
proper language for the problem.

It would be quite odd for someone to write a servlet in C++, when
one can do it much more rapidly, efficiently and correctly in Java, for example.

Python, perl, ruby, Fortran, Assembler, Visual Basic all have their
niche.

>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.

A strange paragraph, to be sure.





== 18 of 25 ==
Date: Tues, Feb 25 2014 10:27 am
From: Gerhard Fiedler


Scott Lurndal wrote:

> Gerhard Fiedler <gelists@gmail.com> writes:
>>OTOH, (type-safely) encapsulating printf is quite the challenge.
>
> See, that's the C++ programmer view. A real programmer will use ...

This sounds as if you think that a C++ programmer is not a real
programmer :)

> ... snprintf when and where it makes sense ...

Sure... I thought that was a given.

> ... and not worry about "encapsulating" it ...

Well, when programming, I rarely think in single programming lines but
more about bigger concepts. And there, "encapsulation" is always
important, no matter the language.

> ... and doesn't care about spurious "language purity".

That idea of "language purity" seems to be yours; it definitely wasn't
part of my post. Does that make you an "unreal" programmer? :)


> examples from C++ operating system:

Not sure what a "C++ operating system" is. But I do understand (and
occasionally use) the printf-family of functions, if that was the point.

> Letting the compiler check arguments, even on user-defined functions
> is trivial with a good compiler:

Try letting the compiler check the argument types when using a variable
as formatting string.

Gerhard




== 19 of 25 ==
Date: Tues, Feb 25 2014 11:21 am
From: scott@slp53.sl.home (Scott Lurndal)


Gerhard Fiedler <gelists@gmail.com> writes:

>Try letting the compiler check the argument types when using a variable
>as formatting string.

I've never seen a case where it makes sense to use a variable as a
formatting string[*]. Can you describe a case where it does make sense
and it doesn't cause a potential security problem?

[*] absent a wrapper function that uses __attribute__((printf(x,y))), anyway.




== 20 of 25 ==
Date: Tues, Feb 25 2014 12:07 pm
From: Victor Bazarov


On 2/25/2014 2:21 PM, Scott Lurndal wrote:
> Gerhard Fiedler <gelists@gmail.com> writes:
>
>> Try letting the compiler check the argument types when using a variable
>> as formatting string.
>
> I've never seen a case where it makes sense to use a variable as a
> formatting string[*]. Can you describe a case where it does make sense
> and it doesn't cause a potential security problem?

<shrug> All you need to imagine is selection between different formats
based on a run-time expression, like

const char* fmt[] = { "%d", "%p", "%s" };
...
int i = some_runtime_value;
...
printf(fmt[i % (sizeof(fmt)/sizeof(*fmt))], whatever);

What security problem do you see here?

> [*] absent a wrapper function that uses __attribute__((printf(x,y))), anyway.

V
--
I do not respond to top-posted replies, please don't ask




== 21 of 25 ==
Date: Tues, Feb 25 2014 12:38 pm
From: Dombo


Op 25-Feb-14 0:52, jacob navia schreef:
> 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...

In C it is, not in mathematical notation. So how come you could easily
make this distinction in this example, but not in case of your string
example?

> The discussion is about overusing overloading for output, and I think
> most participants agree that it is a PITA.

If have no problems with the use of function overloading for output, in
fact I believe it is a good choice since it allows it to be extended
transparently for the user. That doesn't mean I particularly like the
overloading of the << operator (minor gripe) or how iostreams deals with
formatting (big gripe).

> 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.

Why a runtime interpreter? I'd much rather see as much as reasonably can
be done at compile time, including checks and with type safety. The
Boost Format library seems to be a nice compromise between the ease of
formatting of printf and the extendability, type safety and flexibility
of the iostreams.




== 22 of 25 ==
Date: Tues, Feb 25 2014 12:39 pm
From: Ian Collins


Scott Lurndal wrote:
> Gerhard Fiedler <gelists@gmail.com> writes:
>
>> Try letting the compiler check the argument types when using a variable
>> as formatting string.
>
> I've never seen a case where it makes sense to use a variable as a
> formatting string[*]. Can you describe a case where it does make sense
> and it doesn't cause a potential security problem?

Simple internationalisation. I've worked on embedded projects where we
used different sets of format strings for different languages. No
security risks there.

> [*] absent a wrapper function that uses __attribute__((printf(x,y))), anyway.

Where is that defined in the C++ standard?

--
Ian Collins




== 23 of 25 ==
Date: Tues, Feb 25 2014 2:33 pm
From: David Brown


On 25/02/14 21:39, Ian Collins wrote:
> Scott Lurndal wrote:
>> Gerhard Fiedler <gelists@gmail.com> writes:
>>
>>> Try letting the compiler check the argument types when using a variable
>>> as formatting string.
>>
>> I've never seen a case where it makes sense to use a variable as a
>> formatting string[*]. Can you describe a case where it does make sense
>> and it doesn't cause a potential security problem?
>
> Simple internationalisation. I've worked on embedded projects where we
> used different sets of format strings for different languages. No
> security risks there.

That would be my thought. You might have something like this:

typedef enum { formatUK, formatUS } dateFormatChoices;
static const char dateFormatStrings[] = {
"%1$02d/%2$02d/%3$04d", "%2$02d/%1$02d/%3$04d"
}
void printDate(dateFormatChoices i, int day, int month, int year) {
printf(dateFormatStrings[i], day, month, year);
}

(That particular example relies on posix printf with parameters - if you
can't re-arrange parameter order like that, variable format strings are,
I think, significantly less useful.)

>
>> [*] absent a wrapper function that uses __attribute__((printf(x,y))),
>> anyway.
>
> Where is that defined in the C++ standard?
>





== 24 of 25 ==
Date: Tues, Feb 25 2014 4:42 pm
From: Robert Wessel


On Tue, 25 Feb 2014 14:45:38 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:

>Robert Wessel <robertwessel2@yahoo.com> writes:
>>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).
>
>The system that I first did OS development work on supported 100 digit
>intermediaries for COBOL (hardware BCD, addressed to the digit/nibble).
>
> http://vseries.lurndal.org/doku.php
>
>Isn't your example (233.5555%) a bit contrived?


All simple examples are contrived.

But not that much. A fairly simple requirement (multiply a currency
value by a percentage), with not unreasonable ranges, leads to
overflow problems on not unreasonable inputs. Admittedly in most real
multiplications by percentages, you probably have two or three
additional usable digits to play with.


>>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
>
>Well, most of them supported decimal _fixed point_, not floating point.


The 704s and descendents were binary FP, the 7070s had decimal FP.
Many of the commercial machines supported fixed point decimal,
although the 7070s were more in the commercial line, and FP feature
was optional.


>They were business machines after all, not scientific (although the 360's
>were abused for that purpose - which is why IBM had optional binary
>floating point functionality).


It's hard to say that S/360's were "abused" for scientific purposes,
when they were specifically designed to unify both the commercial and
scientific lines of IBM's computers. Specific models were built only
for the scientific community (the four machines in the 91/95/195
groups). You might as well claim that these machines were abused for
commercial purposes leading to IBM having the optional decimal
instructions. Even the chosen name reflects the "all around" purpose
of the machines.




== 25 of 25 ==
Date: Tues, Feb 25 2014 4:46 pm
From: Robert Wessel


On Wed, 26 Feb 2014 09:39:11 +1300, Ian Collins <ian-news@hotmail.com>
wrote:

>Scott Lurndal wrote:
>> Gerhard Fiedler <gelists@gmail.com> writes:
>>
>>> Try letting the compiler check the argument types when using a variable
>>> as formatting string.
>>
>> I've never seen a case where it makes sense to use a variable as a
>> formatting string[*]. Can you describe a case where it does make sense
>> and it doesn't cause a potential security problem?
>
>Simple internationalisation. I've worked on embedded projects where we
>used different sets of format strings for different languages. No
>security risks there.


Unfortunately the strictly positional nature of the input parameters
in the printf functions has always led us to use our own replacement.





==============================================================================
TOPIC: OT: Problem building libc++
http://groups.google.com/group/comp.lang.c++/t/177ee9b847d7540f?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Feb 25 2014 6:55 am
From: scott@slp53.sl.home (Scott Lurndal)


woodbrian77@gmail.com writes:
>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.

Not really, I could care less about the size of a binary.

The layout of data in memory, however, is important in the types
of applications I write - where cache pressure is significant
and there are high levels of concurrency (dozens to hundreds of threads
on systems with 10s to 100's of cores).

>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.

Actually, that could be a really bad idea for multithreaded
applications if multiple threads need that same cache line.

You really want run-time profiling tool help for this problem
(e.g. oprofile/prof).

>
>
>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.

See, that's what I call obsessive :-)

Pick a compiler and stick with it.




==============================================================================

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