Invisible <voi### [at] devnull> wrote:
> The tutorial recommends the C function atoi() - which, being a C 
> function, is about as user-friendly as Windows 2. Much hair-pulling 
> involving pointers ensues.

  No need for atoi(). You can use stringstreams, as I wrote in the other
post.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   No need for atoi(). You can use stringstreams, as I wrote in the other
> post.

I did think using a C function seemed a little bogus.

(For one thing, AFAIK, there is *no way* to know whether atoi() 
succeeded or failed; if it "fails", you get a zero. So was the string 
actually a zero, or did the conversion fail??)

Post a reply to this message

>> Ooo... I didn't realise you could do that. (Pass a const reference, that 
>> is.) So that means, what? If you accidentally try to change it, you'll 
>> get a compiler warning?
> 
>   No, you get a compiler error.

Even better.

>   Declaring everything you don't intend to modify as 'const' is a good
> programming practice in C++ for many reasons:
> 
> 1) If you don't intend to modify the parameter, very especially if the
>    parameter is a reference (in which case you would be modifying the
>    original rather than a copy), then you will get a compiler error if
>    you try to modify it anyways. This will catch programming mistakes
>    at compile time, which is a good thing.
> 
> 2) Declaring a reference parameter as 'const' is self-documenting: You are
>    not only telling the compiler that that parameter is not modified in the
>    function, more importantly you are telling that to a human reader. In
>    other words, you are effectively documenting that the parameter is a
>    pure input parameter, not something the function uses to pass values
>    to the calling code.
> 
> 3) As a bonus, it is possible that in certain situations the compiler might
>    be able to optimize const variables better than non-const ones.

Agreed.

>   Note that (not surprisingly) pointers are slightly more complicated
> with regard to 'const':
> 
>     const Type* ptr = something;
> 
>   This defines a pointer named 'ptr' which points to a const value.
> In other words, you can't modify the value pointed by 'ptr'. However,
> you can modify 'ptr' itself, to make it point somewhere else (or make
> it null, of whatever).
> 
>   If what you want is for 'ptr' itself to be const, not the value it's
> pointing to, you have to write it like this:
> 
>     Type* const ptr = something;
> 
>   Now you can modify the value pointed by 'ptr' but you can't modify 'ptr'
> itself. Naturally if you want *both* things, you write:
> 
>     const Type* const ptr = something;
> 
>   Now you can't modify either 'ptr' nor the value it's pointing to.
> 
>   References do not have this kind of complication because the reference
> variable itself is always const. What the 'const' keyword determines is
> whether the object it's pointing to is const or not.

...ouch. >_< OK, well let's hope I don't need to use pointers too much then!

>> Since you're here... do you happen to know the C++ name for stderr?
> 
>   std::cerr << "An error message.\n";

OK.

>   The problem with the >> operator is that you have to know in advance
> what the type of the input will be. In this case you don't know it because,
> as you say, the input can be an operator (+ or -) or a number.

Indeed.

>   What you can do is this:
> 
>     std::string s;
>     while(true)
>     {
>         std::cin >> s;
>         if(!std::cin.good()) break;
> 
>         int value;
>         std::istringstream iss(s);
>         iss >> value;
>         if(!iss.fail())
>             std::cout << "The input was an integer: " << value << "\n";
>         else
>             std::cout << "The input was something else: " << s << "\n";
>     }

...you mean, you can take a string and make a stream that will read from 
it? (Or, presumably, write to it, if you desire.) So what exactly do the 
good() and fail() functions do?

>>>> PS. Nano is a horrid, horrid text editor!
>>>   Why don't you use something better?
> 
>> Because my virtual machine is slow enough already without starting X11, 
>> and Nano is the only text-mode editor I have available (other than Vim 
>> and Emacs anyway).
> 
>   Why don't you use an editor in your host OS?

Because I haven't found a way to transfer files between the host OS and 
the guest OS.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> ...you mean, you can take a string and make a stream that will read from 
> it? (Or, presumably, write to it, if you desire.)

  Correct. Or, more precisely, you can write to an ostringstream and then
get a regular string out of it (with the str() function).

  Where this becomes fancy is when a function takes an std::istream or an
std::ostream reference, for example:

void readSomethingFrom(std::istream& is) { ... }
void writeSomethingTo(std::ostream& os) { ... }

  You can give those functions any of these things:

readSomethingFrom(std::cin);

std::ifstream inputFile("filename.txt");
readSomethingFrom(inputFile);

std::istringstream iss(someString);
readSomethingFrom(iss);

writeSomethingTo(std::cout);
writeSomethingto(std::cerr);

std::ofstream outputFile("filename.txt");
writeSomethingTo(outputFile);

std::ostringstream oss;
writeSomethingTo(oss);

  The functions themselves don't know (and don't need to know) what the
exact type of stream actually is. All of them are used in the same way.
For example:

void writeSomethingTo(std::ostream& os)
{
    for(int i = 0; i < 10; ++i)
        os << i << "\n";
}

  This is, in fact, pure object-oriented programming (all of those things
are inherited from std::istream or std::ostream, so they can be given to
those two functions). Beautiful.

> So what exactly do the good() and fail() functions do?

http://www.cplusplus.com/reference/iostream/ios/good.html
http://www.cplusplus.com/reference/iostream/ios/fail.html

  Basically you can think of good() as "did the last read succeed?"
(the most common reason for the stream to be not good() is EOF).
It's an overall "is the stream still good?".

  And fail() as "did the input contain a value of the correct type?".
In other words, with the "std::cin >> integer; if(std::cin.fail() ..."
you are asking "did reading an integer fail?". The most common reason
for fail() to be true is that input did not contain what was expected
by the parameter (in this example an integer value).

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Warp wrote:

> >   No need for atoi(). You can use stringstreams, as I wrote in the other
> > post.

> I did think using a C function seemed a little bogus.

  There's merit in those C functions, though: They are much more efficient
than using stringstreams. (For one, they parse the string *in place*,
rather than copying the string around in memory.)

  Of course their usage is more difficult.

> (For one thing, AFAIK, there is *no way* to know whether atoi() 
> succeeded or failed; if it "fails", you get a zero. So was the string 
> actually a zero, or did the conversion fail??)

  Another C function can be used to both parse an integer from a string
and know if there was one: strtod(). However, its usage is even more
complicated than atoi().

-- 
                                                          - Warp

Post a reply to this message

>> ...you mean, you can take a string and make a stream that will read from 
>> it? (Or, presumably, write to it, if you desire.)
> 
>   Correct. Or, more precisely, you can write to an ostringstream and then
> get a regular string out of it (with the str() function).

Ah  - because a string is fixed-size once created?

>   Where this becomes fancy is when a function takes an std::istream or an
> std::ostream reference.
>   The functions themselves don't know (and don't need to know) what the
> exact type of stream actually is. All of them are used in the same way.
>   This is, in fact, pure object-oriented programming (all of those things
> are inherited from std::istream or std::ostream, so they can be given to
> those two functions). Beautiful.

OOP as it should be.

>> So what exactly do the good() and fail() functions do?
> 
> http://www.cplusplus.com/reference/iostream/ios/good.html
> http://www.cplusplus.com/reference/iostream/ios/fail.html
> 
>   Basically you can think of good() as "did the last read succeed?"
> (the most common reason for the stream to be not good() is EOF).
> It's an overall "is the stream still good?".
> 
>   And fail() as "did the input contain a value of the correct type?".
> In other words, with the "std::cin >> integer; if(std::cin.fail() ..."
> you are asking "did reading an integer fail?". The most common reason
> for fail() to be true is that input did not contain what was expected
> by the parameter (in this example an integer value).

OK... So good() is a property of the stream, and fail() is a property of 
the last thing read from it?

Post a reply to this message

Invisible wrote:

> Also, there's an interesting glitch where the program won't continue if 
> you enter a blank line - you must enter *something* or the program won't 
> continue. Presumably this is just the defined behaviour of the >> 
> operator...

	If you DO want to read a whole line, look up the getline function. That 
will also take in an "empty" line.

-- 
Inoculatte: To take coffee intravenously when you are running late.


                     /\  /\               /\  /
                    /  \/  \ u e e n     /  \/  a w a z
                        >>>>>>mue### [at] nawazorg<<<<<<
                                    anl

Post a reply to this message

Warp wrote:

>   What you can do is this:
> 
>     std::string s;
>     while(true)
>     {
>         std::cin >> s;
>         if(!std::cin.good()) break;
> 
>         int value;
>         std::istringstream iss(s);
>         iss >> value;
>         if(!iss.fail())
>             std::cout << "The input was an integer: " << value << "\n";
>         else
>             std::cout << "The input was something else: " << s << "\n";
>     }

"Variable 'iss' has initialiser but has incomplete type."

WTF...?

Oh, wait, I see. That means "you didn't include <sstream>". Well, that 
was quite clear. o_O

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Spot the mistake:

int foo(vector<int>& stack)
{
   int x = stack.back();
   stack.pop_back();
}

For reasons I can't begin to understand,

1. This doesn't produce any compile-time error.

2. This function always returns the value "2144912088".

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
>>> PS. Nano is a horrid, horrid text editor!
>>
>>   Why don't you use something better?
> 
> Because my virtual machine is slow enough already without starting X11, 
> and Nano is the only text-mode editor I have available (other than Vim 
> and Emacs anyway).

Well, that made *me* laugh.

"Nano is awful. I have nothing better. Oh, except the two most popular 
text editors."

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message