Home > Archive > VC STL > April 2005 > Does std::map provides a copy assignment operator?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Does std::map provides a copy assignment operator?
|
|
| Hashim Saleem 2005-04-14, 4:02 pm |
| hi all,
I am just puzzled that whether std::map provides an assignment operator or
not?
I couldnt find any in the source code of STL implementation accompanying
visual studio .net 2003 (VC7.1).
What does C++ standard say about it?
Also, here is an implementation of std::map that does provide an assignment
operator.
http://gcc.gnu.org/onlinedocs/libst...l#std_1_1mapa27
If this implemation provides why doenst Visual studio .net 2003 (VC7.1)?
| |
| Jeff F 2005-04-14, 4:02 pm |
| Hashim Saleem wrote:
> hi all,
>
> I am just puzzled that whether std::map provides an assignment
> operator or not?
>
> I couldnt find any in the source code of STL implementation
> accompanying visual studio .net 2003 (VC7.1).
>
> What does C++ standard say about it?
>
> Also, here is an implementation of std::map that does provide an
> assignment operator.
>
> http://gcc.gnu.org/onlinedocs/libst...l#std_1_1mapa27
>
> If this implemation provides why doenst Visual studio .net 2003
> (VC7.1)?
Why do you think it doesn't(other than the abominably poor C++ documentation
in MSDN)?
#include <map>
...
typedef std::map<int,int> tMap;
tMap Map1, Map2;
Map1 = Map2;
This works for me in VC7.1.
Jeff Flinn
| |
| Simon Watson 2005-04-14, 4:02 pm |
| Are you saying that the default assignment operator doesn't do the right
thing? If the default assignment operator is good enough, why bother to
write another one?
cheers
Simon
"Hashim Saleem" <hashim.saleem@gmail.com> wrote in message
news:eddb$$OQFHA.2384@tk2msftngp13.phx.gbl...
> This works because of the default assignment operator provided by the
> compiler.
>
> If you see the source code of std::map accompanying VC7.1, you wont see
any
> assignment operator.
>
> Source code is attached for reference.
>
>
> "Jeff F" <not@anywhere.com> wrote in message
> news:Ouyes2OQFHA.2604@TK2MSFTNGP10.phx.gbl...
http://gcc.gnu.org/onlinedocs/libst...l#std_1_1mapa27[color=darkred]
>
>
>
| |
| Stephen Howe 2005-04-14, 4:02 pm |
| > If you see the source code of std::map accompanying VC7.1, you wont see
any
> assignment operator.
Does not matter.
If the compiler-manufactured assignment operator (and also copy constructor,
default constructor, destructor) does the right thing, then there is no need
to write it.
You only ever need to write assignment operators, copy constructors,
destructors if the compiler-generated version does the wrong thing. And that
occurs if the class is manually managing some resource (like a ordinary
pointer). See "Law of the Big 3" from
http://www.parashift.com/c++-faq-li...s.html#faq-27.9
"A class with any of {destructor, assignment operator, copy constructor}
generally needs all 3".
A class that contains just
(i) simple types like int's, short's, floats, double's or arrays of
simple types
(ii) other std well-behaved classes like string, vector
does not need assignment operators, copy constructors, destructors etc
because the compiler versions will do the right thing for (i) and call the
equivalent member function for (ii).
As a matter of what I consider "best practice", I don't write assignment
operators, copy constructors, destructors if I know that the
compiler-generated version does exactly the right thing. It is also likely
to be more optimal.
Hope that helps
Stephen Howe
| |
| Hashim Saleem 2005-04-14, 4:02 pm |
| Simon Watson wrote:
> Are you saying that the default assignment operator doesn't do the right
> thing?
That is what I am anxious about. According to my knwoledge the default
assignment operator just copies the underlying bits to bits. This logic
fails in case if your class allocates data dynamically.
May it not be the case, but I think as there is an assignment operator for
vector<> then why there isnt any for map<> provided other STL
implementations do provide one for map.
Regards.
"Simon Watson" <ms dot simonwatson at xoxy dot net> wrote in message
news:uSgOEhPQFHA.2736@TK2MSFTNGP09.phx.gbl...
> Are you saying that the default assignment operator doesn't do the right
> thing? If the default assignment operator is good enough, why bother to
> write another one?
>
> cheers
>
> Simon
>
> "Hashim Saleem" <hashim.saleem@gmail.com> wrote in message
> news:eddb$$OQFHA.2384@tk2msftngp13.phx.gbl...
> any
> http://gcc.gnu.org/onlinedocs/libst...l#std_1_1mapa27
>
>
| |
| Hashim Saleem 2005-04-14, 4:02 pm |
| No. it is not helping.
Actually, I am wrapping std::map into a class and my class malfunction in
copy/assignment operations. The only thing my class contains is an instance
of std::map. All the types contained in may are copy constructable and they
behave individualy correct.
So, my doubt directly goes to the std::map as it does not define its
assignment and copy constructor.
The simple question is why std::map does not provide assignment and copy
constructor?
Regards.
"Stephen Howe" <stephenPOINThoweATtns-globalPOINTcom> wrote in message
news:%23rOCgbQQFHA.3196@TK2MSFTNGP12.phx.gbl...
> any
>
> Does not matter.
> If the compiler-manufactured assignment operator (and also copy
> constructor,
> default constructor, destructor) does the right thing, then there is no
> need
> to write it.
>
> You only ever need to write assignment operators, copy constructors,
> destructors if the compiler-generated version does the wrong thing. And
> that
> occurs if the class is manually managing some resource (like a ordinary
> pointer). See "Law of the Big 3" from
> http://www.parashift.com/c++-faq-li...s.html#faq-27.9
> "A class with any of {destructor, assignment operator, copy constructor}
> generally needs all 3".
> A class that contains just
> (i) simple types like int's, short's, floats, double's or arrays of
> simple types
> (ii) other std well-behaved classes like string, vector
> does not need assignment operators, copy constructors, destructors etc
> because the compiler versions will do the right thing for (i) and call the
> equivalent member function for (ii).
>
> As a matter of what I consider "best practice", I don't write assignment
> operators, copy constructors, destructors if I know that the
> compiler-generated version does exactly the right thing. It is also likely
> to be more optimal.
>
> Hope that helps
>
> Stephen Howe
>
>
| |
| Simon Trew 2005-04-14, 4:02 pm |
| > That is what I am anxious about. According to my knwoledge the default
> assignment operator just copies the underlying bits to bits. This logic
> fails in case if your class allocates data dynamically.
No, it does a memberwise assignment-- i.e. it invokes the assignment
operator on each of the members in turn, in the order they were declared in
the class.
| |
| Simon Trew 2005-04-14, 4:02 pm |
| "Hashim Saleem" <hashim.saleem@gmail.com> wrote in message
news:OvbGLiRQFHA.2136@TK2MSFTNGP14.phx.gbl...
> No. it is not helping.
>
> Actually, I am wrapping std::map into a class and my class malfunction in
> copy/assignment operations. The only thing my class contains is an
instance
> of std::map. All the types contained in may are copy constructable and
they
> behave individualy correct.
>
> So, my doubt directly goes to the std::map as it does not define its
> assignment and copy constructor.
>
> The simple question is why std::map does not provide assignment and copy
> constructor?
Presumably because the default memberwise assignment and memberwise
copy-construction are good enough.
The types contained in the map (I presume "may" is a typo) may be
copy-constructible, but do they have meaningful assignment semantics? The
assignment operator does not invoke the copy constructor (unless using the
placement new trick discussed in this ng a few days ago).
I very much doubt std::map's assignment implementation is incorrect. Someone
would have found out already...
| |
| Stephen Howe 2005-04-14, 4:02 pm |
| > That is what I am anxious about. According to my knwoledge the default
> assignment operator just copies the underlying bits to bits.
But the default assignment operator (for your class that is), will call
map's assignment operator to assign the right-hand side to the left-hand
side. The fact that VC++ library does not define one does not matter. The
compiler will make sure that your classes default assignment operator will
call the compiler-generated map's assignment operator.
If you had
class MyClass
{
public:
// Other member functions but no constructor, destructor, assignment
operator, copy constructor
private:
std::vector<int> v;
std::map<int, int> m;
};
the compiler will automatically generate an assigment operator for MyClass
if you have
MyClass a, b;
a = b;
And the compiler-generated assignment operator for MyClass will
automatically call the assignment operator for v and m. If vector and map do
not have an explicit assignment operator, does not matter, the compiler will
create them can call them from MyClass's assignment operator.
> This logic fails in case if your class allocates data dynamically.
Right. That is true.
If you had an additional data member of MyClass, that was a pointer to an
new'ed int, you now have to write the assignment operator of MyClass to
handle this. But the moment you take responsibility to write the assignment
operator of MyClass, you have to write _ALL_ of it. And that means you have
to explicitly call v & m's assignment operator. But note, if there is no
assignment operator for a member class, the compiler will manufacture one.
Something like
MyClass &operator = (const MyClass &rhs)
{
if (this != &rhs)
{ *pi = *(rhs.pi);
v = rhs.v;
m = rhs.m;
}
return *this;
}
Stephen Howe
| |
| Stephen Howe 2005-04-14, 4:02 pm |
| > According to my knwoledge the default
> assignment operator just copies the underlying bits to bits.
No it does not. The default assignment operator will call various base
classes assignment operators if the class is derived, left to right. It will
then copy each member in turn.
If the member is a class, it will call it's assignment operator
If the member is a POD (plain old data), it will bitwise copy it.
Only if your class is 100% POD, nothing virtual will it be bitwise copied.
Strehen Howe
| |
| Ian Semmel 2005-04-14, 9:01 pm |
|
Jeff F wrote:
>
> Why do you think it doesn't(other than the abominably poor C++ documentation
> in MSDN)?
>
I don't think I would be so generous to describe it as "abominably poor". It is
worse than this by some very large factor.
| |
| pjp@plauger.com 2005-04-14, 9:01 pm |
|
Hashim Saleem wrote:
> I am just puzzled that whether std::map provides an assignment
operator or
> not?
It does.
> I couldnt find any in the source code of STL implementation
accompanying
> visual studio .net 2003 (VC7.1).
Look in <xtree>.
> What does C++ standard say about it?
It should have one.
> Also, here is an implementation of std::map that does provide an
assignment
> operator.
>
>
http://gcc.gnu.org/onlinedocs/libst...l#std_1_1mapa27
>
> If this implemation provides why doenst Visual studio .net 2003
(VC7.1)?
It does.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
| |
| Stephen Howe 2005-04-14, 9:01 pm |
| > > What does C++ standard say about it?
>
> It should have one.
But even if not declared, the compiler will write one anyway, yes?
You have to explicitly make some effort to stop the compiler automatically
generating one.
Cheers
Stephen Howe
| |
| Hashim Saleem 2005-04-15, 9:00 am |
| pjp@plauger.com> wrote:
> Look in <xtree>.
xtree does provide an assignment operator. But according to my knowledge
copy constructor and assignment operator are not inheritable. Since map
inherits from xtree, it does not inherit xtree's copy constructor and
assignment operator. A derived class has to give its own implementation of
copy constructor/assignment operator.
Please correct me if it isnt the case.
Regards.
<pjp@plauger.com> wrote in message
news:1113505175.896612.40620@z14g2000cwz.googlegroups.com...
>
> Hashim Saleem wrote:
>
> operator or
>
> It does.
>
> accompanying
>
> Look in <xtree>.
>
>
> It should have one.
>
> assignment
> http://gcc.gnu.org/onlinedocs/libst...l#std_1_1mapa27
> (VC7.1)?
>
> It does.
>
> P.J. Plauger
> Dinkumware, Ltd.
> http://www.dinkumware.com
>
| |
| Hashim Saleem 2005-04-15, 9:00 am |
| "Simon Trew" wrote:
> The types contained in the map (I presume "may" is a typo) may be
> copy-constructible, but do they have meaningful assignment semantics? The
> assignment operator does not invoke the copy constructor (unless using the
> placement new trick discussed in this ng a few days ago).
Yes they do have meaningful assingment semantics. As I already have written
here that the types contained by map behave correctly if we use them
individually i.e. without putting into map.
"Simon Trew" <noneofyour@business.guv> wrote in message
news:e4DRjoRQFHA.3296@TK2MSFTNGP15.phx.gbl...
> "Hashim Saleem" <hashim.saleem@gmail.com> wrote in message
> news:OvbGLiRQFHA.2136@TK2MSFTNGP14.phx.gbl...
> instance
> they
>
> Presumably because the default memberwise assignment and memberwise
> copy-construction are good enough.
>
> The types contained in the map (I presume "may" is a typo) may be
> copy-constructible, but do they have meaningful assignment semantics? The
> assignment operator does not invoke the copy constructor (unless using the
> placement new trick discussed in this ng a few days ago).
>
> I very much doubt std::map's assignment implementation is incorrect.
> Someone
> would have found out already...
>
>
| |
| Tom Widmer 2005-04-15, 4:01 pm |
| Hashim Saleem wrote:
> pjp@plauger.com> wrote:
>
>
>
> xtree does provide an assignment operator. But according to my knowledge
> copy constructor and assignment operator are not inheritable.
That depends on how you define "inheritable". But I think you could
certainly describe them as inheritable, in that the compiler generated
ones for a derived class will make use of the base class ones.
Since map
> inherits from xtree, it does not inherit xtree's copy constructor and
> assignment operator. A derived class has to give its own implementation of
> copy constructor/assignment operator.
>
> Please correct me if it isnt the case.
If you don't explicitly provide an assignment operator or copy
constructor, the compiler generates them for you. The compiler generated
ones:
1. Perform a copy/assignment of each base subobject in turn.
2. Perform a copy/assignment of each member subobject in turn.
Clearly that is sufficient for the VC7.1 map, since the only subobject
is the base subobject (a _Tree IIRC), and that has well-defined copy and
assigment semantics (see <xtree> as mentioned).
This thread has gone on far too long for such a simple question; VC7.1's
MAP IS COPYABLE AND ASSIGNABLE, WITH THE USUAL SEMANTICS, AS REQUIRED BY
THE C++ STANDARD.
Tom
| |
| Stephen Howe 2005-04-15, 4:01 pm |
| > xtree does provide an assignment operator. But according to my knowledge
> copy constructor and assignment operator are not inheritable.
That is true.
> Since map inherits from xtree, it does not inherit xtree's copy
constructor and
> assignment operator. A derived class has to give its own implementation of
> copy constructor/assignment operator.
That is completely false. The compiler will generate a derived copy
constructor/assignment operator and these will call the base class
equivalents. Inheritance has nothing to do with it.
You seem to have some basic flaw in your understanding on C++.
You need to research under what circumstances the compiler will
automatically generate Default Constructors, Destructors, Copy Constructors
and Assignment Operators.
1. (i) Default Constructors, Destructors, Copy Constructors and Assignment
Operators are special.
(ii) The compiler will manufacture these on an as-needed basis. If your
class is a derived class, even derived multiple times, the compiler will
manfuacture these and they will do exactly the right things. If you have a
base class where you have implemented your special functions, the
compiler-generated versions for derived classes will call your base class
implemented versions.
The versions generated have public access
2. You can disable this automatic generation of these special functions, for
example, if you provide alternative constructors, the compiler will not
generate a default constructor on an as-needed basis.
You disable the automatic generation of copy constructors/assignment
operators by declaring them private and not implementing them.
Essentially, to disable them you, the programmer, have to work to suppress
them.
3. You only ever need to write Default Constructors, Destructors, Copy
Constructors and Assignment Operators if the compiler generated versions do
not do the right thing.
But as it stands, VC 7.1 has been out quite a while; if you were remotely
right that there was this flaw with std::map, don't you think it would be
reported by now?
Is it not more likely your code is incorrect (based on a misunderstanding of
C++)?
Stephen Howe
| |
| Simon Trew 2005-04-15, 4:01 pm |
| "Hashim Saleem" <hashim.saleem@gmail.com> wrote in message
news:Ob7NXAaQFHA.576@TK2MSFTNGP15.phx.gbl...
> "Simon Trew" wrote:
>
> Yes they do have meaningful assingment semantics. As I already have
written
> here that the types contained by map behave correctly if we use them
> individually i.e. without putting into map.
You said:
> All the types contained in may are copy constructable and they
> behave individualy correct.
You didn't mention anything about assignment.
| |
| Stephen Howe 2005-04-15, 4:01 pm |
| > Yes they do have meaningful assingment semantics. As I already have
written
> here that the types contained by map behave correctly if we use them
> individually i.e. without putting into map.
Right. Presumably you have a < operator for the key type. Is it const
(because of course, doing a boolean compare does not change the objects)?
Stephen Howe
| |
| Stephen Howe 2005-04-15, 9:00 pm |
| > I am just puzzled that whether std::map provides an assignment operator or
> not?
So far Hashim, we have not seen any code of yours.
If you think there is a problem, could you post a small compilable example,
with some map assignment, that you think there is a problem, your compiler
switches, then programmers here can verify what you are claiming with VC
6.0, 7.0, 7.1, Whidbey.
I see the expected results with this and VC 7.1:
[color=darkred]
#include <map>
#include <string>
#include <iostream>
using namespace std;
int main()
{
typedef map<const string,int> DictMap;
DictMap m1, m2;
// Do some inserts in increasing magnitude in Map 1
m1.insert(DictMap::value_type("one", 1));
m1.insert(DictMap::value_type("two", 2));
m1.insert(DictMap::value_type("three", 3));
m1.insert(DictMap::value_type("four", 4));
m1.insert(DictMap::value_type("five", 5));
m1.insert(DictMap::value_type("six", 6));
m1.insert(DictMap::value_type("seven", 7));
m1.insert(DictMap::value_type("eight", 8));
m1.insert(DictMap::value_type("nine", 9));
m1.insert(DictMap::value_type("ten", 10));
m1.insert(DictMap::value_type("eleven", 11));
m1.insert(DictMap::value_type("twelve", 12));
// assignment
m2 = m1;
// Display in alphabetical order what is now in Map 2
DictMap::const_iterator itend = m2.end();
for (DictMap::const_iterator it = m2.begin(); it != itend; ++it)
cout << "key: '" << it->first << "', value: " << it->second << '\n';
return 0;
}[color=darkred]
I get
key: 'eight', value: 8
key: 'eleven', value: 11
key: 'five', value: 5
key: 'four', value: 4
key: 'nine', value: 9
key: 'one', value: 1
key: 'seven', value: 7
key: 'six', value: 6
key: 'ten', value: 10
key: 'three', value: 3
key: 'twelve', value: 12
key: 'two', value: 2
Stephen Howe
| |
| Hashim Saleem 2005-04-16, 8:57 am |
| > Is it not more likely your code is incorrect (based on a misunderstanding
> of
> C++)?
>
> Stephen Howe
"Stephen Howe" <stephenPOINThoweATtns-globalPOINTcom> wrote in message
news:OZzNQ1bQFHA.1096@tk2msftngp13.phx.gbl...
>
> That is true.
>
> constructor and
>
> That is completely false. The compiler will generate a derived copy
> constructor/assignment operator and these will call the base class
> equivalents. Inheritance has nothing to do with it.
>
> You seem to have some basic flaw in your understanding on C++.
> You need to research under what circumstances the compiler will
> automatically generate Default Constructors, Destructors, Copy
> Constructors
> and Assignment Operators.
>
> 1. (i) Default Constructors, Destructors, Copy Constructors and Assignment
> Operators are special.
> (ii) The compiler will manufacture these on an as-needed basis. If your
> class is a derived class, even derived multiple times, the compiler will
> manfuacture these and they will do exactly the right things. If you have a
> base class where you have implemented your special functions, the
> compiler-generated versions for derived classes will call your base class
> implemented versions.
> The versions generated have public access
>
> 2. You can disable this automatic generation of these special functions,
> for
> example, if you provide alternative constructors, the compiler will not
> generate a default constructor on an as-needed basis.
> You disable the automatic generation of copy constructors/assignment
> operators by declaring them private and not implementing them.
> Essentially, to disable them you, the programmer, have to work to suppress
> them.
>
> 3. You only ever need to write Default Constructors, Destructors, Copy
> Constructors and Assignment Operators if the compiler generated versions
> do
> not do the right thing.
>
> But as it stands, VC 7.1 has been out quite a while; if you were remotely
> right that there was this flaw with std::map, don't you think it would be
> reported by now?
> Is it not more likely your code is incorrect (based on a misunderstanding
> of
> C++)?
>
> Stephen Howe
>
>
| |
| Hashim Saleem 2005-04-16, 8:57 am |
| Stephen Howe wrote:
> Is it not more likely your code is incorrect (based on a misunderstanding
> of
> C++)?
May be. I am not saying that my code is 100% correct and std::map is flawed.
I just found something missing from std::map (well, according to my
incomplete knowledge :) ) and that was what I was complaining for.
Thanks for all of you that you make my understanding of C++ language more
concrete. (C++ is such a huge language that there is always a new thing to
learn :) ).
Regards,
"Stephen Howe" <stephenPOINThoweATtns-globalPOINTcom> wrote in message
news:OZzNQ1bQFHA.1096@tk2msftngp13.phx.gbl...
>
> That is true.
>
> constructor and
>
> That is completely false. The compiler will generate a derived copy
> constructor/assignment operator and these will call the base class
> equivalents. Inheritance has nothing to do with it.
>
> You seem to have some basic flaw in your understanding on C++.
> You need to research under what circumstances the compiler will
> automatically generate Default Constructors, Destructors, Copy
> Constructors
> and Assignment Operators.
>
> 1. (i) Default Constructors, Destructors, Copy Constructors and Assignment
> Operators are special.
> (ii) The compiler will manufacture these on an as-needed basis. If your
> class is a derived class, even derived multiple times, the compiler will
> manfuacture these and they will do exactly the right things. If you have a
> base class where you have implemented your special functions, the
> compiler-generated versions for derived classes will call your base class
> implemented versions.
> The versions generated have public access
>
> 2. You can disable this automatic generation of these special functions,
> for
> example, if you provide alternative constructors, the compiler will not
> generate a default constructor on an as-needed basis.
> You disable the automatic generation of copy constructors/assignment
> operators by declaring them private and not implementing them.
> Essentially, to disable them you, the programmer, have to work to suppress
> them.
>
> 3. You only ever need to write Default Constructors, Destructors, Copy
> Constructors and Assignment Operators if the compiler generated versions
> do
> not do the right thing.
>
> But as it stands, VC 7.1 has been out quite a while; if you were remotely
> right that there was this flaw with std::map, don't you think it would be
> reported by now?
> Is it not more likely your code is incorrect (based on a misunderstanding
> of
> C++)?
>
> Stephen Howe
>
>
| |
| Hashim Saleem 2005-04-16, 8:57 am |
| "Stephen Howe" wrote:
> So far Hashim, we have not seen any code of yours.
So, here it is just for you guys. Actually, I cant post the source code as
the policy of my company where I am doing job. I ll try to explain what I am
doing by posting the code chunks. Hope these chunks would be enough to clear
my situation here. :)
-----------------------------------------------------------------------------------
class CAscCertChainSummary
{
public:
//! This typedef is a utility typedef for underlying cert chain map.
typedef map<string, CAscX509CertChain<CAscCertificateInfo> > CERTCHAINMAP;
private:
CERTCHAINMAP m_CertChainMap; // Underlying container for cert chain summary.
public:
.............
.............
};
-----------------------------------------------------------------------------------
where CAscX509CertChain is declared as
-----------------------------------------------------------------------------------
template <typename T>
class CAscX509CertChain
{
private:
vector<T> m_vCertificates; // vector of certificates in the chain.
public:
.............
.............
};
-----------------------------------------------------------------------------------
and CAscCertificateInfo is declared as
-----------------------------------------------------------------------------------
class CAscCertificateInfo : public CAscX509Certificate
{
public:
//! This enumeration specifies different types of a certificate.
enum CertType
{
TSA,
OCSPRESPONDER,
CRLSIGNER,
CA,
EE,
OTHER
};
private:
bool m_bTrusted;
string m_szSourceAddress;
CertType m_CertType;
CertType m_CertPathBuildingUsedIn;
public:
.............
.............
};
-----------------------------------------------------------------------------------
and finally CAscX509Certificate is
-----------------------------------------------------------------------------------
class CAscX509Certificate
{
protected:
CERTCertificate *m_pCert; // The underlying pointer to Certificate
structure.
public:
.............
.............
};
-----------------------------------------------------------------------------------
The copy constructor and assignment operator of CAscX509Certificate and
CAscCertificateInfo are as follows respectively.
CAscX509Certificate::CAscX509Certificate
(const CAscX509Certificate
&X509Cert)
{
m_pCert = ::CERT_DupCertificate(X509Cert.m_pCert);
}
CAscX509Certificate &CAscX509Certificate::operator=(const
CAscX509Certificate &rhs)
{
// Check for self assignment
if (this == &rhs)
return *this;
// delete already allocated memory
if(m_pCert)
::CERT_DestroyCertificate(m_pCert);
// Assign new values
m_pCert = ::CERT_DupCertificate(rhs.m_pCert);
return *this;
}
CAscCertificateInfo::CAscCertificateInfo
(const CAscCertificateInfo
&CertificateInfo)
: CAscX509Certificate(CertificateInfo),
m_bTrusted(CertificateInfo.m_bTrusted),
m_CertPathBuildingUsedIn(CertificateInfo
.m_CertPathBuildingUsedIn),
m_CertType(CertificateInfo.m_CertType),
m_szSourceAddress(CertificateInfo.m_szSourceAddress)
{
}
CAscCertificateInfo &CAscCertificateInfo::operator=(const
CAscCertificateInfo &rhs)
{
// Check for self assignment
if (this == &rhs)
return *this;
// delete already allocated memory
if(m_pCert)
::CERT_DestroyCertificate(m_pCert);
m_pCert = ::CERT_DupCertificate(rhs.m_pCert);
m_bTrusted = rhs.m_bTrusted;
m_CertPathBuildingUsedIn = rhs.m_CertPathBuildingUsedIn;
m_CertType = rhs.m_CertType;
m_szSourceAddress = rhs.m_szSourceAddress;
return *this;
}
"Stephen Howe" <stephenPOINThoweATtns-globalPOINTcom> wrote in message
news:%23CgMc9eQFHA.4020@tk2msftngp13.phx.gbl...
>
> So far Hashim, we have not seen any code of yours.
> If you think there is a problem, could you post a small compilable
> example,
> with some map assignment, that you think there is a problem, your compiler
> switches, then programmers here can verify what you are claiming with VC
> 6.0, 7.0, 7.1, Whidbey.
>
> I see the expected results with this and VC 7.1:
>
> #include <map>
> #include <string>
> #include <iostream>
>
> using namespace std;
>
> int main()
> {
> typedef map<const string,int> DictMap;
>
> DictMap m1, m2;
>
> // Do some inserts in increasing magnitude in Map 1
> m1.insert(DictMap::value_type("one", 1));
> m1.insert(DictMap::value_type("two", 2));
> m1.insert(DictMap::value_type("three", 3));
> m1.insert(DictMap::value_type("four", 4));
> m1.insert(DictMap::value_type("five", 5));
> m1.insert(DictMap::value_type("six", 6));
> m1.insert(DictMap::value_type("seven", 7));
> m1.insert(DictMap::value_type("eight", 8));
> m1.insert(DictMap::value_type("nine", 9));
> m1.insert(DictMap::value_type("ten", 10));
> m1.insert(DictMap::value_type("eleven", 11));
> m1.insert(DictMap::value_type("twelve", 12));
>
> // assignment
> m2 = m1;
>
> // Display in alphabetical order what is now in Map 2
>
> DictMap::const_iterator itend = m2.end();
> for (DictMap::const_iterator it = m2.begin(); it != itend; ++it)
> cout << "key: '" << it->first << "', value: " << it->second <<
> '\n';
>
> return 0;
> }
>
> I get
>
> key: 'eight', value: 8
> key: 'eleven', value: 11
> key: 'five', value: 5
> key: 'four', value: 4
> key: 'nine', value: 9
> key: 'one', value: 1
> key: 'seven', value: 7
> key: 'six', value: 6
> key: 'ten', value: 10
> key: 'three', value: 3
> key: 'twelve', value: 12
> key: 'two', value: 2
>
> Stephen Howe
>
>
| |
| Simon Trew 2005-04-18, 4:01 pm |
| What about the < operators?
| |
| Tom Widmer 2005-04-18, 4:01 pm |
| Simon Trew wrote:
> What about the < operators?
std::string (the key type used) has them already!
Tom
| |
| Tom Widmer 2005-04-18, 4:01 pm |
| Hashim Saleem wrote:
> "Stephen Howe" wrote:
>
>
>
> So, here it is just for you guys. Actually, I cant post the source code as
> the policy of my company where I am doing job. I ll try to explain what I am
> doing by posting the code chunks. Hope these chunks would be enough to clear
> my situation here. :)
[SNIP]
Does your default constructor set m_pCert to NULL? What happens if
CERT_DupCertificate fails? And are you sure it is correctly implemented?
Also, have you come across this style of operator== implementation:
A& operator=(A a) //parameter passed by value to create copy
{
a.swap(*this);
return *this; //a's destructor frees old members.
}
All you need to do is implement a swap function, and no need to check
for self-assignment. And it is exception-safe, unlike your version.
Tom
| |
| Hashim Saleem 2005-04-19, 4:02 am |
| Tom Widmer wrote:
> Does your default constructor set m_pCert to NULL? What happens if
> CERT_DupCertificate fails? And are you sure it is correctly implemented?
Yes default constructor does that NULLifying task. About
CERT_DupCertificate, I am not sure whether it is correctly implented or not
because it is not my function, it is library (NSS) function. According to
NSS, all it does is to increment the reference count on m_pCert structure. I
am also calling CERT_DestroyCertificate() in desctructor of
CAscX509Certificate that decrements the reference count on m_pCert and
cleans it up if reference count is zero.
Thanks for providing a new style of assignment operator. I ll definitely
give it a try.
Regards,
"Tom Widmer" <tom_usenet@hotmail.com> wrote in message
news:OWkwYSCRFHA.2664@TK2MSFTNGP15.phx.gbl...
> Hashim Saleem wrote:
> [SNIP]
> Does your default constructor set m_pCert to NULL? What happens if
> CERT_DupCertificate fails? And are you sure it is correctly implemented?
>
> Also, have you come across this style of operator== implementation:
>
> A& operator=(A a) //parameter passed by value to create copy
> {
> a.swap(*this);
> return *this; //a's destructor frees old members.
> }
>
> All you need to do is implement a swap function, and no need to check for
> self-assignment. And it is exception-safe, unlike your version.
>
> Tom
| |
| Simon Trew 2005-04-19, 8:58 am |
| "Tom Widmer" <tom_usenet@hotmail.com> wrote in message
news:uJPEiBCRFHA.2736@TK2MSFTNGP09.phx.gbl...
> Simon Trew wrote:
>
> std::string (the key type used) has them already!
>
> Tom
Yep, I got mixed up in all that code.
|
|
|
|
|