Do you know the C++ base language?

simeonz (490)
You are given a C++ test:

* Addresses each famous caveat. The question is in the form of example code. You have to say if there is a bug, describe the cause, propose a solution.
(Let's say wrong answer corresponds to a run-time failure, assuming that you use the respective functionality.)

* Doesn't include how-to questions.
(Because the ignorance there is less directly harmful.)

* Doesn't include questions about protocol.
(Like, what is the type of... returned from...)

* Assume you remember everything you ever truly learned (vs encountered).
(You ate chocolate, carrots, drank vitamins.. I don't know how this works.)

* You make no accidental errors, because today is your lucky day.

---
So, how much errors do you think you will score. I'll go tentatively for 5-6 dozens. No kidding. At least.

(I don't argue that good programming style is ultimately more important, but assume that you are doing code maintenance for someone else.)

---
Here are some example topics (would be example code in the test):

Someone overrides the virtual assignment operator from the base class. No other assignment operators are present. What happens when one object from the derived class is assigned to another object from the derived class. (without using pointer or reference indirection)

Given some code that allocates two blocks of memory (with new) at the start of some block and releases them (with delete) at the end of the block, body code does arbitrary unknown stuff or is empty, could it have a possible memory leak? What are the possible sources?

Some class misses a member from its initialization list. Assume the type of the member is unknown (, because this is a template, or smth.) What can happen besides the member being default constructed?

You inherit two classes that have a common virtual base and you construct them and nothing else in the initialization list. Given that both of them use parametrized constructor for the virtual base in their initialization lists, what bugs can occur?

You read fixed size records from a file in a while loop using unformatted i/o. They are immediately processed in the body of the loop. You only test the eof bit in the controlling condition of the loop. Assuming that the file was successfully open, what are the possible sources of bugs?
...
Kyon (912)
Erm.. I'm not really getting what you're going onto, so I'll just attempt to answer the given example topics:

Someone overrides the virtual assignment operator from the base class. No other assignment operators are present. What happens when one object from the derived class is assigned to another object from the derived class. (without using pointer or reference indirection)
I believe the (derived) virtual operator will be called and executed first, and then the base assignment operator will be called (within the call of the derived operator).

Given some code that allocates two blocks of memory (with new) at the start of some block and releases them (with delete) at the end of the block, body code does arbitrary unknown stuff or is empty, could it have a possible memory leak? What are the possible sources?
A variety of possible sources which are all the same in the end: the block is exited before the deallocation. This can be because of a break, continue, return, goto, throw or assigning a new value without deleting it first to said pointer.

Some class misses a member from its initialization list. Assume the type of the member is unknown (, because this is a template, or smth.) What can happen besides the member being default constructed?
This depends on a few things; the functionality of the class (if pointers are set to NULL a lot of things can happen) and the way the member is being used for this. Given that it can be any member, the worst that can happen is that it is some strange value within the bounds of which it can hold (for standard types, as said, classes and pointers have default values).

You inherit two classes that have a common virtual base and you construct them and nothing else in the initialization list. Given that both of them use parametrized constructor for the virtual base in their initialization lists, what bugs can occur?
Eh?

You read fixed size records from a file in a while loop using unformatted i/o. They are immediately processed in the body of the loop. You only test the eof bit in the controlling condition of the loop. Assuming that the file was successfully open, what are the possible sources of bugs?
The most common error would be that either the badbit or the failbit are set.
Last edited on
simeonz (490)
Erm.. I'm not really getting what you're going onto..
Understandable, what I wrote is a mess. What I meant is: how much rules in the standard that lead to run-time bugs you estimate you don't know? A dozen, two dozens, a few hundred, many, few?

I'll just attempt to answer the given example topics
It wasn't the point really. I don't want to test forum members or some crap like that (even if I find it challenging myself). I am curious about their self-evaluation.

I believe the (derived) virtual operator will be called and executed first, and then the base assignment operator will be called (within the call of the derived operator).
The derived class will be supplied with default/implicit assignment operator for objects of the derived class type. This assignment operator will not be virtual, but will perform member-wise copy of the fields in the derived class that are not in the base class. Then a static call to the base class assignment operator will be performed.
http://stackoverflow.com/questions/969232/why-does-virtual-assignment-behave-differently-than-other-virtual-functions-of-th

A variety of possible sources which are all the same in the end: the block is exited before the deallocation. This can be because of a break, continue, return, goto, throw or assigning a new value without deleting it first to said pointer.
True. The cause I really looked for was the exception thing. The code in the body, or one of the allocations can cause exception. If the second allocation triggers exception then the first allocation is a leak.

Given that it can be any member, the worst that can happen is that it is some strange value within the bounds of which it can hold (for standard types, as said, classes and pointers have default values).
I think so, if I understand you correctly. A member of POD type (kind-of C structure) will then hold arbitrary values in all of its fields.

Eh?
The virtual base will get default initialized. The derived classes expect initialization with particular parametrized constructor and particular constructor arguments, but they will actually host object that is default-initialized and that may violate their assumptions. Of course, this is all bad design to begin with.
http://www.cplusplus.com/forum/general/33843/

The most common error would be that either the badbit or the failbit are set.
This is true, but I was shooting at something else. The eof bit is set after reading past the end of the file. So, after reading the last record it is still not set. Then the loop will enter the body one last time, but there is no more data. So, the read will fail, leaving the record structure at its old state. The last record will be therefore processed twice.

Here is an example program:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
#include <iostream>
#include <fstream>

using namespace std;

int main()
{
    {
        ofstream out("test.bin");

        for (char i = 'a'; i < 'd'; ++i)
        {
            out.write(&i, 1);
        }
    }

    {
        ifstream in("test.bin");

        char i;

        while(!in.eof())
        {
            in.read(&i, 1);

            cout << i << endl;
        }
    }
}

The output is:
a
b
c
c

Regards
Last edited on
tition (887)
You did not include my most frequent mistake:
1
2
3
4
5
6
7
8
9
10
 
  std::vector<std::vector<int> > myBigDataCollection;
  std::vector<int> newEntry;
  myBigDataCollection.push_back(newEntry);
  for (unsigned int i=0; i<myBigDataCollection.size(); i++)
  { std::vector<int>& currentData= myBigDataCollection[i];
    doSomethingWithCurrentData(currentData);
    if (i==0)
      myBigDataCollection.push_back(newEntry);
    doSomethingElseWithCurrentData(currentData);//ouch
  }

Last edited on
simeonz (490)
You did not include my most frequent mistake: ...

Admittedly, the list of things I included is much shorter than it could be. But those were among the most exotic idiosyncrasies I remembered. But yes, your example fits right in.

Every time I learn some new language caveat, it makes me wonder, how many more are there. Having bugs due to incompetence such as this is something I find inexcusable. But recently I gave up hope that I will know the language ever. And what does this mean - I have accepted that I will produce bad code. >:(
tition (887)
Having bugs due to incompetence such as this is something I find inexcusable


Well, since you are finding and fixing your bugs, and presumably have fixed all known bugs (or will very soon), you can't really prove you DO have bugs, so heads up :)

Last edited on
rapidcoder (1010)

Every time I learn some new language caveat, it makes me wonder, how many more are there. Having bugs due to incompetence such as this is something I find inexcusable. But recently I gave up hope that I will know the language ever


Don't worry. There are many caveats more. This is not your fault. The language was based on some very hard to satisfy constraints:

1. to be compatible with C as much as possible
2. not to pay for what you don't use

Language simplicity, clarity and cohesion were never top-priority for C++ designers. Actually the first versions were just hacks over C language. It inherited some caveats of C and added a bunch of new ones. But this is a practical language. In some applicaitons it still hard to replace. And one get used to these caveats and after some time develops ability to code in such a way that they are not a real problem.


Last edited on
simeonz (490)
you can't really prove you DO have bugs
But I can't really prove I don't have bugs either. :)
filipe (1165)
And if you have to bet, you'd best bet you do have bugs...
tition (887)
... and that my boss wants them fixed and that I will be employed as long as there are bugs in my code... ;)


just joking I am not a programmer, my boss doesn't care how I write my code, or even whether I use a computer; he only cares for the end result :)
Topic archived. No new replies allowed.