comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* IO problem - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/1627ad3e27ed2570?hl=en
* Working with Large Values (double) - 15 messages, 7 authors
http://groups.google.com/group/comp.lang.c++/t/e42843c9cdf13724?hl=en
* hw to get started - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/1a1994fe83f96e2f?hl=en
* 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? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/d7a4099890dfa4ed?hl=en
* Flummoxed - Please Help! - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/d4b5a6ac1e14e414?hl=en
==============================================================================
TOPIC: IO problem
http://groups.google.com/group/comp.lang.c++/t/1627ad3e27ed2570?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Feb 23 2014 6:39 am
From: James Kanze
On Wednesday, February 19, 2014 2:29:18 PM UTC, nvangogh wrote:
> I have come to a question in C++ Primer (p 314 , exercise 8.1) that is
> not clear to me.
> "Write a function that takes and returns an istream&. The function
> should read the stream until it hits end-of-file. The function should
> print what it reads to the standard output. Reset the stream so that it
> is valid before returning the stream."
This doesn't sound to clear to me either. For the most part,
istream input is formatted, so a lot of the characters don't
appear. I'm not too sure what you're supposed to be reading.
If it's ints, for example:
int i;
while ( file >> i && ! file.eof() ) {
if ( ! file ) {
file.clear();
file.ignore(); // but what, and how far?
} else {
std::cout << i << std::endl;
}
}
But of course, this will not reproduce the white space of the
original file. Otherwise:
std::cout << file.rdbuf();
sounds like the complete solution to the problem (but it's not
the sort of answer I'd expect from an introductory text).
> Breaking this down, the function has to do three things:
> 1. Read a stream until it hits end-of-file
Which is already a bit questionable. Normally, you read until
the read fails. Which can be because of end-of-file, but can
also be for other reasons.
> So the >> operator reads input from an istream object - cin.
> This stream's end of file can be interrogated by
> cin.eof().
Not really. The eof function is a bit tricky, in that its
return value reflects, or can reflect, internal state which
isn't well defined. Generally, you would never use cin.eof()
until input had failed.
> This returns true if the end of file bit is set which can be
> tested with a bool variable
> bool on = false;
> on = cin.eof();
> if(on == true)
> // end of file is reached, else
> if(on ==false)
> // keep reading cin
> I don't believe that this is completely correct so can someone show me
> how this code should be presented?
It's not completely correct, or at least, it's not complete.
cin.eof() does return the status of the eofbit. But when the
eofbit is set depends on a number of things, and it isn't
reliable unless an input has failed (and not always then).
The usual idiom is:
while ( std::cin >> something ) // ...
or (for lines):
while ( std::getline( std::cin, line ) // ...
(where line has type std::string).
After failure, you can use std::cin.eof() to determine whether
the failure is due to end of file, or something else. (In the
case of std::getline, it will almost certainly be end of file.)
> 2. Print what is read to the standard output
> I can only imagine this to be cout << ? But am lost from here
std::cout << will do the trick. But in the two while loops
above, the >> operator or getline will have removed characters
(white space or the new line character )from the input, that you
won't ever see.
The one exception is << from a streambuf. Using it is the
idiomatic way of copying one stream to another in C++. But it
represents a special case, which violates most of the usual
rules.
> 3. Reset the stream so it is valid before returning the stream
> This section of the problem again defeats me.
Again, it's not clear what this is supposed to mean. If the
input stream is a file (e.g. std::cin), there's practically no
way of doing this. std::cin.clear() will set the state to
good(), but since you've seen end of file, the next read will
immediately fail (or not, depending on the
implementation---there's a lot which isn't well defined here).
Or... it may mean you have to rewind (seek to the beginning of
the file). But this won't be possible if the input is from a
keyboard. And of course, if you've used std::cout <<
file.rdbuf(), the input stream won't have seen anything, and
will still be in its orginal state (but trying to read from it
will still fail, because the underlying streambuf is at end of
file).
--
James
==============================================================================
TOPIC: Working with Large Values (double)
http://groups.google.com/group/comp.lang.c++/t/e42843c9cdf13724?hl=en
==============================================================================
== 1 of 15 ==
Date: Sun, Feb 23 2014 6:46 am
From: jacob navia
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;
Of course C has ONE of the worst designs. But C++ has THE WORST!
:-)
jacob
== 2 of 15 ==
Date: Sun, Feb 23 2014 10:09 am
From: woodbrian77@gmail.com
On Sunday, February 23, 2014 8:46:10 AM UTC-6, 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;
>
> Of course C has ONE of the worst designs. But C++ has THE WORST!
>
We've discussed this a hundred times. They both have
weaknesses. The poor performance of iostream implementations
is on my list as far as the C++ weaknesses.
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
== 3 of 15 ==
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 ---
== 4 of 15 ==
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 ); }
== 5 of 15 ==
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 ); }
== 6 of 15 ==
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
== 7 of 15 ==
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.
== 8 of 15 ==
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.
== 9 of 15 ==
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
== 10 of 15 ==
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++.
== 11 of 15 ==
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
== 12 of 15 ==
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
== 13 of 15 ==
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
== 14 of 15 ==
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.
== 15 of 15 ==
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
==============================================================================
TOPIC: hw to get started
http://groups.google.com/group/comp.lang.c++/t/1a1994fe83f96e2f?hl=en
==============================================================================
== 1 of 4 ==
Date: Sun, Feb 23 2014 7:12 am
From: Victor Bazarov
On 2/23/2014 4:20 AM, erson212 wrote:
> Please can some 1 tell me hw to get started with c++, first tin to du
>
Since C++ is an exact language (has a grammar, keywords that need to be
spelled correctly, and is case-sensitive), the first thing to do is to
*commit* to doing it and doing it *properly*. You can demonstrate that
you have achieved the first stage when you learn to use proper grammar,
syntax, punctuation in *all* that you write, *including* any posts on
Usenet. Can you do that?
V
--
I do not respond to top-posted replies, please don't ask
== 2 of 4 ==
Date: Sun, Feb 23 2014 9:49 am
From: woodbrian77@gmail.com
On Sunday, February 23, 2014 3:20:06 AM UTC-6, erson212 wrote:
> Please can some 1 tell me hw to get started with c++, first tin to du
Buy a book or two. Get access to at least one C++ compiler.
Linux makes it fairly easy to use several compilers. You're
also welcome to download the archive on my website;
http://webEbenezer.net/build_integration.html
I've been working on the software there since 1999.
I recall Jorgen mentioning in a similar question the need
to write and read a lot of software. That's right I suppose.
Brian
Ebenezer Enterprises - So far G-d has helped us.
http://webEbenezer.net
== 3 of 4 ==
Date: Sun, Feb 23 2014 10:36 am
From: ram@zedat.fu-berlin.de (Stefan Ram)
Victor Bazarov <v.bazarov@comcast.invalid> writes:
>On 2/23/2014 4:20 AM, erson212 wrote:
>>Please can some 1 tell me hw to get started with c++, first tin to du
>Since C++ is an exact language (has a grammar, keywords that need to be
>spelled correctly, and is case-sensitive), the first thing to do is to
>*commit* to doing it and doing it *properly*. You can demonstrate that
>you have achieved the first stage when you learn to use proper grammar,
>syntax, punctuation in *all* that you write, *including* any posts on
>Usenet. Can you do that?
»While sloppy writing does not invariably mean sloppy
thinking, we've generally found the correlation to be
strong -- and we have no use for sloppy thinkers.
If you can't yet write competently, learn to.«
Eric Raymond
http://www.catb.org/~esr/faqs/hacker-howto.html#skills4
»Besides a mathematical inclination, an exceptionally
good mastery of one's native tongue is the most vital
asset of a competent programmer.«
Edsgar Dijkstra
»I've found that some of the best [Software ]developers
of all are English majors. They'll often graduate with
no programming experience at all, and certainly without
a clue about the difference between DRAM and EPROM.
But they can write. That's the art of conveying
information concisely and clearly. Software development
and writing are both the art of knowing what you're going
to do, and then lucidly expressing your ideas.«
Paul Potts
http://praisecurseandrecurse.blogspot.com/2007/03/english-majors-as-programmers.html
»The narrative measures of conjunction use, event
content, perspective shift, and mental state reference
were significantly predictive of later Math scores.«
http://www.arts.uwaterloo.ca/%7Edoneill/papers/Storytelling%20and%20math.pdf
»I have never, ever, ever seen a great software developer
who does not have amazing attention to detail.«
http://www.softwarebyrob.com/articles/Personality_Traits_of_the_Best_Software_Developers.aspx
== 4 of 4 ==
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?
==============================================================================
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 1 ==
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 ---
==============================================================================
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.
==============================================================================
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