Help with strange (for me) STL problem that disappers when rebuilding all

[StephQ]

I have a class Bounds with two constructors:

class Bounds
{
private:

list<Segment> upperLinearSpline; // Upper bound.
list<Segment> lowerLinearSpline; // Lower bound.
....

}


Bounds::Bounds()
{
}

Bounds::Bounds(double lo, double up)
{
lowerLinearSpline.push_back( Segment(Point(0, lo), 0, -HUGE_VAL,
HUGE_VAL) );

upperLinearSpline.push_back( Segment(Point(0, up), 0, -HUGE_VAL,
HUGE_VAL) );
}


Segment is another class with default constructor.
I have not defined destructors, copy constructor and copy assignement.
So the automatic membewise-copy should be used.

The class Bounds appears in other classes in the construtors as or/and
as reference member data like
.....
private:
const Bounds& bounds;
....

Until here everything is working fine.

Now I write code for another class in which Bounds appears only in the
constructor as (not as member data) like:
UniformEnvelope::UniformEnvelope(const Bounds& bounds, .......

and what happends is that when I add the source code and header file
of this new class and compile normally the constructor
Bounds::Bounds(double lo, double up) stop working.
In debug mode I get no error/exceptio at all but I notice that the
push_back() is not working correctly. It does not report any error but
if simply fails to insert the value.

If it is of any help looking in the standart template library the
function failed to insert (does not return error/exception but after
this call in (*this) i see: "(error) 0" as unique element using the
debugger) is _Incsize(1) in:

void _Insert(iterator _Where,
const _Ty& _Val)
{ // insert _Val at _Where

#if _HAS_ITERATOR_DEBUGGING
if (_Where._Mycont != this)
_DEBUG_ERROR("list insert iterator outside range");
#endif /* _HAS_ITERATOR_DEBUGGING */

_Nodeptr _Pnode = _Where._Mynode();
_Nodeptr _Newnode = _Buynode(_Pnode, _Prevnode(_Pnode), _Val);
_Incsize(1);
_Prevnode(_Pnode) = _Newnode;
_Nextnode(_Prevnode(_Newnode)) = _Newnode;
}

in the <list> file.

The very strange thing (for me at least) is that recompiling the whole
project solves the problem.
Do you have any idea of what the problem could be and how could I
check it?

Thank you
StephQ

 

[BobR]

I have a class Bounds with two constructors:

class Bounds{ private:
list<Segment> upperLinearSpline; // Upper bound.
list<Segment> lowerLinearSpline; // Lower bound.
...

// > }

};

Your problem is right here: You need a semicolon!

void _Insert(iterator _Where,

A leading underscore followed by a capital letter is reserved to the
implementation (so are double underscores), you should NOT use them.

The very strange thing (for me at least) is that recompiling the whole
project solves the problem.
Do you have any idea of what the problem could be and how could I
check it?
Thank you StephQ

If you have two files in your project, A.cpp and B.cpp, and B.cpp uses
something from A.cpp, and you change something in the interface in A.cpp,
you need to re-compile BOTH(all) files.
It's NOT a problem, it's how 'make/link' works (it only compiles files that
have changed since the last (full) compile).

 

[Salt_Peter]

I have a class Bounds with two constructors:

class Bounds
{
private:

list<Segment> upperLinearSpline; // Upper bound.
list<Segment> lowerLinearSpline; // Lower bound.
...

}

Bounds::Bounds()
{

}

Bounds::Bounds : upperLinearSpline(), lowerLinearSpline()
{
}

same goes for the parametized ctor...

Bounds::Bounds(double lo, double up)
{
lowerLinearSpline.push_back( Segment(Point(0, lo), 0, -HUGE_VAL,
HUGE_VAL) );

upperLinearSpline.push_back( Segment(Point(0, up), 0, -HUGE_VAL,
HUGE_VAL) );

}

Segment is another class with default constructor.
I have not defined destructors, copy constructor and copy assignement.
So the automatic membewise-copy should be used.

The class Bounds appears in other classes in the construtors as or/and
as reference member data like
....
private:
const Bounds& bounds;
...

Until here everything is working fine.

Now I write code for another class in which Bounds appears only in the
constructor as (not as member data) like:
UniformEnvelope::UniformEnvelope(const Bounds& bounds, .......

and what happends is that when I add the source code and header file
of this new class and compile normally the constructor
Bounds::Bounds(double lo, double up) stop working.
In debug mode I get no error/exceptio at all but I notice that the
push_back() is not working correctly. It does not report any error but
if simply fails to insert the value.

If it is of any help looking in the standart template library the
function failed to insert (does not return error/exception but after
this call in (*this) i see: "(error) 0" as unique element using the
debugger) is _Incsize(1) in:

void _Insert(iterator _Where,
const _Ty& _Val)
{ // insert _Val at _Where

#if _HAS_ITERATOR_DEBUGGING
if (_Where._Mycont != this)
_DEBUG_ERROR("list insert iterator outside range");
#endif /* _HAS_ITERATOR_DEBUGGING */

_Nodeptr _Pnode = _Where._Mynode();
_Nodeptr _Newnode = _Buynode(_Pnode, _Prevnode(_Pnode), _Val);
_Incsize(1);
_Prevnode(_Pnode) = _Newnode;
_Nextnode(_Prevnode(_Newnode)) = _Newnode;
}

in the <list> file.

The very strange thing (for me at least) is that recompiling the whole
project solves the problem.
Do you have any idea of what the problem could be and how could I
check it?

Thank you
StephQ

Always initialize all your members, thats not the compiler's job - its
yours. You've not shown enough code to detect any other issues.

 

[Obnoxious User]

Salt_Peter skrev:

Bounds::Bounds : upperLinearSpline(), lowerLinearSpline()
{
}

Unnecessary. They are initialized properly anyway, you don't
need to call the default constructor explicitly.

 

[Salt_Peter]

Bounds::Bounds : upperLinearSpline(), lowerLinearSpline()

typo:

Bounds::Bounds() : upperLinearSpline(), lowerLinearSpline()

 

[Victor Bazarov]

Bounds::Bounds : upperLinearSpline(), lowerLinearSpline()

typo:

Bounds::Bounds() : upperLinearSpline(), lowerLinearSpline()
[..]

Since both 'Spline' things are standard list containers, there is
no need to initialise them explicitly, the default initialisation
should work just fine.

You've not detected any issues. Neither have I, but I didn't look.

V

 

[StephQ]

// > }

};

Your problem is right here: You need a semicolon!

Sorry, I made a mistake in pasting only this part of the class. This
error is not present in the complete version of the code.

A leading underscore followed by a capital letter is reserved to the
implementation (so are double underscores), you should NOT use them.

The part pasted is from the STL that shipped with my compiler (visual
studio 2005). I posted it just in case someone weally expert with STL
could deduce what could be wrong with my code.

If you have two files in your project, A.cpp and B.cpp, and B.cpp uses
something from A.cpp, and you change something in the interface in A.cpp,
you need to re-compile BOTH(all) files.

That's the point. The strange point is that in this case if I don't
recompile everything I get problems with my constructor. And the
problem appears in the function I reported. But I'm almost sure that
it's a problem of my software, and not of the STL implementation,
which should have been tested a lot more than my code.

Cheers
StephQ

 

[StephQ]

I have a class Bounds with two constructors:
class Bounds
{
private:
list<Segment> upperLinearSpline; // Upper bound.
list<Segment> lowerLinearSpline; // Lower bound.
...
}
Bounds::Bounds()
{
}
Bounds::Bounds : upperLinearSpline(), lowerLinearSpline()

typo:

Bounds::Bounds() : upperLinearSpline(), lowerLinearSpline()
[..]

Since both 'Spline' things are standard list containers, there is
no need to initialise them explicitly, the default initialisation
should work just fine.



You've not detected any issues. Neither have I, but I didn't look.

V

I will try the explicit initialization suggestion with the default
constructor to see if it makes a difference.
Is explicitely calling the default constructor necessary in same
situations?


Cheers
StephQ

 

[BobR]

StephQ wrote in message ...

[snip]
The part pasted is from the STL that shipped with my compiler (visual
studio 2005).

Oh. The upper-case ' I ' fooled me. I've only seen implementations that use
all lower-case in the public interface of the STL:

That's the point. The strange point is that in this case if I don't
recompile everything I get problems with my constructor. And the
problem appears in the function I reported. But I'm almost sure that
it's a problem of my software, and not of the STL implementation,
which should have been tested a lot more than my code.
Cheers, StephQ

You'll need to post more code to get help. Reduce your code to the smallest
that will exhibit the problem, and post that (if the solution didn't jump
out at you in the process). We'll need to see class Bounds, class Segment,
and the part in main(or?) where you use the class[es] (esp. the
list.insert()).

 

[Victor Bazarov]

[..]
I will try the explicit initialization suggestion with the default
constructor to see if it makes a difference.

Trust me, it won't make any.

Is explicitely calling the default constructor necessary in same
situations?

Only in case of POD. For classes that have their own constructors
(either user-defined, or compiler-provided) there's no difference.

V

 

[Jim Langston]

I have a class Bounds with two constructors:

class Bounds
{
private:

list<Segment> upperLinearSpline; // Upper bound.
list<Segment> lowerLinearSpline; // Lower bound.
...

}


Bounds::Bounds()
{
}

Bounds::Bounds(double lo, double up)
{
lowerLinearSpline.push_back( Segment(Point(0, lo), 0, -HUGE_VAL,
HUGE_VAL) );

upperLinearSpline.push_back( Segment(Point(0, up), 0, -HUGE_VAL,
HUGE_VAL) );
}


Segment is another class with default constructor.
I have not defined destructors, copy constructor and copy assignement.
So the automatic membewise-copy should be used.

The class Bounds appears in other classes in the construtors as or/and
as reference member data like
....
private:
const Bounds& bounds;
...

Until here everything is working fine.

Now I write code for another class in which Bounds appears only in the
constructor as (not as member data) like:
UniformEnvelope::UniformEnvelope(const Bounds& bounds, .......

You have some class that accepts a constant reference to an instance of
Bounds. Well, you haven't shown any code where the constructor would be
called. Why don't you try posting a complete compilable program that shows
the issue? We're only getting bits and pieces here.

 

[James Kanze]

I have a class Bounds with two constructors:

class Bounds
{
private:

list<Segment> upperLinearSpline; // Upper bound.
list<Segment> lowerLinearSpline; // Lower bound.
...
}

Bounds::Bounds(double lo, double up)
{
lowerLinearSpline.push_back( Segment(Point(0, lo), 0, -HUGE_VAL,
HUGE_VAL) );

upperLinearSpline.push_back( Segment(Point(0, up), 0, -HUGE_VAL,
HUGE_VAL) );
}

Segment is another class with default constructor.
I have not defined destructors, copy constructor and copy assignement.
So the automatic membewise-copy should be used.

The class Bounds appears in other classes in the construtors as or/and
as reference member data like
....
private:
const Bounds& bounds;
...

Until here everything is working fine.

Now I write code for another class in which Bounds appears only in the
constructor as (not as member data) like:
UniformEnvelope::UniformEnvelope(const Bounds& bounds, .......

and what happends is that when I add the source code and header file
of this new class and compile normally the constructor
Bounds::Bounds(double lo, double up) stop working.
In debug mode I get no error/exceptio at all but I notice that the
push_back() is not working correctly. It does not report any error but
if simply fails to insert the value.

Practically, there are two things which can cause this: a header
file has been modified since the last full build, but one of the
source files which reused it was not recompiled, or you used
different options in the earlier compilations. (Note that even
such basic things as sizeof( std::list<Something> ) may change
depending on compiler options.)

 

[StephQ]

Sorry about that. I will post a reproducible example as soon as
possible.
Probably after Wednsday becouse I have to finish some parts of the
software before that date.

Cheers
StephQ