I got compile failures because GCC balks at using copy-style initialization without a public copy constructor. I have no idea how MSVC++ compiles that code, it shouldn't. Try turning up the warning level on your compiler to 11 ( or at least d10+1).
I believe the compiler is allowed to elide the copy constructor in such a statement (C++ standard section 12.8/15). GCC might be stricter about requiring the copy constructor to be present however, even if it will go unused.
[/quote]
[12.1](11) says this.
A functional notation type conversion (5.2.3) can be used to create new objects of its type. [ Note: The
syntax looks like an explicit call of the constructor. —end note ] [ Example:—end example ][/quote]
complex zz = complex(1,2.3);
cprint( complex(7.8,1.2) );
The next paragraph, [12.1](12) says this.
An object created in this way is unnamed. [ Note: 12.2 describes the lifetime of temporary objects. —end note ]
[ Note: explicit constructor calls do not yield lvalues, see 3.10. —end note ]
[/quote]
The, jumping to [12.2](1), we get the following snippet.
Even when the creation of the temporary object is avoided (12.8), all the semantic restrictions shall be respected as if the temporary object had been created.
[ Note: Even if the copy/move constructor is not called, all the semantic restrictions, such as accessibility (Clause 11), shall be satisfied.
[/quote]
Later on, [12.8](33) has this to say.
A program is ill-formed if the copy/move constructor or the copy/move assignment operator for an object is implicitly used and the special member function is not accessible (Clause 11).
[/quote]
Sound pretty clear and explicit to me. The inline notes are considered normative. The end result is that the compiler is allowed to elide the copy constructor but that constructor must be in scope and accessible.
If compiler accepts a functional notation type conversion syntax for object construction and the class of that object has a private copy constructor, that compiler is not conformant. It's possible that MSVC++ is conformant but its standard library provides implicit public copy constructors for its IOStreams classes. There is nothing I can find in the standard requiring or forbidding copy semantics on a std::fstream but there are better language lawyers than I.
Odd memory problems with classes
Author
I got compile failures because GCC balks at using copy-style initialization without a public copy constructor. I have no idea how MSVC++ compiles that code, it shouldn't. Try turning up the warning level on your compiler to 11 ( or at least d10+1).
I believe the compiler is allowed to elide the copy constructor in such a statement (C++ standard section 12.8/15). GCC might be stricter about requiring the copy constructor to be present however, even if it will go unused.
[/quote]
What is the warning number for this, anyway? I want to add these warnings individually because when I set my warning level higher my compiler complains about the Windows 7.1 SDK about a thousand times.
Apologies - I wasn't trying to say it was right in not checking that the copy constructor exists. I was merely saying that this elison might be the reason the call isn't checked - the compiler doesn't omit a call to the copy constructor, and the semantic verification obviously doesn't account for this early enough.
AFAIK std::fstreams are not copyable under MSVC++.
AFAIK std::fstreams are not copyable under MSVC++.
Yikes, a professor recommending an IDE upgrade to fix a code issue. Would definitely make me think twice about who is teaching and what is being taught...
Author
Ok, so I moved the namespace, I added initialization lists where they were obviously needed (there are still places that need them), and I took out all the unnecessary copying.
I will eventually add destructor and copy methods where needed and then add some logging as suggested by Bregma.
(and I've updated the repository)
I will eventually add destructor and copy methods where needed and then add some logging as suggested by Bregma.
(and I've updated the repository)
Author
I started reading Effective C++ v2 today, and I've already come across many points that you guys have suggested.
I'm going to take a hiatus on my game for a few weeks to focus on preparing for an interview... after that I'll do some major cleaning up.
I'm going to take a hiatus on my game for a few weeks to focus on preparing for an interview... after that I'll do some major cleaning up.
Since you're using Actor as a polymorphic base class, it needs a virtual destructor. Deleting an Asteroid object through an Actor pointer without a virtual destructor yields undefined behavior.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
