C++ Tutorials - Absolute n00b spoonfeed

This piece of code will compile and run just fine. However something is really wrong here. Can you find out what

Code: Select all

#include <iostream>

using namespace std;

class Foo
{
protected:
     const int foo;
public:
     Foo();
     Foo(int);
     const int * getFoo(void) const;
};

class Bar : public Foo
{
     const int bar;
public:
     Bar();
     Bar(int);
     const int * getBar(void) const;
     const int * getFooBar(void) const;
};

Foo::Foo() : foo(0)
{
}

Foo::Foo(int _foo) : foo(_foo)
{
}

const int * Foo::getFoo(void) const
{
     return &foo;
}

Bar::Bar() : Foo(1), bar(0)
{
}

Bar::Bar(int _bar) : Foo(_bar + 1), bar(_bar)
{
}

const int * Bar::getBar(void) const
{
     return &bar;
}

const int * Bar::getFooBar(void) const
{
     return &foo;
}

int main (int argc, char *argv[])
{
     Foo foo;
     Bar bar(4);
     int m = 10;
     int *o;
     const int *p = foo.getFoo();
     const int *n = &m;
     m += *n + *p;
     const int **q = const_cast<const int **>(&o);
     *q = p;
     q = NULL;
     cout << "Foo::foo + Bar::foo is " << *foo.getFoo() + *bar.getFooBar() << endl;
     *o = m;
     cout << "m + Foo::foo + Bar::foo is " << m + *foo.getFoo() + *bar.getFooBar() << endl;
}



Hm, we haven't gone into inheritance just yet

antiRTFM wrote:Hm, we haven't gone into inheritance just yet

I've seen more than one on this forum expressing to have at least average or above average knowledge of C++. Well this is the kind of challenges that are needed. Not everyone needs to be spoon fed
I was hoping to get some people to try and solve it. But so far, unfortunately not. In my opinion there's way too much talk about C++ on this forum instead of actual code challenges. You also learn by coding and not just talking or debating what's best in C++.


Before your summer break you were the one who stimulated to learn more about C++, if you don't want to wait for future video's. I for one did. If you think I'm overdoing it with this debug challenge, then you can delete the post.

If i got that far (just getting into pointers) then i'd surely have a go at it
Though hell, i'm taking a c++ course, and just because i love learning it, i spent a long time just learning it on my own (Like with antiRTFM's helpful videos i mean)

OMG!!! I hate Dealing with Class inheritance, not that it's not useful, but learning about it SUCKS!!!!!!!!!!!

That was probably the most boring thing of my life. lol.

I don't have much time to look at the code, I might take a peak at
it if I have time later.

C++ wrote:

antiRTFM wrote:Hm, we haven't gone into inheritance just yet

I've seen more than one on this forum expressing to have at least average or above average knowledge of C++. Well this is the kind of challenges that are needed. Not everyone needs to be spoon fed
I was hoping to get some people to try and solve it. But so far, unfortunately not. In my opinion there's way too much talk about C++ on this forum instead of actual code challenges. You also learn by coding and not just talking or debating what's best in C++.


Before your summer break you were the one who stimulated to learn more about C++, if you don't want to wait for future video's. I for one did.

I agree 100%.

Actually i was trying to clear things up for those who don't understand all that inheritance code yet, so i replied with a comment thats in the tone of a perplexed n00b

I know java inheritance Infact, in the book I'm reading, we go over inheritance next chapter, so I'll try to look at this after reading it

Marss++ wrote:OMG!!! I hate Dealing with Class inheritance, not that it's not useful, but learning about it SUCKS!!!!!!!!!!!

That was probably the most boring thing of my life. lol.

I don't have much time to look at the code, I might take a peak at
it if I have time later.

The code I wrote is just the very basics of inheritance. It really isn't a hard concept to grasp. It can get a little confusing when dealing with polymorphism or abstract classes, but I had no problems understanding it so far.

I'll give a clue to everyone to make it a bit easier. The problem has nothing to do with the derived class or inheritance. Try to think more constant

antiRTFM wrote:I agree 100%.

Actually i was trying to clear things up for those who don't understand all that inheritance code yet, so i replied with a comment thats in the tone of a perplexed n00b

Ok, let's get one thing straight. It wasn't meant to criticize anything you're doing. I was referring to the forum in general. Everyone needs books or great video tutorials like yours to learn. But fooling around with foobars is not only fun but educational as well.

I didn't say it was hard I just was saying that learning about class inhertance was a really boring stage for me.

From Java, I'd say polymorphism and abstract classes/data mebers/member functions are pretty simple to be honest, C++. And the great thing about them is you can supply them as arguments and such. Interfaces is where it can get slightly confusing I reckon.

Marss++ wrote:I didn't say it was hard I just was saying that learning about class inhertance was a really boring stage for me.

Cool, what's the solution?

Well maybe I was a bit too enthusiastic when posting this challenge, so here's the solution.

Code: Select all

int main (int argc, char *argv[])
{
     Foo foo;

     Bar bar(4); // This creates a derived object from Foo. base class gets passed 4 + 1 in the constructor.

     int m = 10;
     int *o;

     const int *p = foo.getFoo(); // Return a const pointer to foo

     const int *n = &m; // load a const pointer with the address of non const int m. This is perfectly legal to do so.

     m += *n + *p; // 10 + 10 + 0 = 20

     const int **q = const_cast<const int **>(&o); // BAD!!! this can be used to circumvent access rules, see further.

     *q = p; // now non const int pointer o will point to private member foo!!!

     q = NULL; q is no longer needed

     cout << "Foo::foo + Bar::foo is " << *foo.getFoo() + *bar.getFooBar() << endl; // Result is like you would expect. 0 + 5 = 5

     *o = m; // Hmm seems to be an uninitialized pointer, but it got initialized through pointer q, and points to private member foo, which was protected by const pointer p. But not anymore!

     cout << "m + Foo::foo + Bar::foo is " << m + *foo.getFoo() + *bar.getFooBar() << endl; // foo is changed by circumventing access rules! 20 + 20 + 5 = 45!
}


So this shows the danger of using something as casting. If I'd remove the cast the compiler would rightfully so complain about trying to init a const **q to a non const one. However it does not complain when you try to assign a non const *pointer to a const *pointer, It does complain because you'd be able to change to what type of pointer *q is pointing to. One way of solving this would be to declare pointer q as follows.

Code: Select all

const int *const *q = &o


Now you can't dereference *q and change to what pointer *q is pointing to. You can only do this now by changing the address of pointer o. And you can't assign a const pointer to a non const pointer without a cast.