yurakm
Member
Posts: 149
Joined: May 2005
|
Sun Jan 17, 10 09:06 PM
|
|
I assume that the interview will be mostly devoted to a numerical methods and financial models, not to a C++ proper. However:
It is impossible to learn C++ fast, unlike C. Depending on how much time you have to prepare (one weekend or two weeks, for example), I would suggest to read / understand about:
- good understanding of pointers, pointer arithmetics, relations between pointers and arrays, syntax p[n] where p is a pointer. Actually it is C stuff, not specific to C++, but still a lot of people are uncomfortable with it to substantial extent.
- pointers to pointers (also a C stuff). For example, how to write a list (in C) minimizing special case processing of a first record / root pointer. Answer - to use pointer to the root pointer or a pointer 'next', instead of a pointer to a record.
- temporaries (expressions, values returned by functions), where they live, and how long they live. Special case - how long lives a temporary assigned to a const reference.
- references and their relation to pointers (in substance, a C++ reference is almost the same thing as a const pointer with a different syntax - but not just a pointer, nor a pointer to const)
- const in different settings:
-- const integers (char, int, long)
-- const pointers - and pointers to const - and const pointers to const
-- const in function (methods) parameters
-- const methods (const relatively a hidden paramter - an instance of a class that owns the method)
-- const-like attributes: volatile and mutable
-- const references and relations to temporaries (the question concerns const, temporaries, and references together, see above)
- order of evaluation of terms in expressions, function parameters : in many cases the order is not standardized in C++, that may cause a portability problem, even to a next version of the same compiler or between a debug and optimized builds.
- how a function return it value (two different ways are permitted by standard, that imposes semantic requirements on copy constructor)
Caution: There are very tricky aspects, related to a return of a std::auto_ptr or, even worse, of a class that contains std::auto_ptr. Hopefully, your interviewer will not ask, because he does not know to handle it himself. Or, if he know how, he understands that it is not worthwhile in the first place - better to use a boost::shared_ptr instead.
The above would probably take one weekend; actually it may take an evening only to refresh if you used to know most of the stuff but did not code in C++ for several years
If you have one week:
- operators, like opreator += (C & left, const C & right)
- classes and structures
- any class, even an empty class, i.e a class without data members, takes at least 1 byte of memory (sizeof > 0)
- inheritance, virtual methods, vtable, abstract classes, pure virtual classes
- upcast and downcast; static and dynamic casts, RTTI, typeid, typeinfo. Particularly, when dynamic cast throws and when returns NULL. And that the technique is inapplicable to classes that do not have virtual methods
- public/private/protected (particularly protected)
- friends (very rarely used, but often asked on interviews)
- operators as member of classes, e.g. operator += (const C & right)
- type conversions via a constructor with one argument ("import") or via operator ("export"). Keyword explicit. Tricky question - why copy constructor should not be explicit.
- implicit calls to copy constructors, particularly when passing arguments to function by value, or returning a function value.
- four things that C++ generates automatically if you do not declare them in classes: default constructor, default destructor, copy constructor, and assignment operator.
- declared constructor (with any parameters) precludes an automatic generation of a default constructor
- initialization of class members and parent classes (not in a body of constructor); order of the initialization.
- virtual destructor and why destructor should be virtual. Or, even better, when it should be virtual, when it should not, and when it does not matter.
Multiple inheritances, particularly virtual inheritance, is a thorny subject. Many shops even prohibit multiple inheritances, or limit them to Java-style cases, requiring that all parents but one should be pure virtual. If you do not know them, it is fine - very probably the interviewer does not know them either, and any case it is very typical even for decent to good C++ programmers. If you know them well, it is fine too. The worst case is if you do not know that it is tricky.
- Operators new and delete; array versions; a difference between them and malloc/free
(it may be dangerous somewhat, because interviewers often do not know or did not think trough some fine points themselves in my experience. Also, interviewers like to ask questions how memory management libraries are implementing malloc/free - that is not a part of C++, or even of C).
- More advanced: a placement version of operator new
- STL: it is a very big topic.
Many programmers think that they know STL, while in reality they know how to write std::vector, std::string, std::list, and may be few more containers. STL is much bigger than containers; particularly, <algorithm> contains about 50 canned algorithms that work on pair of iterators. Most widely used of them are copy, transform, sort, and for_each; however, it always is worthwhile to scan a list of the algorithms before coding your own. You may find a little jewel like n-th element when you want to extract efficiently a median or other percentile, for example.
I would suggest to scan through STL algorithms while preparing to interview, and to learn only may be 5 of them. No time for more, and probably mo use either. Also, learn std::set, std::map, and other containers like priority queue. I would not expect questions about <functional> on interview; when coding <functional> was very useful, but boost provides better alternatives now.
Concerning maps: operator [] creates a new element of the map with the key and a default value, if the map did not contain such an element already. A corollary: operator [] is not const, (relative to the underlying map). Both limit severely the usage of the operator, particularly when a map is const. Method 'find' is used instead.
- exceptions
== I am afraid that it is too much already ==
|
|
.jpg)
