comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* implicit passing by reference - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/dddf6db3d26e03e4?hl=en
* Iterator pair as a function argument? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/d7a4099890dfa4ed?hl=en
* Working with Large Values (double) - 18 messages, 7 authors
http://groups.google.com/group/comp.lang.c++/t/e42843c9cdf13724?hl=en
* Flummoxed - Please Help! - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/d4b5a6ac1e14e414?hl=en
* hw to get started - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/1a1994fe83f96e2f?hl=en
==============================================================================
TOPIC: implicit passing by reference
http://groups.google.com/group/comp.lang.c++/t/dddf6db3d26e03e4?hl=en
==============================================================================
== 1 of 4 ==
Date: Sun, Feb 23 2014 1:10 pm
From: jerry.jeremiah@gmail.com
On Friday, February 21, 2014 6:42:57 PM UTC+13, Paavo Helde wrote:
>
> In C++ the function declarations specify exactly if the pass is by value or by reference. The people at stackoverflow probably have confused C++ with some other language. Do not take stackoverflow too seriously, the answers there are ranked by the person least qualified to judge the correctness.
>
> Cheers
>
> Paavo
I *knew* it was wrong. What I didn't know what that stackoverflow was so unreliable (I have had good luck until now)
Thanks very much for all the advice.
Jerry
== 2 of 4 ==
Date: Sun, Feb 23 2014 3:14 pm
From: Paavo Helde
jerry.jeremiah@gmail.com wrote in
news:65747709-69b4-44bb-8494-63b1a68366c5@googlegroups.com:
> What I didn't know what that stackoverflow was
> so unreliable (I have had good luck until now)
I have asked some questions myself there, and the system soon insisted me
me to select THE answer. How would I know which, if any, of the proposed
third-party libraries is of any good? It becomes clear only after a couple
of years of eperience, possibly only after when the poor
customers^H^H^H^H^H^H^H^H^Hbeta-testers have filed their multi-threading
and other bug reports.
Cheers
Paavo
== 3 of 4 ==
Date: Sun, Feb 23 2014 7:30 pm
From: Daniel
On Sunday, February 23, 2014 9:13:29 AM UTC-5, James Kanze wrote:
>
> The highest ranked answers are rarely the correct ones.
>
Speaking as someone with a stackoverflow reputation of 81,234, so some votes must have hit the target :-)
Daniel
== 4 of 4 ==
Date: Mon, Feb 24 2014 2:57 am
From: Stuart
On 02/23/14, Stefan Ram wrote:
>
> Read the post »Welcome Slashdot refugees!« of February 6 in
> the newsgroup »comp.misc« and the following posts to witness
> the return of Slashdot users to Usenet.
>
I took your advice and I stumbled upon this posting,
<ldcp5b$ct9$1@speranza.aioe.org>, where the poster said that newsgroups
needed somehow be improved by some rating system in order to sort out
irrelevant or rather uninteresting postings.
I don't think that this is necessary. If you follow the newsgroup for a
while, you get to know people. Whenever I see either Alf, Bart, Bo, Ian,
James Kanze, Jorgen, Joshua Cramner, Juha, Paavo, Öö, yourself, Tobias
Müller, Ulrich, or Victor (in alphabetical order), I know that this
posting is worth reading.
Brian, Quall, and even Mr. Flibble make some interesting contributions,
although these are often buried in a mass of off-topic ramblings.
Regards,
Stuart
==============================================================================
TOPIC: Iterator pair as a function argument?
http://groups.google.com/group/comp.lang.c++/t/d7a4099890dfa4ed?hl=en
==============================================================================
== 1 of 2 ==
Date: Mon, Feb 24 2014 3:12 am
From: Juha Nieminen
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?
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 ---
== 2 of 2 ==
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: Working with Large Values (double)
http://groups.google.com/group/comp.lang.c++/t/e42843c9cdf13724?hl=en
==============================================================================
== 1 of 18 ==
Date: Mon, Feb 24 2014 3:32 am
From: Juha Nieminen
jacob navia <jacob@spamsink.net> wrote:
> Of course C has ONE of the worst designs. But C++ has THE WORST!
The C version is not type safe, cannot be expanded with new types, and
has poor abstraction, while the C++ version has all of those.
Just as an example of that, assume you have in one file
typedef int Integral;
and in another something along the lines of
void foo(Integral i)
{
printf("???", i); // What to put here?
}
If you put "%i" there, it will break if 'Integral' is ever changed to
a bigger or incompatible type.
With luck, the compiler will give you warnings for the format string
not matching the parameter types, so you can manually go and fix all
the instances. Excellent programming technique.
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
== 2 of 18 ==
Date: Mon, Feb 24 2014 4:04 am
From: ram@zedat.fu-berlin.de (Stefan Ram)
Juha Nieminen <nospam@thanks.invalid> writes:
>Just as an example of that, assume you have in one file
>typedef int Integral;
#include <iostream>
struct integer{ int value; void print(); };
void integer::print(){ ::std::cout << value; }
int main(){ integer i ={ 2 }; i.print(); }
#include <stdio.h>
struct integer
{ int value; void( * print )( struct integer * this ); };
void print( struct integer * this ){ printf( "%d", this->value ); }
int main(){ struct integer i ={ 2, print }; i.print( &i ); }
== 3 of 18 ==
Date: Mon, Feb 24 2014 4:30 am
From: ram@zedat.fu-berlin.de (Stefan Ram)
Supersedes: <OOP-20140224130338@ram.dialup.fu-berlin.de>
Juha Nieminen <nospam@thanks.invalid> writes:
>Just as an example of that, assume you have in one file
>typedef int Integral;
#include <iostream>
struct integer{ int value; void print(); };
void integer::print(){ ::std::cout << value; }
int main(){ integer i ={ 2 }; i.print(); }
#include <stdio.h>
struct integer{ int value; void( * print )( struct integer * ); };
void print( struct integer * this ){ printf( "%d", this->value ); }
int main(){ struct integer i ={ 2, print }; i.print( &i ); }
== 4 of 18 ==
Date: Mon, Feb 24 2014 5:14 am
From: Gerhard Fiedler
jacob navia wrote:
> Le 23/02/2014 14:59, James Kanze a écrit :
>> 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.
>>
>
> Of course. For instance in the evil C language you use:
>
> printf("0x%08x\n", x);
>
> In the much more advanced C++ language you use:
>
> std::cout << std::hex << std::setfill('0') << std::setw(8) << x <<
> std::dec << std::endl;
If you have a need to print this more often than once, then there are
other language features that you can use to encapsulate all this.
There are also libraries that use C++ features to provide something
similar in ways that avoid some of the problems of built-in streams.
OTOH, (type-safely) encapsulating printf is quite the challenge.
Gerhard
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
== 5 of 18 ==
Date: Mon, Feb 24 2014 5:24 am
From: ram@zedat.fu-berlin.de (Stefan Ram)
Gerhard Fiedler <gelists@gmail.com> writes:
>jacob navia wrote:
>>Of course. For instance in the evil C language you use:
>>printf("0x%08x\n", x);
>There are also libraries that use C++ features to provide something
>similar in ways that avoid some of the problems of built-in streams.
You both sound a little bit as if it were not possible to use
printf in C++.
>OTOH, (type-safely) encapsulating printf is quite the challenge.
Sometimes, language support for OOP or generic programming is better.
I don't think anyone would deny this.
But sometimes, printf is more readable and writeable. That's why, in
2004, they have added printf to the Java programming language after
Java already had formatted printing right from the start in 1995, but
using a call-style interface instead of a DSL like printf.
== 6 of 18 ==
Date: Mon, Feb 24 2014 5:29 am
From: jacob navia
Le 24/02/2014 12:32, Juha Nieminen a écrit :
> The C version is not type safe
Most modern C compilers will warn if you pass an incorrect type to
printf. please, no straw men here.
== 7 of 18 ==
Date: Mon, Feb 24 2014 5:49 am
From: jacob navia
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.
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".
Maybe you would stop doing that?
After 20 years of insults and lies, you have won. You have destroyed the
C language to the point that the C standards committee doesn't dare to
prescrive something for fear it would bother the C++ language, or make a
comptetition with C++. Thus, C has stagnated, nothing is being developed
and all efforts go to C++.
Look, now you have anonymous lambdas and all common lisp in your language.
Why go on pounding C?
Is it not enough already?
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.
Just stop denigrating C.
Thanks in advance
jacob
== 8 of 18 ==
Date: Mon, Feb 24 2014 5:58 am
From: ram@zedat.fu-berlin.de (Stefan Ram)
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++.
== 9 of 18 ==
Date: Mon, Feb 24 2014 6:14 am
From: jacob navia
Le 24/02/2014 14:58, Stefan Ram a écrit :
> 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 )
>
With a consistent naming convention I do not see how this could ever be
a problem.
print_xxx(XXX *data);
is quite easy to use, remember, etc, the same as <<.
> 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++.
>
As far as I remember C++ is statically typed language, i.e. everything
is known at compile time. Objective C, is not, and you use the method
lookup of the language to figure out dynamically what "print" function
would be called. There is no method lookup in c++ so the compiler
generates in the case of a virtual function a lookup in a specific class
hierarchy that must be given to it at compile time. True, there is a
genericity here that is not there in C.
Do I need that?
How much does that costs me in memory area in my cramped brain?
Do I want that?
Those are questions that everyone answers as he/she likes/must.
I would not blame anyone for choosing C++, I have even worked debugging
C++, everyone must try to feed his/her family somehow.
What bothers me precisely is this lack of respect from C++ programmers
that believe that because they have mastered some c++ trivialities they
are better than people that do not care about them.
Look at how java programmers are laughed at here. Or Fortran
programmers, or whatever. It is this attitude, this lack of respect that
I question.
Thanks
== 10 of 18 ==
Date: Mon, Feb 24 2014 6:14 am
From: Victor Bazarov
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.
Too bad. Perhaps you can read more about overloading, it's one
important feature of C++ that sets it aside from C.
> But I am afraid you will never be convinced (of course). [..]
You took the words right out of my mouth (fingertips)... :-)
V
--
I do not respond to top-posted replies, please don't ask
== 11 of 18 ==
Date: Mon, Feb 24 2014 6:21 am
From: Wouter van Ooijen
jacob navia schreef op 24-Feb-14 3:14 PM:
>> ... << x ...
>> ... << i ...
>
> There is no method lookup in c++ so the compiler
> generates in the case of a virtual function a lookup in a specific class
> hierarchy that must be given to it at compile time. True, there is a
> genericity here that is not there in C.
For the simple case of <<'ing a value no virtual function lookup is
needed, because the compiler knows the type of the rhs and hence which
method or function to call. A vft is needed only when the rhs is
(derived from) a base type that has a virtual << method.
Wouter van Ooijen
== 12 of 18 ==
Date: Mon, Feb 24 2014 6:30 am
From: jacob navia
Le 24/02/2014 15:14, Victor Bazarov a écrit :
> Perhaps you can read more about overloading, it's one important feature
> of C++ that sets it aside from C.
I have implemented function overloading in my compiler system lcc-win.
And true, I have read a lot of things about overloading, and also about
how overloading (like anything) can be ABUSED.
For example, the expression
String a,b,c;
c = a+b;
is an *abuse* of overloading.
Why?
Because there is no ADDITION being done when a and b are STRINGS but a
concatenation of two strings, what is *completely different*. If a and b
are strings we have
a+b != b+a
what goes against all the mathematical basis of addition as normal
people use that word.
That is why string "addition" is an ABUSE of overloading.
In the same vein, shifting left an object to print it just because the
opeartor << looks like the head of a left arrow or suggests "put into"
is NONSENSE and an abuse of the overloading concept.
This WRONG DESIGN DECISION is at the heart of a catastrophe in c++ i/o
as I showed in my example.
No, output has nothing to do (really *NOTHING*) with left shift, and the
whole concept precludes querying the state of the output machine,
precludes a simpler syntax, etc. This is so true that now there are C++
packages that output their data without operator overloading.
As I documented in the documentation of my compiler system, overloading
works best when used with NUMBERS or NUMERIC data. It is also a great
idea when used with arrays (overloading operator []). But in OTHER
applications it can be an incredibly BAD idea.
The world is a complex place and there is no magic bullets Mr Bazarov.
Things that are good in some contexts are BAD in another. Knives are
great for cutting bread, but they can cut your finger as easily too.
Beware!
:-)
jacob
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".
Thanks.
== 13 of 18 ==
Date: Mon, Feb 24 2014 6:34 am
From: jacob navia
Le 24/02/2014 15:21, Wouter van Ooijen a écrit :
> jacob navia schreef op 24-Feb-14 3:14 PM:
>
>>> ... << x ...
>>> ... << i ...
>>
>> There is no method lookup in c++ so the compiler
>> generates in the case of a virtual function a lookup in a specific class
>> hierarchy that must be given to it at compile time. True, there is a
>> genericity here that is not there in C.
>
> For the simple case of <<'ing a value no virtual function lookup is
> needed, because the compiler knows the type of the rhs and hence which
> method or function to call. A vft is needed only when the rhs is
> (derived from) a base type that has a virtual << method.
>
> Wouter van Ooijen
I know, I was speaking of the general case of course. In the << case the
compiler saves the programmer the effort of remembering the name of the
output function since all syntax is just <<.
As I said before, using a simple
print_xxx
naming convention makes this as easy to remember as the << syntax.
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?
jacob
== 14 of 18 ==
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.)
== 15 of 18 ==
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.
== 16 of 18 ==
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 :-)
== 17 of 18 ==
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
== 18 of 18 ==
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.
==============================================================================
TOPIC: Flummoxed - Please Help!
http://groups.google.com/group/comp.lang.c++/t/d4b5a6ac1e14e414?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Feb 24 2014 4:05 am
From: guinness.tony@gmail.com
On Tuesday, 18 February 2014 19:40:26 UTC, Mike Copeland wrote:
> I have the following (rather simple, I think) code which compiles but
> executes in a bizarre way: the code in the subprogram is skipped when
> called. 8<{{
> Here's the code and the call to it I use:
>
> string spellNumber(double value)
> {
> bool showThousands = false;
> bool allZeros = true;
> int ii, dPos, nn;
> char wc;
> string digits, temp;
> ostringstream ossw;
> static string builder;
> ossw.str("");
> ossw << value;
> digits = ossw.str();
> dPos = digits.find('.');
> if(dPos != string::npos) digits.erase(dPos);
> nn = digits.length();
> wc = digits.back();
> for(ii = digits.length()-1; ii >= 0; ii--)
> {
> int ndigit = (int)(digits[ii]-'0');
> int column = (digits.length()-(ii+1));
> } // for
> // more code to be added here
> return builder;
> }
> ...
> spellNumber(123.45); // call the function
>
> I have, of course the normal stdafx.h header and "use namespace
> std;", and this is code from a small test program I use to debug new
> functions and such. Many other programs and many thousands of lines of
> code work fine, but this code is weird...and I can't see what's wrong
> with it!
> Please advise... TIA
Your function returns a copy of the empty string named 'builder'.
Seeing this, the compiler can also determine that all the other code
has no observable external effect and is at liberty to ignore it.
==============================================================================
TOPIC: hw to get started
http://groups.google.com/group/comp.lang.c++/t/1a1994fe83f96e2f?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Feb 24 2014 4:20 am
From: guinness.tony@gmail.com
On Sunday, 23 February 2014 18:36:14 UTC, Stefan Ram wrote:
>
> »I've found that some of the best [Software ]developers
> of all are English majors. ...«
>
> Paul Potts
Now THAT's a very interesting correlation. Who would have
thought that high-ranking officers of our army would be
suited to be good software engineers?
==============================================================================
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