> If I had known that my stl implementation was holding
> vector<vector> correctly I would have rather use it avoiding a lot of
> complication.

    I think you just hit my point :) You would rather used it, but you
did not, because of behaviour of concrete stl implementation. If I would
use specific features of STLPort, like ability to deal with
vector<vector> correctly, I would bind my code to STLPort.

    OTOH, it is true that some people are already doing strange things
in STL now and it is also true that STLPort is     quite portable
itself...

Mirek


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

cxl@volny.cz (Mirek Fidler) wrote in message news:<b9847k$1nkf$1@news.vol.cz>...
> > If I had known that my stl implementation was holding
> > vector<vector> correctly I would have rather use it avoiding a lot of
> > complication.
>
>     I think you just hit my point :) You would rather used it, but you
> did not, because of behaviour of concrete stl implementation. If I would
> use specific features of STLPort, like ability to deal with
> vector<vector> correctly, I would bind my code to STLPort.
>

  Then we can do it if we keep it secret ;-). This way the "bad
performance" implementation will be better and the good one won't be
changed.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>     Say I will implement function that returns a container. Now I have a
> piece of code that works well - but only with STLPort/mojo, simply
> because STLPort does something significantly better than C++ standard
> requires. I think that this makes code unportable and thus, is some
> sense, violating C++ standard... (well, word 'violating' is little bit
> too harsh here :)

I don't agree with this statement. Different implementations of the
standard can do the same job in different ways and still be standard
compliant. It is already the case that your C++ code compiled with one
implementation of the standard does not perform the same as another.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

cxl@volny.cz ("Mirek Fidler") wrote in message news:<b8pdu1$2ih5$1@news.vol.cz>...
>     I think while these improvements are really useful, they bring one
> interesting question:
>
>     Can we use them ?
>
>     Say I will implement function that returns a container. Now I have a
> piece of code that works well - but only with STLPort/mojo, simply
> because STLPort does something significantly better than C++ standard
> requires. I think that this makes code unportable and thus, is some
> sense, violating C++ standard... (well, word 'violating' is little bit
> too harsh here :)
>
> Mirek
>

  Of course we can use them :-)

  Part of the modification are rather logical. I think that most of
C++ programmers, that are not expert, do think that when they write
swap(vector1, vector2) it is the vector::swap that is called even if
it is not the case on most of compilers.

  About the other modifications I would have the same logic, not all
C++ programmers think in term of performance when they write code. I
see quite regularly vector pass by value in function or vector<vector>
with a lot of insertion and deletion. Good programmers will keep on
avoiding such things and they will be right but it not a reason to
keep the other's code as bad as it is just because when it is compile
with an other stl implementation it will be slow.

  Moreover it is sometimes very usefull to do vector<string> or
vector<vector> and even if it is not performant you have to do so. I
had once to manage a vector<vector> to make some kind of hash
container. To avoid performance penalty I made vector<vector*> but I
had to handle memory managment manually and I am almost sure that my
code was not exception safe as I was no very aware about that when I
wrote this code. If I had known that my stl implementation was holding
vector<vector> correctly I would have rather use it avoiding a lot of
complication.

  And please don't try to see a philisophical side in the C++
standard, it is only a technical document with clear rules. You obey
them or not. There are some obscure points that will be elucidated in
the next standard version but about the vector behavior it is quite
clear. Most of the time it says that operation has to "call at most 2N
copy constructor" or things like that. Not calling any is just in the
standard. There is only the erase method that is not standard
compliant but I will look at a Standard C++ modification for this
over-specification.

Thank you for your remarks, you can have a look at the source code in
the forum of Stlport at the following link:
  http://www.stlport.com/dcforum/DCForumID5/682.html

but I have to make a new patch because I made a lot of modifications
lately.

Best Regards.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

===================================== MODERATOR'S COMMENT:
 This thread is drifting off-topic for comp.std.c++.
Please ensure that any follow-ups relate to C++ standardisation.



===================================== END OF MODERATOR'S COMMENT
google@dalvander.com (Anders Dalvander) wrote in message news:<d04c84a9.0305040301.5efdd2ba@posting.google.com>...
> > I have also integrated a call_traits mechanism to avoid for instance the
> > vector<char>::push_back method to take a reference to const data (char
> > const&) when a value (char) is more performant.
>
> Would this be of any use as the member functions are inline? Even an
> average compiler of today would spot this and optimize away the actual
> call.
>

I don't think so. Stlport is, as its name show it, a portable stl
implementation working on many different platform and compilers. You
can't be sure that all compilers does the right optimization.
Moreover, do you regularly check the assembly generated by your
compiler to see if an optimization has been performed? Personnaly I
don't (even if I would like to...) and few C++ programmers do so. To
count on hypothetical compiler optimization is not a good idear when
you can force it in your code.

Best Regards.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> I have also integrated a call_traits mechanism to avoid for instance the
> vector<char>::push_back method to take a reference to const data (char
> const&) when a value (char) is more performant.

Would this be of any use as the member functions are inline? Even an
average compiler of today would spot this and optimize away the actual
call.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> - integration of the mojo framework. Has there been already a
discution
> - improvement of the erase method by using the swap container member
> I also improved the std::swap function implementation so that it calls
> I have also integrated a call_traits mechanism to avoid for instance
the

    I think while these improvements are really useful, they bring one
interesting question:

    Can we use them ?

    Say I will implement function that returns a container. Now I have a
piece of code that works well - but only with STLPort/mojo, simply
because STLPort does something significantly better than C++ standard
requires. I think that this makes code unportable and thus, is some
sense, violating C++ standard... (well, word 'violating' is little bit
too harsh here :)

Mirek


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

===================================== MODERATOR'S COMMENT:
 Please ensure that replies are topical for comp.std.c++



===================================== END OF MODERATOR'S COMMENT
Hello

I am working on a stl implementation, Stlport (www.stlport.com), trying
to improve performance. I have remarked that most of stl implementations
do optimizations when dealing with basic types or pointers, most of the
time using memmove in the vector implementation. But there are many
other types that you know a lot about when implementing a stl, it is the
stl containers themselves. This is why most of my work is based on
improving the Stlport vector implementation when instanciated with an
other container (the most famous ones are vector<vector> or
vector<string> I think). For the moment I have done the following things:

- integration of the mojo framework. Has there been already a discution
about this framework from Andrei Alexandrescu? I used only the move
constructor feature for the moment, not the temporary object detection.
When the internal vector's memory buffer is resized its internal objects
are moved rather than copy.

- improvement of the erase method by using the swap container member
function rather than the assignment operator when moving the objects
following the erased object. Alberto Barbati already told me that it was
not conformant to the standard because it says that the assignment
operator has to be called for each objects after the erased object but
it is rather a standard over specification.

I also improved the std::swap function implementation so that it calls
the swap container member function even if the compiler do not support
partial template specialization.

I have also integrated a call_traits mechanism to avoid for instance the
vector<char>::push_back method to take a reference to const data (char
const&) when a value (char) is more performant.

I would like to know what you all think about.

I also had a little problem when integrating the mojo framework under
gcc2.95. In its article Andrei says that you can use private inheritance
with his framework but gcc do not accept it. I was so wondering if the
private, protected, public qualifier in inheritance have an influence on
the polymorphic aspect of an object. To be clear, does that:

class Base {};
class Derived : private Base {};

void func (Base const& param);

int main()
{
 Derived D;
 func(D);
};

has to compile according the standard??

And does that:

template <class T> struct TStruct;

template <> struct<Base> TStruct
{};

int main()
{
 TStruct<Derived> TD;
};
has to compile too??

I have also some questions about mojo but it will be for an other post.

Thank you.

Francois Dumont

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]