std::vector<const MyType> not allowed

M

muzicmakr

I'm porting some code from windows to mac, and there are some
instances of std::vector<const MyType>, that compiled just fine on the
pc, but won't compile under gcc.

I'd never tried to do this particular construct myself, and after some
searching online, I found a post somewhere saying this isn't legal c++
because the standard containers need types that are assignable.

My questions-- is that correct? Why does visual studio allow it if
it's wrong? And is there some other way to try to preserve the intent
of the original? (Otherwise I'm just going to strip out the
consts.)

Thanks for your time!

mich
 
J

James Kanze

I'm porting some code from windows to mac, and there are some
instances of std::vector<const MyType>, that compiled just
fine on the pc, but won't compile under gcc.
I'd never tried to do this particular construct myself, and
after some searching online, I found a post somewhere saying
this isn't legal c++ because the standard containers need
types that are assignable.
My questions-- is that correct? Why does visual studio allow
it if it's wrong?

It's undefined behavior. It may cause an error when compiling,
it may compile, but do strange things during execution, or it
may work just fine.
And is there some other way to try to preserve the intent of
the original? (Otherwise I'm just going to strip out the
consts.)

What is the intent of the original? Given the semantics of
vector, having a non-const vector of const objects doesn't make
much sense. And if you declare an std::vector< MyType > const,
there's no way you can get a non-const reference to any of the
elements.
 
L

Lance Diduck

My questions-- is that correct?  Why does visual studio allow it if
it's wrong?  
MSVC probably allowed it because your code never uses a member
function that cared whether T was const or not. This is an example of
a struct that in one version allows a const whereas the other does not
template<class T>
struct Foo{
Foo(){}
#ifdef ALLOW_CONST_T
Foo(T const&v):var(v){}
#else
Foo(T const&v){
var=v;
}
#endif
T var;
};

Whether I define ALLOW_CONST_T or not does not change the behavior of
Foo(other than performance in certian cases of T) but one version
allows Foo<const X> and the other does not. And that only applies if
the user of Foo actually invokes that particular constructor.
So what is likely happening is that the particular mixture of user
code and how the container was implemented never actully hit upon
something that cared about the constness of T, whereas in the gcc
version it did.
Lance
 
P

pjp

 application_pgp-signature_part
< 1KViewDownload





That is correct.


Because the very last thing that Microsoft wants you to do is write portable
code that complies with commodity standards that are not controlled by
Microsoft. Microsoft would like nothing more than to force you to write code
that compiles only on Windows.

Nice guess, if a bit paranoid, but you're wrong. Dinkumware added the
capability to declare a container of const type because -- are you
ready for this? -- customers demanded it. And now the latest revision
of the C++ Standard calls for *all* implementations to support vectors
of const type for all operations that make sense.

So much for vendor lock in.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top