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, 12 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 7:28 am
From: jacob navia
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
== 2 of 24 ==
Date: Mon, Feb 24 2014 7:36 am
From: jacob navia
Le 24/02/2014 16:26, Stefan Ram a écrit :
> Wouter van Ooijen <wouter@voti.nl> writes:
>> 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";
>
> // Perl, overloading .
> msg = "M name[" . name . "],address[" . address . "] END";
>
> // VBA, overloading &
> msg = "M name[" & name & "],address[" & address & "] END"
>
> This solves the objection of overloading »+« against its
> supposed semantics of the mathematical addition, while it
> keeps the other advantages of a notation with a binary
> operator for concatenation.
>
> Yet, I have never observed any real problems with
> overloading »+« to mean string concatenation.
>
What about the problem of the intermediate results?
When using
zz=a+b+c+d;
the compiler must realize that it is better to avoid intermediate
results! This makes the compiler specialize in a special case of
operator overloading. Is this justified?
And another problem
zz = a + b + 12;
b+12 is defined in C (and C++) since it is a pointer+integer addition
giving a pointer to 12 characters after the start of b.
What happens there? Will the compiler silently accept that mistake?
You see?
The INTERACTIONS between features are also a problem.
== 3 of 24 ==
Date: Mon, Feb 24 2014 7:43 am
From: Wouter van Ooijen
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 );
:(
Wouter van Ooijen
PS Jacob, why are you hanging out of a C++ forum?
== 4 of 24 ==
Date: Mon, Feb 24 2014 7:51 am
From: Victor Bazarov
On 2/24/2014 10:23 AM, jacob navia wrote:
> Le 24/02/2014 15:54, Victor Bazarov a écrit :
>> When I mentioned overloading, I did really mean *function* overloading.
>
> Well, strange, since we were talking about the << syntax of c++ for
> OUTPUT, what is operator overloading and NOT function overloading.
If you care to reread the thread, I decided to reply to you when you stated
On 2/24/2014 8:49 AM, 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.
So, let me repeat.
C++ is so "fundamentally better" that you don't have to write Print_XXX
function with different XXX for every different type.
Moreover, making 'print_whatnot' a stand-alone function would probably
be a design mistake in that case anyway. Most likely it's better to
split the responsibilities between three parts of the design -- the
class that needs to be printed, the sink that handles the actual output
and the template that binds the two.
But again, this discussion is not about how to design an output for a
combination of object types and sinks, is it?
>
> It is a pity that all my arguments are brushed aside as "a rant" and you
> do not even go into them.
There is no depth in them that would allow anybody to "go into them",
unfortunately.
> This is convenient for you of course, since the sorry state of affairs
> in c++ because precisely too much operator overloading when formatting
> is at the center of this dicussion.
>
> Now, to come back to a function overload solution:
>
> Having a SINGLE print function to print ANY object looks great at first
> but then... how do you remember which one to use?
"Are you saying that I can dodge bullets?"
"I am saying that when you are ready, you won't have to."
(or something like that). You're still thinking in C terms. You don't
have to remember which function to use *when* your output subsystem is
designed and implemented properly, using not C but C++ mechanisms as
they are intended to be used.
>
>
> Suppose
>
> void print(XXX *data1);
> void print(XXX *data1, FILE *sink);
> void print(XXX *data1, int printFlags, FILE *sink);
> void print(XXX *data1, int printFlags, int linewidth); // Uses stdout
> void print(YYY *data2, long long printflags);
> void print(YYY *data2, CUSTOMER *c, long long flags);
>
> etc.
>
> Now the programmer must remember which arguments/argument order is
> necessary for each function... And since all have the SAME name
> remembering them is MUCH more difficult than
>
> void print_noargs(XXX *data1);
> void printWithSink(XXX *data1, FILE *sink);
> void printFlagsSink(XXX *data1, int flags, FILE *sink);
>
> or other similar simple naming schema.
>
> You see?
No, I don't see. What I see is a C approach to designing C++
interfaces, and *that* is the most common problem leading to the
dismissal of C++ features by those who come from long (too long if you
ask me) time use of C.
It's not impossible for C programmers to adopt the correct approach and
learn C++ ways -- I've seen it happen, but more often than not it's due
to what seems their lack of interest or fear to have to apply effort or
to leave the comfort of well-learned C idioms that they stay in their
playpen and keep trying to use their trusted building blocks instead of
getting to know a complex erector set.
>
> IT DEPENDS!
>
> If you have few "print" functions with identical number of arguments
> overloading is OK, but as the print functions proliferate, it becomes
> more and more difficult to use the correct one!
>
> *IT DEPENDS*
>
> That is what many C++ heads do not understand. The world is very complex
> and single solutions are good in some contexts, bad in another,
> the same as I said from operator overloading.
>
> Thanks for your input.
You're welcome.
It looks that you're just starting on the journey that is C++. You have
made a few wrong steps and your feet start to ache or perhaps you
twisted your ankle because you weren't watchful enough for rocks just
underneath the surface. Two thoughts come to mind. Don't let a small
pain divert you from the right path. And, when in shallows, don't
pretend you're treading water -- others who have already passed that
part of the way will see right through that.
Good luck in your studies!
V
--
I do not respond to top-posted replies, please don't ask
== 5 of 24 ==
Date: Mon, Feb 24 2014 7:55 am
From: ram@zedat.fu-berlin.de (Stefan Ram)
jacob navia <jacob@spamsink.net> writes:
>zz=a+b+c+d;
>the compiler must realize that it is better to avoid intermediate
>results! This makes the compiler specialize in a special case of
>operator overloading. Is this justified?
Why not?
C++ compilers also can optimize away some intermediate
results by means of the general application of move
semantics and of as-if semantics.
In Java, "abc"+"def" is compiled to "abcdef".
In C++, "abc"+"def" is not concatenation in spite of a C++ book
that claimed so.
When one wants to optimize, one can always do so:
#include <iostream>
#include <ostream>
#include <string>
int main()
{ ::std::string s{ "abc" };
s.reserve( 16);
s += "def";
s += "ghi";
s += "jkl";
::std::cout << s << '\n'; }
>And another problem
>zz = a + b + 12;
>b+12 is defined in C (and C++) since it is a pointer+integer addition
>giving a pointer to 12 characters after the start of b.
By left associativity of »+«, »b + 12« is not a
subexpression of »a + b + 12«.
== 6 of 24 ==
Date: Mon, Feb 24 2014 7:57 am
From: Victor Bazarov
On 2/24/2014 10:36 AM, jacob navia wrote:
> Le 24/02/2014 16:26, Stefan Ram a écrit :
>> Wouter van Ooijen <wouter@voti.nl> writes:
>>> 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";
>>
>> // Perl, overloading .
>> msg = "M name[" . name . "],address[" . address . "] END";
>>
>> // VBA, overloading &
>> msg = "M name[" & name & "],address[" & address & "] END"
>>
>> This solves the objection of overloading »+« against its
>> supposed semantics of the mathematical addition, while it
>> keeps the other advantages of a notation with a binary
>> operator for concatenation.
>>
>> Yet, I have never observed any real problems with
>> overloading »+« to mean string concatenation.
>>
>
> What about the problem of the intermediate results?
>
> When using
>
> zz=a+b+c+d;
>
> the compiler must realize that it is better to avoid intermediate
> results! This makes the compiler specialize in a special case of
> operator overloading. Is this justified?
You make it sound that the existence of move c-tors is somehow
unjustified in C++. Using proper technique helps the compiler to avoid
having to "realize that it is better". The compiler is but a tool, and
it is *you* who realize (or not, like in this case) *what* is *better*
and what isn't.
>
> And another problem
>
> zz = a + b + 12;
>
> b+12 is defined in C (and C++) since it is a pointer+integer addition
> giving a pointer to 12 characters after the start of b.
>
> What happens there? Will the compiler silently accept that mistake?
No. You can't overload operators for built-in types. If 'b' is a
pointer, b + 12 is a pointer. If 'b' is a string type with an
overloaded '+' operator, it will either have an overloaded variation
that accepts 'int' as its argument, or the compiler will report an error.
> You see?
All I see is ignorance so far.
> The INTERACTIONS between features are also a problem.
Perhaps you care to post a complete C++ program that illustrates that.
V
--
I do not respond to top-posted replies, please don't ask
== 7 of 24 ==
Date: Mon, Feb 24 2014 8:03 am
From: Victor Bazarov
On 2/24/2014 10: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.
You can make a mistake of providing a wrong variable in that list and
the compiler is unfortunately *impotent* to help you:
int fortytwo = 42;
char* two = "2";
char* here = "1";
...
strcatMany(here, two, fortytwo, NULL);
(not to mention that 'here' probably has not enough room to contain the
entire string, and you *need to remember that*). There is so much that
is wrong with those approaches.
V
--
I do not respond to top-posted replies, please don't ask
== 8 of 24 ==
Date: Mon, Feb 24 2014 8:10 am
From: Martin Shobe
On 2/24/2014 9:36 AM, jacob navia wrote:
> Le 24/02/2014 16:26, Stefan Ram a écrit :
>> Wouter van Ooijen <wouter@voti.nl> writes:
>>> 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";
>>
>> // Perl, overloading .
>> msg = "M name[" . name . "],address[" . address . "] END";
>>
>> // VBA, overloading &
>> msg = "M name[" & name & "],address[" & address & "] END"
>>
>> This solves the objection of overloading »+« against its
>> supposed semantics of the mathematical addition, while it
>> keeps the other advantages of a notation with a binary
>> operator for concatenation.
>>
>> Yet, I have never observed any real problems with
>> overloading »+« to mean string concatenation.
>>
>
> What about the problem of the intermediate results?
>
> When using
>
> zz=a+b+c+d;
>
> the compiler must realize that it is better to avoid intermediate
> results! This makes the compiler specialize in a special case of
> operator overloading. Is this justified?
Why must it realize that? It's certainly allowed to, but "must"?
> And another problem
>
> zz = a + b + 12;
>
> b+12 is defined in C (and C++) since it is a pointer+integer addition
> giving a pointer to 12 characters after the start of b.
>
> What happens there? Will the compiler silently accept that mistake?
The precedence rules say that 12 is added to the results of a + b. So
that particular mistake doesn't occur. Since you appear to be
overloading "+" for "char *", zz would now contain the address of a[12],
while a would contain the concatenation of a + b.
Unintuitive, certainly. It's why I wouldn't overload + on "char *". For
a string class, this wouldn't be an issue.
Martin Shobe
== 9 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
== 10 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.
== 11 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.
== 12 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
== 13 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?
>
== 14 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
== 15 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
== 16 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
== 17 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
== 18 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.
== 19 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.
== 20 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
== 21 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.
== 22 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" }}); }
== 23 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.
== 24 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
==============================================================================
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