Thread: Drawing Tool Software Data Structure Questions!

Assuming that you only want shapes, and not free hand drawing such as in MS-Paint or Photoshop, you can use basic polymorphism to model this.

Make an abstract base class shape, and then have each specific shape you want inherit from this base class. Then you can store all the instances in some datastructure, for example a std::vector. Then it is a simple matter of iterating on this vector in your main program loop, calling update and draw routines on each shape. Each shape need only keep track of its top left coordinates and size (YMMV depending on specific shapes). When a user wants to draw a shape, lets say a square, add it to the list, and keep updating its size until the user releases the mouse button.

If you want to support free hand drawing this approach will not be suitable, i suppose you would have to keep track of the entire canvas pixel by pixel in some sort of buffer if this is the case.

I'm not quite sure what this drawShapes class is supposed to represent. You have already outlined some distinct elements that your program needs to have (squares/triangles/circles), why not base the code around these?

I don't have much experience with GUIs but i know that this could be done fairly easily using SFML, its not a GUI library but it saves you the trouble of having to deal directly with OpenGL/DirectX when drawing the canvas, it is very easy to use, the documentation is great and you can combine it with a bunch of existing GUI frameworks for the actual GUI elements.

Originally Posted by MutantJohn

But is there a better OOP I'm ignorant of?

Completely.

This is a classic beginner OOP problem. You should use inheritance and create a Shape class with the data and methods common to all shapes (e.g., position and draw()).

You inherit the specific shapes from the Shape class.

Code:

class Shape {
    Point  m_pos;
    Color  m_colorOutline, m_colorInside;
    //...
public:
    virtual void draw() = 0;
};


class Circle : public Shape {
    size_t m_size;
    //...
public:
    void draw();
};


class Rectangle : public Shape {
    size_t m_hsize;
    size_t m_vsize;
    //...
public:
    void draw();
};


class Triangle : public Shape {
    Point p1, p2, p3;  // points relative to m_pos
public:
    void draw();
};

Note that the draw() function in Shape is (pure) virtual. It needs to be implemented in each shape to draw that particular shape.

Then you keep your shapes in a vector of Shape*. Simply looping through the vector and calling the draw() function on each shape calls the appropriate draw function.

I suggest you read a book on C++.

Okay, so I'm done nerd-raging now. Sorry, Arch totally scared the poop out of me because my stupid Gnome shell took forever to load so I was in no mood to tolerate such useless posts, ooga. You shouldn't even be here if you're going to post like that, tbh.

Okay, so I wrote this code that seems to show what I was talking about, that allocating a new real shape (struct square, circle, triangle) and how the inheritance gives it its own parent class. Or at least, the address aren't the same even for different structs, using inherited data declarations.

Code:

#include <stdio.h>
#include <stdlib.h>

struct foo {


   foo(int x) { 


      a = x;
   }


   int a;
   int b;
   int c;
};


struct bar : foo {


   bar(int x) : foo(x) { }
};

struct qux : foo {


   qux(int y) : foo(y) { }
};

int main(void) {


   struct bar *hope = new struct bar(23);


   hope->b = hope->a + 1;
   hope->c = hope->a + 2;


   struct qux *faith = new struct qux(1);


   faith->b = faith->a*2;
   faith->c = faith->a*3;


   printf("And this is what hope brought : (%d, %d, %d)\n", hope->a, hope->b, hope->c);
   printf("And this is why we have faith : (%d, %d, %d)\n", faith->a, faith->b, faith->c);
   printf("And just to prove they're different parent classes, %p != %p\n", (void*) &hope->a, (void*) &faith->a);


   delete(hope);
   delete(faith);


   return 0;
}

This has output,

Code:

And this is what hope brought : (23, 24, 25)
And this is why we have faith : (1, 2, 3)
And just to prove they're different parent classes, 0x59f8040 != 0x59f8090

So as you can see, both instances of bar inherit the a, b, c fields listed in foo and that they also inherit from different instances of foo as well. Or at least, the inheritance of one is not directly the other. While they may both inherit fields a, b, c, each a, b, c do not have the same memory addresses.

So basically, I just don't think the code you posted really does anything. Oh wait, that wasn't the point!

It was the vectors! That's right, it was the vectors!

I was curious how you could have a vector of different shapes pointed to by the same type. Like, if vector was of type Shape*, then how could it point to other classes? I'm sorry if I'm a C++ newb. Idk what these crazy CS people do. I think they don't actually know what a vector is but that's not relevant now is it?

Final edit : I know that I'm using "struct" and it really bugs C++ programmers. I also know that structs are by default, public, right? I like that. I don't have to tell it to be public which is nice. Also, any competent C++ programmer knows that a struct declaration is handled different than by gcc. g++ reads it more intelligently than gcc does which is why it's nice. C++ is C with a smarter compiler, is all.

By cursor, do you mean the position of the centre of the shape? I.e. Every shape needs a centre, or anchor-point. If so, then yes.
The shapes example is the classic example for advantages of polymorphism. It is literally the text-book perfect case for using polymorphism.
Yes you seem to have answered your own questions for the most of it.

One word of warning though. This kind of thing should be done with no typecasts at all. Generally, the moment you feel the need to typecast, you are doing something wrong. The point of OOP is that the calling code doesn't need to know what type of object it is...
If you want to say draw the object, you just ask the object to do that by calling e.g. it's draw method.
If you want to know the object's colour, you ask the object to tell you.
If you want to know the bounding rectangle of the object, you just ask the object to tell you.
If you want to detect if the user has clicked on the object, you pass it the mouse coordinates, and let it give you the answer as to whether you clicked on it or not.

The caller never has to do the work of finding out what type the object is. Ignorance is bliss! Let polymorphism do that work for you.

Originally Posted by MutantJohn

I was curious how you could have a vector of different shapes pointed to by the same type. Like, if vector was of type Shape*, then how could it point to other classes? I'm sorry if I'm a C++ newb. Idk what these crazy CS people do. I think they don't actually know what a vector is but that's not relevant now is it?

With polymorphism, we use the term "is a" a lot. In this instance, through polymorphism a square is a shape, and so is perfectly happy being referred to through a pointer to a shape.

Final edit : I know that I'm using "struct" and it really bugs C++ programmers. I also know that structs are by default, public, right? I like that. I don't have to tell it to be public which is nice. Also, any competent C++ programmer knows that a struct declaration is handled different than by gcc. g++ reads it more intelligently than gcc does which is why it's nice. C++ is C with a smarter compiler, is all.

struct does not bug most C++ programmers afaik. It's all about how you set the visibility of the members within it that matters.

I second what oogabooga said. You need to read up on C++.

You shouldn't use raw pointers.
You shouldn't use printf.
You shouldn't use new and delete directly, we have smart pointers for that. Or STL containers.
You _definitely_ should not be casting values to void* using C-style casts for the purpose of printing them.

You also seem like you have still to grasp the point of object oriented programming.
The fact that you prefer structs over classes really hammers this point home, you _should_ prefer your data to be private by default, not public. The point of encapsulation is that the outside world knows as little as possible about the internals of the object, and a well designed class will have a simple public interface and then hide everything else that is going on behind the scene. By saying you prefer to have public as the default access specifier you make it sound like you're planning on having a lot of public members, and only a few private, and that is not desirable.

Also, if your first thought is to reach for typecasts, when polymorphism is mentioned, you certainly have some reading to do.

[QUOTE=MutantJohn;1173717...so I was in no mood to tolerate such useless posts, ooga. You shouldn't even be here if you're going to post like that, tbh.[/quote]
That was a little harsh. The best thing for you is to read a beginner's C++ book, actually. C++ is a different beast from C and you need to shed some of these C habits you have. I understand that it may not always be what you want or need or feel like doing, and that's fine; we can still give you good advice and suggestions, but it wasn't such a useless post. I would say it was a good one, to some degree.

So, some advice for your code. Don't use the old C headers. The new C++ headers involves putting a "c" before the name and getting rid of the .h, so:

#include <stdio.h>
#include <stdlib.h>

becomes

#include <cstdio>
#include <cstdlib>

These are all placed in the std namespace and is recommended practice to use.
I strongly recommend that you use the keyword private, protected or public when using inheritance. It explicitly tells what type of inheritance you want to use and makes the code less confusing. You should read up about the different types of inheritance in C++.
You should strive to always use the initializer list, and avoid assignments. It doesn't really matter for primitive types (eg int, float), but it does matter for more advanced types such as strings, vectors, etc.

>>struct bar *hope = new struct bar(23);
The struct keyword can be omitted. Keeping it makes the code more ugly and annoys people, so:
bar* hope = new bar(23);
I still prefer the star to bind to the type.

>>hope->b = hope->a + 1;
This violates encapsulation. Member should be private by default and setter and getter functions should be made to set and get these. You should study the encapsulation and abstraction techniques.

Also as people have said, avoid printf. There's no need for it in C++.

I was curious how you could have a vector of different shapes pointed to by the same type. Like, if vector was of type Shape*, then how could it point to other classes? I'm sorry if I'm a C++ newb. Idk what these crazy CS people do. I think they don't actually know what a vector is but that's not relevant now is it?

This is the point:

Code:

#include <iostream>
#include <vector>

struct Point {};
struct Color {};

class Shape
{
	Point  m_pos;
	Color  m_colorOutline, m_colorInside;
	//...
public:
	virtual void draw() = 0;
};


class Circle: public Shape
{
	size_t m_size;
	//...
public:
	virtual void draw() { std::cout << "Circle::draw\n"; }
};


class Rectangle2: public Shape
{
	size_t m_hsize;
	size_t m_vsize;
	//...
public:
	virtual void draw() { std::cout << "Rectangle::draw\n"; }
};


class Triangle: public Shape
{
	Point p1, p2, p3;  // points relative to m_pos
public:
	virtual void draw() { std::cout << "Triangle::draw\n"; }
};

int main()
{
	std::vector<std::unique_ptr<Shape>> Shapes;
	Shapes.push_back(std::unique_ptr<Shape>( new Circle() ));
	Shapes.push_back(std::unique_ptr<Shape>( new Rectangle2() ));
	Shapes.push_back(std::unique_ptr<Shape>( new Triangle() ));

	// Requires: C++14
	//Shapes.push_back(std::make_unique<Circle>());
	//Shapes.push_back(std::make_unique<Rectangle2>());
	//Shapes.push_back(std::make_unique<Triangle>());
	// End

	for (const auto & Shape : Shapes)
		Shape->draw();
}

Output:
Circle::draw
Rectangle::draw
Triangle::draw

Note the vector has pointers to Shape, yet I put Circle, Rectangle and Triangles in it, and yet magically, the compiler calls the functions in the derived classes.
You can omit the virtual keyword in the derived classes, but I strongly recommend you do not. It documents that they are, in fact, virtual.

Final edit : I know that I'm using "struct" and it really bugs C++ programmers. I also know that structs are by default, public, right? I like that. I don't have to tell it to be public which is nice.

Yes, they do, and that is a bad thing. Hide everything is a good rule. Expose something only if you must. The better you hide things, the more robust your code becomes.

Also, any competent C++ programmer knows that a struct declaration is handled different than by gcc. g++ reads it more intelligently than gcc does which is why it's nice. C++ is C with a smarter compiler, is all.

I certainly don't know that. Why should I?
And no, C++ is not C with a smarter compiler. You are free to believe that, but it's not truth, and I advice you to abandon that line of thinking.
Think: C++ is an entirely different language that is built on top of C.

First things first:

So one thing I'm starting to immediately notice is the use of public vs. private. I get that private is 'safer' than public but unless someone is modifying the source code, code that works and works well works well regardless if it used public vs. private members. Allowing public access does not imply public use, does it? It would just be to block the stupidity of anyone modifying the code itself.

Encapsulation is a cornerstone of object oriented programming, and it is imperative to understand why this is the case if you want to learn C++. Hiding the internals of an object reduces complexity and increases robustness. I suggest you Google encapsulation and read up on it, here is the wikipedia page for starters.

Originally Posted by MutantJohn

Okay, I'm sorry for being grumpy. I guess it was uncalled for. But ooga didn't even mention a specific book or section of a book to look for. Telling me "read a book" is fine but it can't help but sound condescending without including, "Read a book to further understand what STL even stands for and what a 'smart pointer' is" amongst other things. There's a difference between a useless post like that from someone who clearly understands the material and posting something that will help me.

He may have no obligation to help me but he certainly has no obligation to be condescending either. He should've just said nothing.

If you go back and read his post you will find that there was actually nothing inherently condescending about that one sentence, maybe other than the fact that it was a one-sentence answer to some fairly long posts by you. I suppose it could be construed as slightly dismissive but it was sound advice nonetheless.

And yes, I really do miss my imperative language... Oh God, C, I'll never leave you again! But seriously, let's talk C++ and hopefully in a much more informed manner. Keep in mind, guys, my BS is in physics. Why is this going so badly? Because I'm used to my intuition guiding me. C is intuitive because it is imperative. Object orientation is just like, "Whoa, why would I even do this ever?" As an outsider, I wanna be included! And C++ feels like the language actual computer scientists nerd out over. I wanna be part of that club!

Funny, at my CS program everyone is obsessing over C, or as they like to call it, "the native language".

First of all, I really wanna talk about these lines of code here :
<snip>

Do not get hung up on the details of this particular code snippet, think of std::vector as a dynamic array that resizes when you need it to. std::unique_ptr is a smart pointer that frees whatever memory it points to when it goes out of scope, it also ensures (you can get around this by misusing it) that no other unique_ptr can gain ownership of the object it points to. std::unique_ptr can be cumbersome to use at first, especially if you're using it with you own classes.

Now, let's talk about this loop before I go off and read about what a virtual function is and why I should care. Also, I will work on my visibility. I will never ever call a 'class' a 'class'. It will always be a struct. Always. I will switch to cout though. I will also use "using namespace std;" so I don't have to type "std::" every line. I will also use the <memory> library and smart pointers.

That loop is a for-each loop, it loops through an entire container (or whatever other object that defines the appropriate operators, i forget which) and puts the elements in the variable to the left of the ':'. Think of it as a for-loop that avoids having to mess around with indices or iterators.

"using namespace std;" pulls the entire standard library into the global namespace, and this is not always a good thing. I suggest you just get used to typing std::, another option is to only "use" the classes you are actually using:

Code:

using std::string;
using std::cout;

...and so on.

phantom was right, C++ is more complex but it's kind of neat. Also, using references totally trolls and undermines what C++ is trying to do with its protection. We use a unique_ptr to prevent it being manipulated by different pointers but references are a complete workaround of that, it seems to me.

And my bad, I thought C++ was written in C.

Do not dismiss references so lightly, they are a very useful tool. They allow you to pass objects by reference without having to resort to old school pointers for example. I'm sure someone more intimate with C++ than me can give you a tonne of other good reasons why references are useful.

C++ has many complex features, but the point is to help the programmer avoid having to write complex code. Also keep in mind that you do not have to use every part of C++, you can get by just fine without ever learning about lambda functions and template specializations. Yes it is possible to work around std::unique_ptr, but that would defeat the purpose of using a std::unique_ptr in the first place. You can also work around access specifiers if you really want, but why?

If by "i thought C++ was written in C" you mean C++ compilers are written in C, then yes, some of them are. But really you could write a C++ compiler in any language if you wanted (this is no small task).

Att least one C++ compiler I know is written in... *drum roll* C++! *Gasp* Yes, you heard that right.

Originally Posted by MutantJohn

Oh, I see now. Then was the original C++ compiler written in C? I could totally see writing a C++ compiler in C being a do-able process. But it's soooo meta.

Then is g++ written in C?

Hehe, actually the first C++ compiler was written with C++:

Originally Posted by Bjarne Stroustrup

The first C++ compiler (Cfront) was written in C++. To build that, I first used C to write a "C with Classes"-to-C preprocessor. "C with Classes" was a C dialect that became the immediate ancestor to C++. That preprocessor translated "C with Classes" constructs (such as classes and constructors) into C. It was a traditional preprocessor that didn't understand all of the language, left most of the type checking for the C compiler to do, and translated individual constructs without complete knowledge. I then wrote the first version of Cfront in "C with Classes".

..okay maybe not quite.

GCC was originally written in C, but they changed to C++ in august 2012, so if you want to build GCC you need a C++ compiler. I wouldn't call writing a C++ compiler a do-able task, it is a gargantuan undertaking, and certainly not one you could complete on your own. Heck, it took Microsoft the best part of a decade to get templates right.

And I'll try to adapt to encapsulation. The proper definition of robustness makes sense because even when I was writing C code, I was like, man, this is totally fragile and changing one thing wrongly would break the whole thing!

Generally, C can be very fragile. That is what happens when you have to do pointer arithmetics and memory management by hand. Using the STL will make your code far less bug prone.