Quote:Original post by theOcelot
Maybe I'm missing something, but couldn't you just make SimpleImage automatically copy when constructed with a third-party handle? Is there ever a time when you don't want it to do that?

For our situation, almost always...

As a side note here's what the problem:
- 20 yr old code
- 3 different image libs, all 3rd party and very old
- Proprietary image lib desired (there is good reason for this)
- How to do all this incrementally?
- Main SimpleImage class wants to use proprietary stuff
- But it can use 3rd party stuff (keyword here is incrementally), but we don't want the performance penalty of making copies of potentially huge images hundreds of times a second. We can't replace code every where at once.
- As we remove dependance on 3rd party stuff and add functionality to proprietary lib, code that uses SimpleImage class already works.

That's it in a nutshell. 3rd party image handles from multiple image libs are scattered all over (in fact many of them are public class members!! And these handles tend to be either integers that mean "something" to the library, or a direct pointer!). So simultaneously we're trying to make the code safer as well - and it's really nasty at places. All the while this all has to be done on the side while we add features according to requirements from boss's boss. As an example, in one class, by replacing 3rd party stuff with our own over the last couple years (plus some other refactoring to a small extent), the line count for the class has gone from 25,000 to just over 10,000.

So you need a separate function to create the copy of the data.

SimpleImage x = SimpleImage::copy(handle); //this is a normal thing to doSimpleImage x = SimpleImage(handle); //being different fromSimpleImage x(handle); //is not normal semantics

Quote:Original post by popsoftheyear
My point was that it turned out that

T x = T(a); // or T x(T(a));

and

T x(a);

were coming out to be the same. I had expected the first one to create a temporary T, and it didn't.

My understanding of the standard is that

T x = a;

is semantically equivalent to

T x = T(a);

which is likewise equivalent to

T x(T(a));

However, an implementation is free to (and almost certainly will) optimise out the temporaries. The following section of the standard I think specifies this:

Quote:
From section 8.5:

Otherwise (i.e., for the remaining copy-initialization cases), user-defined conversion sequences that can convert from the source type to the destination type or (when a conversion function is used) to a derived class thereof are enumerated as described in 13.3.1.4, and the best one is chosen through overload resolution (13.3). If the conversion cannot be done or is ambiguous, the initialization is ill-formed. The function selected is called with the initializer expression as its argument; if the function is a constructor, the call initializes a temporary of the cv-unqualified version of the destination type. The temporary is an rvalue. The result of the call (which is the temporary for the constructor case) is then used to direct-initialize, according to the rules above, the object that is the destination of the copy-initialization. In certain cases, an implementation is permitted to eliminate the copying inherent in this direct-initialization by
constructing the intermediate result directly into the object being initialized; see 12.2, 12.8.

(emphasis mine)

Quote:Original post by popsoftheyear

Quote:Original post by theOcelot
Maybe I'm missing something, but couldn't you just make SimpleImage automatically copy when constructed with a third-party handle? Is there ever a time when you don't want it to do that?

For our situation, almost always...

As a side note here's what the problem:
- 20 yr old code
- 3 different image libs, all 3rd party and very old

It sounds like you're already wrapping the APIs, though. Isn't the purpose of that wrapping to make it so that you can swap them for ones that behave better? :)