STL list code fires assertion in VC++ 2005, but not in VC++ 2003.

[Jason Doucette]

element cannot be compared to NULL.

Technically, that's always been the case.

Yes, I am aware of that. VC++ 7.1's implementation merely allowed me
to use them as pointers. I could just turn off VC++ 8.0's debug
warnings, but I'd rather code correctly, and leave all warnings on.

Jason

 

[Jason Doucette]

Yes, the caller does have access to the list, so returning end() is an

It's the usual solution when the user is aware of the list.
Another, more general solution is to use Barton and Nackman's
Fallible as a return value.


This sounds like something Fallible was designed for. The
client has no need to "know" anything about the list.

James, can you elaborate on Barton and Nackman's Fallible? I will
research it right now, since it sounds like what I need.

An issue that remains is that I have a pointer to the list. If the
pointer is NULL, the list doesn't even exist. Thus, I cannot return
myList.end() in such a case. (Incidentally, the reason I use a
pointer is so I can check the list's constructor for errors -- I am
very picky about error checking).

Thanks,
Jason

 

[Marcus Kwok]

An issue that remains is that I have a pointer to the list. If the
pointer is NULL, the list doesn't even exist. Thus, I cannot return
myList.end() in such a case. (Incidentally, the reason I use a
pointer is so I can check the list's constructor for errors -- I am
very picky about error checking).

The common idiom for constructor errors is to have the constructor throw
an exception.

 

[Jason Doucette]

The common idiom for constructor errors is to have the constructor throw

an exception.

Yes. A lot of code have STL containers as globals, seemingly
oblivious to the fact that their constructors are being run (even just
to create an empty list) without any code to catch that exception.

So, I use use a pointer to the list, and make that global, instead.
Then, the creation of the list can exist in code that catches any
constructor exceptions.

Jason

 

[Andre Kostur]

Yes. A lot of code have STL containers as globals, seemingly
oblivious to the fact that their constructors are being run (even just
to create an empty list) without any code to catch that exception.

So, I use use a pointer to the list, and make that global, instead.
Then, the creation of the list can exist in code that catches any
constructor exceptions.

Out of curiosity... what exception do you expect your list's constructor to
throw? (Assuming default constructor for the list)

 

[Kai-Uwe Bux]

Out of curiosity... what exception do you expect your list's constructor
to throw? (Assuming default constructor for the list)

It could throw a bad_alloc. If the list uses an extra node as the past_end
node, the pointer to which is returned by end(), then there could be an
allocation even for the empty list.


Best

Kai-Uwe Bux

 

[James Kanze]

James, can you elaborate on Barton and Nackman's Fallible? I will
research it right now, since it sounds like what I need.

It's the "standard" solution anytime a function might not be
able to return a legitimate value. In its simplest form:

template< typename T >
class Fallible
{
public:
Fallible()
: myIsValid( false )
{}
Fallible( T const& value )
: myIsValid( true )
, myValue( value )
{}

bool isValid() const
{
return myIsValid ;
}

T const& value() const
{
assert( myIsValid ) ;
return myValue ;
}
private:
bool myIsValid ;
T myValue ;
} ;

For a version with all sorts of bells and whistles (and which
really goes beyond the concept of Fallible, and should probably
be several different classes), see the code at my site
(kanze.james.neuf.fr//code-en.html---subsystem Basic, component
Fallible). The one extension there that you probably do want is
the member function "elseDefaultTo()"; the rest is really
support for other uses.

 

[Jason Doucette]

Out of curiosity... what exception do you expect your list's constructor to

throw? (Assuming default constructor for the list)

std::bad_alloc is the C++ standard for out of memory exceptions, which
is what the STL uses. Actually, it doesn't specifically use it, it's
just uses C++'s new internally, and this throws std::bad_alloc when it
fails, so the STL throws std::bad_alloc as a result.

Be cautious if you're using VC++ 6.0 or earlier since, without proper
attention, the default behaviour doesn't match the C++ standard; it
returns NULL.

Jason