I wrote an extension on the bitset class and I checked if a copy
constructor and assignment operator was present in the STL bitset file.
I can't found any of these expected:
bitset(const bitset<N>& b);
bitset<N>& operator=(const bitset<N>& b);
I see only an assignment operator for the inner Reference class. If I
test the assignment it seems to work though strange. I'm using VC
express 2008.
Anyone can help me out here.
Thnx
-G
The compiler generates a default copy constructor and assignment
operator when needed. In this case the semantics of these (memberwise
copy) is exactly what's needed.
Bo Persson
Ok thanks Bo. I did some googling on this topic and found that with some
STL distribution these are explicitly defined in the bitset class. ( eg
hp , apache or the famous derived Boost which is even making the bitset
class dynamically settable )
However good to know that the MS compiler makes the substitution
automatically.
-G
I'm not sure what you mean by "substitution" here. All C++ compilers
generate an implicit copy constructor and assignment operator for any
class where those are not provided explicitly. This is part of C++
language specification, not some kind of implementation-specific
behavior.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
Igor,
I don't use STL very much actually. I dove into my archives ;-) I
checked my C++ book of the man himself Bjarne Stroustrup (3 edition) and
indeed on page 284 chapter 11.7 "Essential Operators" I read :
" For a class for wich the copy assig and the copy const are not
explicitly declared by the programmer, the missing operations will be
generated by the compiler."
So whenever I provid a copy constructor or assignment operator in my
derived STL class the compiler will take mines, in case I don't the
compiler takes the default ones for me correct ?
Of course care should be taken when you don't define your own copy
constructor and take the default one:
– if the class has member variables as values (no
references or pointers)
– if the class does not run additional initialization
routines
Where can I find the official STL specification on the net ?
thnx
-G
> Ok thanks Bo. I did some googling on this topic and found that with some
> STL distribution these are explicitly defined in the bitset class. ( eg hp
> , apache or the famous derived Boost which is even making the bitset class
> dynamically settable )
boost::dynamic_bitset probably has a copy ctor and assignment operator
because this makes sense for this class. What does it have to do with
std::bitset? Why do you think it's derived from std::bitset?
http://www.boost.org/doc/libs/1_36_0/libs/dynamic_bitset/dynamic_bitset.html#description
Misunderstanding, of course dynamic_bitset has nothing to do with stl
bitset but I used it in my sentence because it's also quit simaliar with
the std bitset class to point out the precense of the copy const and
assign oper which is not the case in the std::bitset class.
Why do you think it's derived from std::bitset?
I didn't. The dynamic_bitset is simply a class from the boost namespace
and not the std namespace. Same misunderstanding sorry for this.
This is the official C++ language standard (including the standard
library):
http://www.amazon.com/Standard-Incorporating-Technical-Corrigendum-No-1/dp/0470846747
I don't know whether it's avaliable online anywhere.
There is a number of online references (both for the language and the
library), none of them "official" (meaning, sanctioned and maintained by
a standards-setting body).
Ok. But looking at the link that I gave you, you should be
able to see why a compiler generated copy ctor/assignment
operator may not be useful.
The general reason that you would write your own is that
the default ones don't do the job.
> Ok. But looking at the link that I gave you, you should be
> able to see why a compiler generated copy ctor/assignment
> operator may not be useful.
Yes indeed because the size of the boost bitset can be given at run-time
so completly dynamic and the compiler doesn't know the size of the set
at compile time and therefore can't deliver good defaults. Example out
of boost:
// constructor with allocator
template <typename Block, typename Allocator>
dynamic_bitset<Block, Allocator>::dynamic_bitset(const Allocator& alloc)
: m_bits(alloc), m_num_bits(0)
{
}
// copy constructor
template <typename Block, typename Allocator>
inline dynamic_bitset<Block, Allocator>::
dynamic_bitset(const dynamic_bitset& b)
: m_bits(b.m_bits), m_num_bits(b.m_num_bits)
{
}
// assig
template <typename Block, typename Allocator>
dynamic_bitset<Block, Allocator>& dynamic_bitset<Block, Allocator>::
operator=(const dynamic_bitset<Block, Allocator>& b)
{
m_bits = b.m_bits;
m_num_bits = b.m_num_bits;
return *this;
}
> The general reason that you would write your own is that
> the default ones don't do the job.
FYI:
in the dynamic_bitset doc of boost this is written:
"dynamic_bitset is meant to be a run-time sized version of std::bitset"
I'd like to point out that the official STL and STL documentation are
available at SGI's, which is where the STL has found its resting place.
However, this is only interesting for historic reasons, because the STL was
mostly incorporated in the C++ standard, along with the C API and
IOStreams, to name the next two biggest parts. "mostly" also means not
100%, and there are a few slight differences between the C++ stdlib and the
STL.
In any case, to the OP:
- You should only look at the C++ stdlib, the STL is obsolete.
- The term "STL" is often used to refer to the containers, iterators and
algorithms of the C++ stdlib, but that is technically not correct.
> I don't know whether it's avaliable online anywhere.
Doing some searching, you should be able to find a prerelease version, which
is accurate in 99% of all cases, but the official documents from the ISO
are usually not downloadable for free.
cheers
Uli
--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
Thanks Uli for your clear answer.
So the namespace std could be considered as a set of
classes,containers,.. implemented following the C++ specifications
mostly based on using templates. And in fact eg the boost library can be
considered the same way isolated in his proper namespace "boost". Boost
is just another implementation using the C++ standards and a bit more
extended comparing to the std. (eg more run-time dynamic features)
Starting this thread has given me the knowledge to better place all this
C++ and STL stuff as I meanly program in java these days where the
(copy)constructing and assignments are a bit different from C++ ;-)
Thanks everyone to write a few words here and clear out some fundamentals.
-G
No. There is a C++ standard, which says what any conforming implementation
must provide. This includes e.g. the parts from the STL and IOStreams, both
contained in the namespace 'std'. Now, the standard doesn't provide any of
the code to achieve that, this is completely left to the compiler vendor.
Further, I wouldn't call Boost an implementation. The point is that for the
C++ standard, you have on one side the standard which defines requirements
and on the other side different compilers and stdlibs from different
vendors that implement this standard. If you look at Boost, you find that
it is a library which doesn't implement a separate standard.
> Starting this thread has given me the knowledge to better place all this
> C++ and STL stuff as I meanly program in java these days where the
> (copy)constructing and assignments are a bit different from C++ ;-)
Actually, if you had mentioned that earlier that you are a Java programmer
that would have helped. Code in 'std' is roughly equivalent to code in
in 'java.*', while the code in 'boost' is something that you get from an
add-on library.