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, 8 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 6:47 am
From: scott@slp53.sl.home (Scott Lurndal)
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.
>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.)
== 2 of 24 ==
Date: Mon, Feb 24 2014 6:49 am
From: scott@slp53.sl.home (Scott Lurndal)
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.
== 3 of 24 ==
Date: Mon, Feb 24 2014 6:50 am
From: scott@slp53.sl.home (Scott Lurndal)
James Kanze <james.kanze@gmail.com> writes:
>On Friday, February 21, 2014 2:51:27 PM UTC, Scott Lurndal wrote:
>
>> man 3 snprintf
>>
>> (Yes, it works fine in C++)
>
>Funny, because it never worked "fine" in C. In C, you use it,
>because there's not really anything else, but C formatted output
>has to be one of the worst designs ever.
Compared to the crapfest that C++ defines (operator overloading,
setw, setprecision, et alia;give me a break!), snprintf is a paragon of clarity.
I suppose you could always use to COBOL picture clauses :-)
== 4 of 24 ==
Date: Mon, Feb 24 2014 6:54 am
From: Victor Bazarov
On 2/24/2014 9:30 AM, jacob navia wrote:
> 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.
> [.. rant about operator overloading removed ..]
You really need to stop taking everything as an attack, you know. When
I mentioned overloading, I did really mean *function* overloading. And,
curiously enough, as you do claim to have "implemented function
overloading", you immediately go on giving an example of *operator*
overloading as a feature that is prone to abuse...
Well, let me be a bit more verbose, as now I see that my *assumption* of
your somewhat skewed knowledge of overloading was most likely the cause
for your "disagreement".
When you define 'print' function for other types, the main advantage the
overloading gives you is that you don't need to name those functions
differently.
... print(const OneType& val);
can easily coexist in C++ with
... print(const SomeOtherType& val);
which gives you this important feature -- you can write in your code
print(someObject);
without having to remember what type 'someObject' has. The compiler
will pick the right function for you.
> P.S. It would be great if you wouldn't assume that other people that do
> not agree with c++'s decisions are ignorants that "should read more".
Even if you are not "an ignorant", the pattern of your disagreement
"with c++'s decisions" does indeed suggest that you should read more,
and I am not sorry that I assumed as much.
V
--
I do not respond to top-posted replies, please don't ask
== 5 of 24 ==
Date: Mon, Feb 24 2014 6:56 am
From: scott@slp53.sl.home (Scott Lurndal)
ram@zedat.fu-berlin.de (Stefan Ram) writes:
>jacob navia <jacob@spamsink.net> writes:
>>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.
>
> Because in C++, the user can always use the same verb:
>
>... << x ...
>... << i ...
>
> while in C, he has to remember individual verbs per type
>
>print_double( x )
>print_int( x )
>
> or cannot infer a static type at all, because the type is
> not know at compile time, in which case one needs to start
> to implement OO in C, which is already supplied by the
> language in C++.
After a quarter century of writing production C++ code, I find your
complaints to be spurious. I use the standard C library formatting
utilities and I have no problem remembering anything about how to
use them.
Modern compilers are good at warning about varargs argument mismatches
with the format string. A good programmer seldom needs to change a
datatype for an existing variable when maintaining a program because
the correct type was chosen from the start.
You're inventing a problem that doesn't exist, just to denigrate another
language.
Modern C++ has become almost unreadable.
== 6 of 24 ==
Date: Mon, Feb 24 2014 7:04 am
From: Wouter van Ooijen
jacob navia schreef op 24-Feb-14 3:34 PM:
> Besides, if you want to support SEVERAL print functions for instance for
> formatting a customer with name, age or name, SS number, or just
> initials, etc you will need anyway several print functions in C++ also,
> if I remember correctly isn't it?
In true C++: if that is what you want it is cetainly possible, just like
you can have print_xxx functions if you want to.
I think I would prefer to reserve operator<<(person) for (debug)
printing of ALL data in person, and have separate getters for the items
that you might want to print, like
std::cout
<< std::setw( 30 ) << person.name()
<< " lives at "
<< std::setw( 60 ) << person.adress();
This keeps *what* you want to print separate from *how* you want to
print it.
Wouter van Ooijen
== 7 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);
== 8 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
== 9 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" );
== 10 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.
== 11 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
== 12 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.
== 13 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
== 14 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.
== 15 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?
== 16 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
== 17 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«.
== 18 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
== 19 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
== 20 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
== 21 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
== 22 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.
== 23 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.
== 24 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
==============================================================================
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 6:49 am
From: drew@furrfu.invalid (Drew Lawson)
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.
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.
>bool foo(std::vector<int>::iterator b, std::vector<int>::iterator e, int)
>
>Of course if you want to make the function more generic you should
>templatize it so that it will accept iterators of any type of vector
>(or even any other data container.)
>
>--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
--
Drew Lawson
". . . And I never give a reason"
-- God, as channeled by Seven Nations
==============================================================================
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 */
};
==============================================================================
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