bergjensen33 wrote: |
---|
Let's take class constructors and destructors as an example. I understand what it is, but I cannot think of a class I'd create that would have one. |
The purpose of a constructor is to initialise the member variables of the class or struct.
There are a number of ways this can happen:
1. default behavior, as in specifying
default()
for a constructor;
2. specifying default values for each member yourself in the class definition;
3. have your own constructor that takes arguments, and set the values of each member with a member initialiser list.
The last one is probably a quite common way of creating an object with particular values.
The first two can create an object with default values, but we want avoid doing this then set the values later: it is more efficient to use method 3 to do it all at once. Some of the STL functions such as
emplace_back
, call the constructor to create the object directly in the container.
With destructors it is quite common to just use the default behaviour, that is not write your own destructor. But there are times when one needs to write a destructor. One example is for a RAII class: obtain a resource in the constructor, destroy it in the destructor.
bergjensen33 wrote: |
---|
Another example is std::set. What are its advantages over other containers? Why so many containers? |
Various STL containers are implemented with different data structures. Side Note: The C++ standard does not specify how a container should be implemented. Each data structure has it's own advantages and disadvantages: some are fast at finding values; some are fast at inserting at beginning or end; some of them are associative - they have a key value pair and use hash functions.
One can look on cppreference to see what the various pro and cons are :
https://en.cppreference.com/w/cpp/container
One thing to note though, there are several things which affect the performance of container operations, according to Bjarne Stroustrup: move semantics; concurrency; and cache effects.
Sometimes the performance can be surprising. I once tried the hypotheses that an
std::unordered_map
might be faster than a
std::vector
to find a value because it uses a hash function. But for anything up to 8 million ints (on my machine) the vector could create all the values,
sort them, then find the value
quicker than unordered map could create values and lookup using the hash function. It was
JLBorges who educated me about this.
I guess the thing to realise is that programming in general is a vast field - there is a lifetime of learning. I would even go so far as to say there is a lifetime of learning just in C++, partly due to new standards and library features coming out every 3 years.
It is not enough to just learn the features of a language: one has to learn quite a bit about computer science theory; things like design patterns; idioms; good practise; the list goes on .......
With my first C++ text book, I read the whole thing over a weekend. Some of the things I learnt: overloaded functions do this; classes do this; templates do this; iterators do this etc. But that was just the barest scratch on the tip of the iceberg. For example, classes sound like a simple concept, but saying that I know what a class and inheritance is, so now I know how to do OO programming, is utterly false.
I am not trying to put you off here, plug away at learning stuff a small piece at a time. Gradually the pieces will fit together, you will feel more confident as time goes on. Ask questions here, there are plenty of people who know their stuff. We have a number of people who I consider experts.