const BUGS me down!

[puzzlecracker]

I am sure all of you are familier with this example from effective C++:
What exactly is the problem and more IMPRTANTLY why?
is there something (more like everything) I don't understand about
"string" ? I have been having some problems with this in my own code as
well. THX

String someFamousAuthor() // randomly chooses and
{ // returns an author's name
switch (rand() % 3) { // rand() is in <stdlib.h>
// (and <cstdlib> - see
// Item 49)
case 0:
return "Margaret Mitchell"; // Wrote "Gone with the
// Wind," a true classic
case 1:
return "Stephen King"; // His stories have kept
// millions from sleeping
// at night
case 2:
return "Scott Meyers"; // Ahem, one of these
} // things is not like the
// others...
return ""; // we can't get here, but
// all paths in a value-

 

[Karl Heinz Buchegger]

I am sure all of you are familier with this example from effective C++:

Please don't assume that.
Even if you assume that give more information about what you are
referring to. "Effective C++" contians a lot of things. So which
item are you referring to?

What exactly is the problem and more IMPRTANTLY why?

Well. What are the smyptoms?
What error message do you get?

is there something (more like everything) I don't understand about
"string" ? I have been having some problems with this in my own code as
well. THX

String someFamousAuthor() // randomly chooses and

There is no such class called 'String' in standard C++

 

[Ioannis Vranos]

I am sure all of you are familier with this example from effective C++:

All those who have read it.

What exactly is the problem and more IMPRTANTLY why?
is there something (more like everything) I don't understand about
"string" ? I have been having some problems with this in my own code as
well. THX

String someFamousAuthor() // randomly chooses and

I assume you want it to be string someFamousAuthor()

{ // returns an author's name
switch (rand() % 3) { // rand() is in <stdlib.h>
// (and <cstdlib> - see
// Item 49)
case 0:
return "Margaret Mitchell"; // Wrote "Gone with the
// Wind," a true classic
case 1:
return "Stephen King"; // His stories have kept
// millions from sleeping
// at night
case 2:
return "Scott Meyers"; // Ahem, one of these
} // things is not like the
// others...
return ""; // we can't get here, but
// all paths in a value-

What is the problem here?

 

[Ron Natalie]

I am sure all of you are familier with this example from effective C++:
What exactly is the problem and more IMPRTANTLY why?
is there something (more like everything) I don't understand about
"string" ? I have been having some problems with this in my own code as
well. THX

String someFamousAuthor() // randomly chooses and

The class is "string" not String.

{ // returns an author's name
switch (rand() % 3) { // rand() is in <stdlib.h>
// (and <cstdlib> - see
// Item 49)

Look up srand.

 

[Ron Natalie]

I am sure all of you are familier with this example from effective C++:
What exactly is the problem and more IMPRTANTLY why?
is there something (more like everything) I don't understand about
"string" ? I have been having some problems with this in my own code as
well. THX

String someFamousAuthor() // randomly chooses and
{ // returns an author's name
switch (rand() % 3) { // rand() is in <stdlib.h>
// (and <cstdlib> - see
// Item 49)
case 0:
return "Margaret Mitchell"; // Wrote "Gone with the
// Wind," a true classic
case 1:
return "Stephen King"; // His stories have kept
// millions from sleeping
// at night
case 2:
return "Scott Meyers"; // Ahem, one of these
} // things is not like the
// others...
return ""; // we can't get here, but
// all paths in a value-

 

[Howard]

All those who have read it.

And remember everything they've read.

It's not talking about "string", it's talking about "String", the class he's
demonstrating a problem with.

I assume you want it to be string someFamousAuthor()

(No..actually, that's a class Mr. Meyers has defined to help demonstrate the
point he's trying to make.)

What is the problem here?

To the OP (puzzlecracker)...did you read all of the text associated with
that example (Item 29 in Effective C++)? It explains the whole issue pretty
well, I thought.

The problem is related to the String class definition, and this example
demonstrates the dangers of allowing a user to obtain a pointer to internal
data of an object (the temporary String object returned by the function, in
this case).

Read the whole item again. And notice that it's *not* that function that's
the problem, but rather the method chosen to return the internal character
data (see the String class definition in that item), which makes it possible
for a calling function to attempt to refer to internal data which may
already have been destroyed.

-Howard

 

[puzzlecracker]

it describes the consequences but not the problem:

""""""""""
Now consider this use of someFamousAuthor, in which we assume that
String declares an operator const char* member function as described
above: ¤ Item E29, P25

const char *pc = someFamousAuthor();
cout << pc; // uh oh...
""""""""""""


for smart ones: there is NO NO NO class called string - - string is
actually a typedef for an instantiation of a class template. And to
make it clearer:

namespace std {
template<class charT, class traits =
char_traits<charT>,
class Allocator=allocator<charT> >
class basic_string;

;
typedef basic_string<char> string;
}

 

[Howard]

it describes the consequences but not the problem:

Read the entire item, including the text *before* that example. It does
explain the problem. It's the operator() that returns a char* which
provides a "handle" to the internal data member. That's what he's saying
you need to avoid.


""""""""""
Now consider this use of someFamousAuthor, in which we assume that
String declares an operator const char* member function as described
above: $ Item E29, P25

const char *pc = someFamousAuthor();
cout << pc; // uh oh...
""""""""""""


for smart ones: there is NO NO NO class called string - - string is
actually a typedef for an instantiation of a class template. And to
make it clearer:

namespace std {
template<class charT, class traits =
char_traits<charT>,
class Allocator=allocator<charT> >
class basic_string;

;
typedef basic_string<char> string;
}

--------------

Umm, ok. And your point is? There is a template class. The template has
an instantiation, which is thus a class. And a typedef provides an alias
for that class. So std::string is a class, which happens to be an
instantiation of a template class. So what's the problem?

-Howard

 

[Karl Heinz Buchegger]

it describes the consequences but not the problem:

Huch. How come?
If I read that item, it clearly says what the problem is.
It also tells you how this problem arises (the sequence of
events that lead to that problem) and what you can do about it:

<Quote>
Believe it or not, you can't predict what this code will do, at least not with any certainty.
That's because by the time you try to print out the sequence of characters pointed to by pc,
that sequence is undefined. The difficulty arises from the events that transpire during the
initialization of pc: ¤ Item E29, P26

A temporary String object is created to hold someFamousAuthor's return value. ¤ Item E29, P27
That String is converted to a const char* via String's operator const char* member function,
and pc is initialized with the resulting pointer. ¤ Item E29, P28
The temporary String object is destroyed, which means its destructor is called. Within the
destructor, its data pointer is deleted (the code is shown in Item 11). However, data points
to the same memory as pc does, so pc now points to deleted memory — memory with undefined
contents. ¤ Item E29, P29

Because pc was initialized with a handle into a temporary object and temporary objects are
destroyed shortly after they're created, the handle became invalid before pc could do
anything with it. For all intents and purposes, pc was dead on arrival. Such is the
danger of handles into temporary objects. ¤ Item E29, P30

For const member functions, then, returning handles is ill-advised, because it violates
abstraction. Even for non-const member functions, however, returning handles can lead
to trouble, especially when temporary objects get involved. Handles can dangle, just
like pointers, and just as you labor to avoid dangling pointers, you should strive to
avoid dangling handles, too. ¤ Item E29, P31

Still, there's no reason to get fascist about it. It's not possible to stomp out all
possible dangling pointers in nontrivial programs, and it's rarely possible to eliminate
all possible dangling handles, either. Nevertheless, if you avoid returning handles when
there's no compelling need, your programs will benefit, and so will your reputation. ¤ Item E29, P32