• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

actual C++ interview question

Joined
12/14/10
Messages
131
Points
38
If a class only has non-const PODs, e.g.

class A
{
int x;
double d;
};

is a copy-constructor auto-generated?
 
What are the default values for the member data?

Another basic test question?

BTW what did the interviewer say?

Another answer; please use rule-of-three?
http://en.wikipedia.org/wiki/Rule_of_three_(C++_programming)

I don't recall exactly. After he said the answer was wrong I clarified that it is only generated if the copy constructor is actually called. But he said something about how a copy constructor shouldn't be called because the class should be treated as a struct of POD??

I was the one that asked about wehter the data members were const, which the Wikipedia article doesn'taddress.

Not having a copy ctor is very bad practice.

It's a bit depressing to be honest. So basic...

Well he started with questions about cache considerations in choosing data structures, which I know nothing about.

The recruiter told me I needed a solid foundation in C++, boost, STL and data structures, and that they would teach low latency programming techniques.
 
Last edited:
The guy is an idiot. I guess he was going for that the copy constructor is "trivial" and one is not defined. When the objects need to be copied, they just use a bitwise memcopy. No need for anyone really to know this
 
That's what I said, but the interviewer said I was wrong.

Yanking my chain I guess, considering the group.
C++Standard Section 12.8 part 7 ($60 from the ANSI Store):

7 If the class definition does not explicitly declare a copy constructor, one is declared implicitly. If the class definition declares a move constructor or move assignment operator, the implicitly declared copy constructor is defined as deleted; otherwise, it is defined as defaulted (8.4). The latter case is deprecated if the class has a user-declared copy assignment operator or a user-declared destructor. Thus, for the class definition
C++:
struct X {
    X(const X&, int);
};

a copy constructor is implicitly-declared. If the user-declared constructor is later defined as
C++:
X::X(const X& x, int i =0) { / ... / }
then any use of X’s copy constructor is ill-formed because of the ambiguity; no diagnostic is required.

Check this link for the current drafts.

PS - Forward that to the guy, and if he still says you are wrong, tell him to go fck himself
 
C++Standard Section 12.8 part 7 ($60 from the ANSI Store):

7 If the class definition does not explicitly declare a copy constructor, one is declared implicitly. If the class definition declares a move constructor or move assignment operator, the implicitly declared copy constructor is defined as deleted; otherwise, it is defined as defaulted (8.4). The latter case is deprecated if the class has a user-declared copy assignment operator or a user-declared destructor. Thus, for the class definition
C++:
struct X {
    X(const X&, int);
};

a copy constructor is implicitly-declared. If the user-declared constructor is later defined as
C++:
X::X(const X& x, int i =0) { / ... / }
then any use of X’s copy constructor is ill-formed because of the ambiguity; no diagnostic is required.

Check this link for the current drafts.

PS - Forward that to the guy, and if he still says you are wrong, tell him to go fck himself

LOL, that's made my day :D
 
LOL, that's made my day :D

Yea made my day too because their is NOT a copy constructor auto generated and the guy thinks he is smarter than he is. Please read about "trivial copy constructors" with only "POD" members. This is to be backwards compatible (and avoiding a total waste of cycles) with C and the case
struct
{
int c;
};
not needing a copy constructor
 
Yea made my day too because their is NOT a copy constructor auto generated and the guy thinks he is smarter than he is. Please read about "trivial copy constructors" with only "POD" members. This is to be backwards compatible (and avoiding a total waste of cycles) with C and the case
struct
{
int c;
};
not needing a copy constructor

All the references I've ever seen (including the one cited by Pingu) state there is a default copy constructor for any class that does not have one defined by the user. And a struct in C++ is a class. So where's your reference for this supposed special case?
 
Yea made my day too because their is NOT a copy constructor auto generated and the guy thinks he is smarter than he is. Please read about "trivial copy constructors" with only "POD" members. This is to be backwards compatible (and avoiding a total waste of cycles) with C and the case
struct
{
int c;
};
not needing a copy constructor

So it appears that the interviewer was for the most part correct, though it was a bit of a trick question. An implicit copy constructor is automatically declared but not auto-generated in the sense of an actual compiled function body.

Now my understanding is that when a trivial copy constructor is called, the compiler implements it using std::memmove (which as you pointed out avoids wasting clock cycles). As far as the interviewer's comment that the copy constructor should not even be used (I guess he means std::memmove should be manually done instead), I think this is an opinion at best. It seems like better coding style to use a copy ctor, though manual construction is a stronger guarantee of the described behaviour.
 
So it appears that the interviewer was for the most part correct, though it was a bit of a trick question. An implicit copy constructor is automatically declared but not auto-generated in the sense of an actual compiled function body.
...
.

Thanks Milo, I agree, he is correct, but the question is useless except if the person is interview for some compiler some or something like that
 
So it appears that the interviewer was for the most part correct, though it was a bit of a trick question. An implicit copy constructor is automatically declared but not auto-generated in the sense of an actual compiled function body.

That's just semantics. The constructor is still auto-generated in the sense that is giving to you by the compiler, implicitly.

C++Standard Section 12.8 part 15 and 16 (again $60 from the ANSI Store):

15 The implicitly-defined copy/move constructor for a non-union class X performs a memberwise copy/move of its bases and members. [ Note: brace-or-equal-initializers of non-static data members are ignored. See also the example in 12.6.2. —end note ] The order of initialization is the same as the order of initialization of bases and members in a user-defined constructor (see 12.6.2). Let x be either the parameter of the constructor or, for the move constructor, an xvalue referring to the parameter. Each base or non-static data member is copied/moved in the manner appropriate to its type:
(15.1) — if the member is an array, each element is direct-initialized with the corresponding subobject of x;
(15.2) — if a member m has rvalue reference type T&&, it is direct-initialized with static_cast<T&&>(x.m);
(15.3) — otherwise, the base or member is direct-initialized with the corresponding base or member of x.
Virtual base class subobjects shall be initialized only once by the implicitly-defined copy/move constructor (see 12.6.2).

16 The implicitly-defined copy/move constructor for a union X copies the object representation (3.9) of X.

PS - Again, tell him to go fck himself.
 
yup, some people learn from their mistakes, others stick to their guns no matter how silly it makes them look.

Implicitly-defined copy constructor

If the implicitly-declared copy constructor is neither deleted nor trivial, it is defined (that is, a function body is generated and compiled) by the compiler if odr-used. For union types, the implicitly-defined copy constructor copies the object representation (as by std::memmove). For non-union class types (class and struct), the constructor performs full member-wise copy of the object's bases and non-static members, in their initialization order, using direct initialization.

http://en.cppreference.com/w/cpp/language/copy_constructor

I guess you know more than all of these people.
 
I don't think a conforming implementation is obliged to generate and compile a function body for the copy ctor here -- at least not based on the code given. What's missing is either odr-use or explicit defaulting after first declaration (see below).

It's the difference between implicitly-declared vs. implicitly-defined -- only the latter case would imply actual function body code generation possibility (although not the obligation, since the implementation is allowed to elide).

I think the implicitly-declared part is fine. In fact, in the C++03 Standard we had a clear wording "A copy constructor for class X is trivial if it is implicitly declared [...]", which is not present in the more recent draft I'm looking at (N4140).

Now, regarding the implicitly-defined part:
In N4140 this is 12.8 [class.copy] /13; we have: "A copy/move constructor that is defaulted and not defined as deleted is implicitly defined if it is odr-used (3.2) or when it is explicitly defaulted after its first declaration. [Note: The copy/move constructor is implicitly defined even if the implementation elided its odr-use (3.2, 12.2). —end note ]"

To illustrate the above -- here's a piece of code (with the generated assembly for illustration):
C++:
class A
{
  int x;
  double d;
};

int main()
{
  A a;
}

/*
Clang 3.7:
main:  # @main
   push   rbp
   mov   rbp, rsp
   xor   eax, eax
   pop   rbp
   ret

GCC 4.9.2:
main:
   push   rbp
   mov   rbp, rsp
   mov   eax, 0
   pop   rbp
   ret

Note: I have NOT odr-used any copy constructors (I've only odr-used `A`s default ctor) -- hence, no copy constructors are defined (implicitly or not).

Now, to see the contrast, let's odr-use `A`s trivial copy constructor:

C++:
class A
{
  int x;
  double d;
};

int main()
{
  A a;
  A b(a);
}

/*
Clang 3.7:
main:  # @main
   push   rbp
   mov   rbp, rsp
   xor   eax, eax
   mov   rcx, qword ptr [rbp - 16]
   mov   qword ptr [rbp - 32], rcx
   mov   rcx, qword ptr [rbp - 8]
   mov   qword ptr [rbp - 24], rcx
   pop   rbp
   ret

GCC 4.9.2:
main:
   push   rbp
   mov   rbp, rsp
   mov   rax, QWORD PTR [rbp-32]
   mov   rdx, QWORD PTR [rbp-24]
   mov   QWORD PTR [rbp-16], rax
   mov   QWORD PTR [rbp-8], rdx
   mov   eax, 0
   pop   rbp
   ret
*/

Note that this is exactly as the Standard's note says -- "The copy/move constructor is implicitly defined even if the implementation elided its odr-use (3.2, 12.2). " -- so, the implementations (both with disabled optimizations, i.e., -O0; also both with -std=c++11) have elided the `call A::A(A const&)`, but it _is_ defined (with the corresponding data transfers via `mov` inlined into the generated `main`s body).

// (Note: members `x` and `d` are default-initialized to indeterminate values. I'm wondering, perhaps this was the reason for the interviewer's issue with copying things around?)
 
Last edited:
yup, some people learn from their mistakes, others stick to their guns no matter how silly it makes them look.

Implicitly-defined copy constructor

If the implicitly-declared copy constructor is neither deleted nor trivial, it is defined (that is, a function body is generated and compiled) by the compiler if odr-used. For union types, the implicitly-defined copy constructor copies the object representation (as by std::memmove). For non-union class types (class and struct), the constructor performs full member-wise copy of the object's bases and non-static members, in their initialization order, using direct initialization.

http://en.cppreference.com/w/cpp/language/copy_constructor

I guess you know more than all of these people.

These kinds of interviews must be mind-numbing.
 
I don't think a conforming implementation is obliged to generate and compile a function body for the copy ctor here -- at least not based on the code given. What's missing is either odr-use or explicit defaulting after first declaration (see below).

It's the difference between implicitly-declared vs. implicitly-defined -- only the latter case would imply actual function body code generation possibility (although not the obligation, since the implementation is allowed to elide).

I think the implicitly-declared part is fine. In fact, in the C++03 Standard we had a clear wording "A copy constructor for class X is trivial if it is implicitly declared [...]", which is not present in the more recent draft I'm looking at (N4140).

Now, regarding the implicitly-defined part:
In N4140 this is 12.8 [class.copy] /13; we have: "A copy/move constructor that is defaulted and not defined as deleted is implicitly defined if it is odr-used (3.2) or when it is explicitly defaulted after its first declaration. [Note: The copy/move constructor is implicitly defined even if the implementation elided its odr-use (3.2, 12.2). —end note ]"

Actually, the interviewer claimed that "a copy ctor is not generated". If "function body code generation" includes inlined functions, then I believe your quote from the standard, and also your code example, prove him wrong. If the copy ctor is used (i.e. odr-used) then the code is generated for the copy ctor (with the exception of elision).

Another reference, Scott Meyer's Effective C++, also states [Item 5] that the compiler generates the implicitly-declared copy ctor "if it is needed".

The only way I can make sense out of his comment is if "generated" is interpreted to mean "code is generated for a non-inlined function ", and even then I doubt the standard guarantees that an implicitly-defined copy ctor is inlined (it is implicitly-declared inline, but that is normally only a hint to the compiler).

...

// (Note: members `x` and `d` are default-initialized to indeterminate values. I'm wondering, perhaps this was the reason for the interviewer's issue with copying things around?)

Implicitly-defined copy constructor

If the implicitly-declared copy constructor is neither deleted nor trivial, it is defined (that is, a function body is generated and compiled) by the compiler if odr-used. For union types, the implicitly-defined copy constructor copies the object representation (as by std::memmove). For non-union class types (class and struct), the constructor performs full member-wise copy of the object's bases and non-static members, in their initialization order, using direct initialization.

http://en.cppreference.com/w/cpp/language/copy_constructor

In case your reference also applies to trivial copy ctors, i.e. if "the constructor performs full member-wise copy of the object's bases and non-static members", then the interviewer is correct from a low-latency perspective that the copy ctor should not be used, because it will be less efficient than std::memmove.

In fact, in Polter's code example, my understanding of the generated assembly is that the two members are each being copied separately, rather than the while object being copied at once.
 
Last edited:
i think a default copy constructor and assignment operator is always provided in a class. They instead perform bit wise copy(shallow copy) instead of deep copy. This Q itself is little bit unclear. u should just provide more details next time.
 
Back
Top