Drawing Tool Software Data Structure Questions!

This is a discussion on Drawing Tool Software Data Structure Questions! within the C++ Programming forums, part of the General Programming Boards category; Let's say I want to create a software that will draw various 2D shapes to the screen and allow the ...

  1. #1
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    1,045

    Drawing Tool Software Data Structure Questions!

    Let's say I want to create a software that will draw various 2D shapes to the screen and allow the user to manipulate them in real-time. So they could choose a tool (a button on a GUI or something), and drag-and-draw a rectangle. Or a triangle.

    I can't help but feel like an OO approach would be the ticket here but I'm not sure how I'd implement that.

    Would I have something this pseudocode?
    Code:
    class drawShapes {
    
       public :
          /* Here I need to be able to allow the user to draw
          and manipulate multiple shapes so I figure I need to
          define all the shapes. Do I use something like this? */
    
          struct square *obj1;
          struct triangle *obj2;
          struct circle *obj3;
    
          /* Would I then put all my functions here? */
    };
    So basically, I have no idea what I'm doing but I'm confident I can handle this abstraction with a little help.

    The basic idea of the software would, create a shape and then allow the user to manipulate it with multiple tools.

    In pure C, what I would do is, define a button struct with a function pointer. So there'd be a "create square" button. I guess that's the same as a class in C++.

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

  2. #2
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    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.
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  3. #3
    - - - - - - - - oogabooga's Avatar
    Join Date
    Jan 2008
    Posts
    2,808
    Quote Originally Posted by MutantJohn View Post
    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.
    Last edited by oogabooga; 08-13-2013 at 06:18 PM. Reason: added draw() to derived objects; added Triangle
    The cost of software maintenance increases with the square of the programmer's creativity. - Robert D. Bliss

  4. #4
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    1,045
    I have some questions.

    The parent class stores the position of the cursor, right? Then the rest is simply color data?

    So, calling the other classes calls the parent class and constructs both of them.

    But then how does a vector of type Shape pointer point to various structs? Is it just because they have the same inheritance? Because a square struct is not a circle struct unless we cast them as the same type of typecast and I guess I just answered my own question because they can all draw() and that would be all we can salvage from the typecast as that is the only common member.

  5. #5
    - - - - - - - - oogabooga's Avatar
    Join Date
    Jan 2008
    Posts
    2,808
    I suggest you read a book on C++.
    The cost of software maintenance increases with the square of the programmer's creativity. - Robert D. Bliss

  6. #6
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    1,045
    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.
    Last edited by MutantJohn; 08-14-2013 at 03:31 AM.

  7. #7
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,299
    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.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  8. #8
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,299
    Quote Originally Posted by MutantJohn View Post
    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.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  9. #9
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    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.
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  10. #10
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,538
    [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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  11. #11
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    1,045
    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.

    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!

    First of all, I really wanna talk about these lines of code here :
    Code:
        std::vector<std::unique_ptr<Shape>> Shapes;
        Shapes.push_back(std::unique_ptr<Shape>( new Circle() ));
    Alright, I'ma try to dissect this just so I know what's going on. We're declaring a 'vector' data structure whose type is a flavor of pointer to a class denoted as 'Shape'. I'm reading now what a vector is in C++ and it seems pretty cool. I like it. Plus, the indexing of it is incredibly easy because it's an array.

    So the next line uses that vector and we're pushing an element to the back which would be element 0, right? But what are we pushing onto it? The same flavor of pointer but I think I get it now. Because a unique_ptr can have only one owner, what you're doing with your vector.push() is passing ownership to the element of vector. As in, element 0 would technically own the pointer to the Circle class we declared.

    Because each element of your vector declaration is a unique pointer type, it's readily able to serve as the sole owner of whatever is pushed onto it. I think that's right and it actually makes a lot of sense, considering other things I've tried playing around with. For example, I think this explains why
    Code:
        std::unique_ptr<Shape> ptr1(new Circle() );
        Shapes.push_back(ptr1);
    just simply doesn't even compile. The first line declares ptr1 to a Circle structure but only ptr1 can own this so when I try to push it onto the stack, I'm trying to give that structure multiple, do they call it mutators? Basically, it's something that has access to that particular structure. Because Shapes[i] would try to be the new pointer to the same structure and C++ is all like, no!

    However, this works :
    Code:
        std::unique_ptr<Shape> ptr1(new Circle() );
        ptr1->draw();

    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.

    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.

    Code:
        for (const auto & Shape : Shapes)
            Shape->draw();
    First thing's first, I recognize a for-loop. With you so far. But what on God's green Earth is in the middle of that? Back in my day, we had an initializer, a breaking condition and an updater, i.e.
    Code:
     for (int i=0; i<10; i++) {}
    .

    But what this looks like is, you're declaring a constant variable whose type is deduced from an initialization expression, in our case & Shape??? I though & was the logical and operator so you'd be comparing bits. Lol my bad, & Shape is actually a reference so Shape is exactly what it inherits from the Shapes vector, right? But it can't inherit all of Shapes at once, right? So it inherits one element at a time? And that's why we can call Shape->draw because Shape is now literally Shapes[0] and that's why it still works with a unique_ptr type. Then it becomes Shapes[1] and then Shapes[2].

    So Shape is declared as a reference to what it inherits from the Shapes structure. By default, it inherits the first pointer of the structure or it starts at the bottom of it.

    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.

  12. #12
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    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.

    Quote Originally Posted by MutantJohn View Post
    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).
    Last edited by Neo1; 08-14-2013 at 03:51 PM.
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  13. #13
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    1,045
    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?

    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!

  14. #14
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,538
    Att least one C++ compiler I know is written in... *drum roll* C++! *Gasp* Yes, you heard that right.
    Last edited by Elysia; 08-14-2013 at 03:52 PM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  15. #15
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Quote Originally Posted by MutantJohn View Post
    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++:

    Quote 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.
    Last edited by Neo1; 08-14-2013 at 03:50 PM.
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 8
    Last Post: 12-01-2011, 06:31 PM
  2. Replies: 1
    Last Post: 11-15-2011, 10:41 PM
  3. Data structure for storing serial port data in firmware
    By james457 in forum C Programming
    Replies: 4
    Last Post: 06-15-2009, 09:28 AM
  4. system software....many questions
    By planet_abhi in forum Tech Board
    Replies: 4
    Last Post: 04-26-2003, 03:52 AM
  5. couple of questions on drawing text and buttons
    By Leeman_s in forum Windows Programming
    Replies: 3
    Last Post: 12-28-2002, 10:45 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21