STL vector

STL vector

[Mws]

hi, 

why is the std::vector member function pop_back() not checking for
validity? 
is this wanted behaviour or a bug?

regards
marcel

Re: STL vector

[John Love-Jensen]

Hi marcel,

Doing a pop_back on an empty std::vector has undefined effect.

Probably a safe bet that whatever the undefined effect, it isn't a desirable
effect.

The size method can be called before the pop_back, to assure that there is
something to pop.

HTH,
--Eljay

Re: STL vector

[Mws]

On Monday 31 October 2005 12:17, John Love-Jensen wrote:
> Hi marcel,
> 
> Doing a pop_back on an empty std::vector has undefined effect.
> 
> Probably a safe bet that whatever the undefined effect, it isn't a desirable
> effect.
> 
> The size method can be called before the pop_back, to assure that there is
> something to pop.
> 
> HTH,
> --Eljay
> 
> 
it's implemented like

      void
      pop_back()
      {
	--this->_M_impl._M_finish;
	std::_Destroy(this->_M_impl._M_finish);
      }

but, imho a 

      void
      pop_back()
      {
	if ( this->_M_impl._M_finish != this->_M_impl._M_start)
	{
		--this->_M_impl._M_finish;
		std::_Destroy(this->_M_impl._M_finish);
	}
      }

would be save and shouldn't be that performance specific. also the programmer can save his ( if (!foo.empty()) ... things for all occurences of pop_back();
i do not really know, why the stl implementation's - in my point of view - regression is applicalable.

can someone explain it to me?

regards
marcel

Re: STL vector

[John Love-Jensen]

Hi marcel,

> can someone explain it to me?

The *STANDARD* says that pop_back on an empty std::vector has an undefined
effect.

The safer version you suggest complies with the standard -- but it's not
reliable behavior on all C++ compilers, and it has a performance penalty for
code that does not expect nor rely upon the safe behavior you've suggested.
Even though the performance penalty is slight, it is enough that certain
situations may opt not to use std::vector because of the performance
overhead.

You can get that same safe behavior by doing a if(v.size()) v.pop_back(); in
your code.  Or better yet, create a marcel::vector template class that adds
the additional safety feature you desire *AND* is cross-platform compatible.
That same guarantee cannot be made of the std:: namespace's implementation
of std::vector.

HTH,
--Eljay

Re: STL vector

[Mws]

On Monday 31 October 2005 12:49, John Love-Jensen wrote:
> Hi marcel,
> 
> > can someone explain it to me?
> 
> The *STANDARD* says that pop_back on an empty std::vector has an undefined
> effect.
> 
> The safer version you suggest complies with the standard -- but it's not
> reliable behavior on all C++ compilers, and it has a performance penalty for
> code that does not expect nor rely upon the safe behavior you've suggested.
> Even though the performance penalty is slight, it is enough that certain
> situations may opt not to use std::vector because of the performance
> overhead.
> 
> You can get that same safe behavior by doing a if(v.size()) v.pop_back(); in
> your code.  Or better yet, create a marcel::vector template class that adds
> the additional safety feature you desire *AND* is cross-platform compatible.
> That same guarantee cannot be made of the std:: namespace's implementation
> of std::vector.
> 
> HTH,
> --Eljay
> 
> 
thanks for clarify.
i'll think i'll implement my own templates for the std::<classes> with extended safety.

regards
marcel

Re: STL vector

[Dima Sorkin]

> i'll think i'll implement my own templates for the std::<classes> with
> extended safety.
 Before you do it, try debug mode of STLport (www.stlport.org).
It is almost paranoidal mode, it checks things you could not even
fantasize about.

Regards,
 Dima.

Re: STL vector

[random]

Mws wrote:

>hi, 
>
>why is the std::vector member function pop_back() not checking for
>validity? 
>is this wanted behaviour or a bug?
>
>  
>
There isn't a check, to ensure maximum possible performance. If you want
to enable checking, you should compile using the flag:

-D_GLIBCXX_DEBUG

Which turns on lots of checks, including this one, at the obvious cost
of slight slowness, and also checks a bunch of other things as well.
note you have to recompile your whole program using this flag, as it
makes the various stl containers a slightly larger size, to hold the
debugging information, so you can't link debugging and non-debugging
code (well, you can in some cases, if you are really careful, but in
general you just shouldn't).

Chris

Re: STL vector

[Mws]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

On Tuesday 01 November 2005 11:01, Dima Sorkin wrote:
> > i'll think i'll implement my own templates for the std::<classes> with
> > extended safety.
>  Before you do it, try debug mode of STLport (www.stlport.org).
> It is almost paranoidal mode, it checks things you could not even
> fantasize about.
> 
> Regards,
>  Dima.
> 
yes, i downloaded it and had a look at the source:

  void pop_back() {
    --this->_M_finish;
    _Destroy(this->_M_finish);
  }

the same unchecked stuff :)

so, still there is the option to have my own classes.
sometimes, standards are of a crazy design imho.

performance does matter _all_ time,
safety, code reduction is like an unreal feature.

thus better do reinvent a wheel by creating your own kind of STL?
know all issues and trapdoors.
if you fall into one, wonder and wonder,
have look at bits/.....h and find out, 
that a sigsegv is not caused by the push_back(T),
but by a long time ago pop_back() at totally different position of source.

regards
marcel

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: STL vector

[Dima Sorkin]

On 11/2/05, Mws  wrote:
>  void pop_back() {
>    --this->_M_finish;
>    _Destroy(this->_M_finish);
>  }
>
> the same unchecked stuff :)

 Hi.
  Why do yo think this piece of code is unchecked ?
The check can be inside the iterator's "operator--".
Intall it and run some small test, to examine is there
a check.

By the way, installation of STLport 4.6.2 was problematic
with the newer versions of GCC.I am not sure the problem
was solved in the latest snapshots of STLport. But if you
have gcc 3.3.* or older, there are no problems.

Regards,
 Dima.

Re: STL vector

[random]

Mws wrote:

>On Tuesday 01 November 2005 11:01, Dima Sorkin wrote:
>  
>
>>>i'll think i'll implement my own templates for the std::<classes> with
>>>extended safety.
>>>      
>>>
>> Before you do it, try debug mode of STLport (www.stlport.org).
>>It is almost paranoidal mode, it checks things you could not even
>>fantasize about.
>>
>>Regards,
>> Dima.
>>
>>    
>>
>yes, i downloaded it and had a look at the source:
>
>  void pop_back() {
>    --this->_M_finish;
>    _Destroy(this->_M_finish);
>  }
>
>the same unchecked stuff :)
>
>  
>
Just to point it out, if you check the debugging version (it lives in
debug/vector), the function looks like:

void
pop_back()
      {
        __glibcxx_check_nonempty();
        iterator __victim = end() - 1;
        __victim._M_invalidate();
        _Base::pop_back();
      }

Some nice checking there :)

Chris

Re: STL vector

[Mws]

On Thursday 03 November 2005 16:49, random@bubblescope.net wrote:
> Mws wrote:
> 
> >On Tuesday 01 November 2005 11:01, Dima Sorkin wrote:
> >  
> >
> >>>i'll think i'll implement my own templates for the std::<classes> with
> >>>extended safety.
> >>>      
> >>>
> >> Before you do it, try debug mode of STLport (www.stlport.org).
> >>It is almost paranoidal mode, it checks things you could not even
> >>fantasize about.
> >>
> >>Regards,
> >> Dima.
> >>
> >>    
> >>
> >yes, i downloaded it and had a look at the source:
> >
> >  void pop_back() {
> >    --this->_M_finish;
> >    _Destroy(this->_M_finish);
> >  }
> >
> >the same unchecked stuff :)
> >
> >  
> >
> Just to point it out, if you check the debugging version (it lives in
> debug/vector), the function looks like:
> 
> void
> pop_back()
>       {
>         __glibcxx_check_nonempty();
>         iterator __victim = end() - 1;
>         __victim._M_invalidate();
>         _Base::pop_back();
>       }
> 
> Some nice checking there :)
yes, sounds to be a solution. i will try out and see if a glibc/libcstd++ combination including
the debug stuff is able to run on an embedded system with limited resources. e.g. 32 mb ram.

regards marcel