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, 11 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
* Iterator pair as a function argument? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/d7a4099890dfa4ed?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:05 am
From: scott@slp53.sl.home (Scott Lurndal)
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
snprintf when and where it makes sense and not worry about "encapsulating"
it and doesn't care about spurious "language purity".
examples from C++ operating system:
snprintf(buf, sizeof(buf), "QM%05u", s->drive_serial);
snprintf(name, sizeof(name), "vdev-xen%u", index);
snprintf(ep, (varlen+vallen+2), "%s=%s", argv[1], argv[2]);
Letting the compiler check arguments, even on user-defined functions
is trivial with a good compiler:
class Console {
...
public:
void printf(const char *fmt, ...) __attribute__((format(printf, 2, 3)));
};
console->printf("This warns if long long argument used %u\n", long_long_unsigned_int_var);
== 2 of 24 ==
Date: Mon, Feb 24 2014 7:13 am
From: Paavo Helde
scott@slp53.sl.home (Scott Lurndal) wrote in
news:QZIOu.9571$sB7.2196@fx19.iad:
> Paavo Helde <myfirstname@osa.pri.ee> writes:
>>scott@slp53.sl.home (Scott Lurndal) wrote in news:PJJNu.5151$7V3.3521
>>@fx18.iad:
>>
>>>
>>> man 3 snprintf
>>>
>>> (Yes, it works fine in C++)
>>
>>Except that it is part of C99 and not present in MSVC++, which is what
>>Mike is using (to add confusion, there is nonstandard _snprintf with
>>slightly different interface).
>>
>
> One can count on microsoft to screw things up, I guess. sprintf is
> a security problem waiting to catch a poor programmer and should have
> been deprecated two decades ago.
Agreed, but nobody has proposed using sprintf.
Cheers
Paavo
== 3 of 24 ==
Date: Mon, Feb 24 2014 7:14 am
From: Wouter van Ooijen
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" );
== 4 of 24 ==
Date: Mon, Feb 24 2014 7:23 am
From: jacob navia
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.
It is a pity that all my arguments are brushed aside as "a rant" and you
do not even go into them.
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?
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?
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.
== 5 of 24 ==
Date: Mon, Feb 24 2014 7:25 am
From: Wouter van Ooijen
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).
> Modern C++ has become almost unreadable.
Y ain't seen nothing yet! Try template metaprogramming :)
Wouter van Ooijen
== 6 of 24 ==
Date: Mon, Feb 24 2014 7:26 am
From: ram@zedat.fu-berlin.de (Stefan Ram)
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.
== 7 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
== 8 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.
== 9 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?
== 10 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
== 11 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«.
== 12 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
== 13 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
== 14 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
== 15 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
== 16 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.
== 17 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.
== 18 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
== 19 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?
>
== 20 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
== 21 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
== 22 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
== 23 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
== 24 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.
==============================================================================
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 7:19 am
From: scott@slp53.sl.home (Scott Lurndal)
woodbrian77@gmail.com writes:
>On Saturday, February 22, 2014 2:01:50 PM UTC-6, woodb...@gmail.com wrote:
>
>>
>> OK, thanks. I looked at that and wasn't making much
>> progress with it so I decided to install Arch linux.
>> That was a little bit of a pain, but I got it and
>> it has clang 3.4 as it's default version.
>
>This tripped me up so am adding a note about it here.
>
>It wasn't enough to do
>
>pacman -S clang
>
>. I also had to do
>
>pacman -S libc++
>
>and link with libc++abi (-lc++abi)
>.
>
>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).
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.
An example:
struct AHCIDevice {
struct IDEBus port; /* 0 1696 */
/* XXX last struct has 4 bytes of padding */
/* --- cacheline 26 boundary (1664 bytes) was 32 bytes ago --- */
uint32_t state; /* 1696 4 */
uint32_t finished; /* 1700 4 */
struct AHCIPortRegs reg; /* 1704 68 */
/* XXX 4 bytes hole, try to pack */
/* --- cacheline 27 boundary (1728 bytes) was 48 bytes ago --- */
uint64_t lst; /* 1776 8 */
uint64_t res_fis; /* 1784 8 */
/* --- cacheline 28 boundary (1792 bytes) --- */
int done_atapi_packet; /* 1792 4 */
int init_d2h_sent; /* 1796 4 */
class AHCICmdHdr * cur_cmd; /* 1800 8 */
struct AHCICmdHdr cur_cmd_buf; /* 1808 32 */
/* size: 1840, cachelines: 29, members: 10 */
/* sum members: 1836, holes: 1, sum holes: 4 */
/* paddings: 1, sum paddings: 4 */
/* last cacheline: 48 bytes */
};
==============================================================================
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 .
==============================================================================
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