Finally getting into GUI, have questions

This is a discussion on Finally getting into GUI, have questions within the C++ Programming forums, part of the General Programming Boards category; So I've been taking programming classes at school for a while now (towards a programming AA), and I'm finally far ...

  1. #1
    Registered User
    Join Date
    Nov 2008
    Location
    Bay Area, CA
    Posts
    53

    Finally getting into GUI, have questions

    So I've been taking programming classes at school for a while now (towards a programming AA), and I'm finally far enough along in the class sequence that we've just started getting into GUI programming. Sort of - each lab assignment is a personal choice of either console, FLTK, or Windows Forms.

    We're 4 out of 5 assignments in now, and I finally choose FLTK (didn't want to be tied down, I can learn platform specific stuff later) instead of a console. I learned how to use it as I went, finished the assignment, it works beautifully, but now that I'm done, I have some general GUI programming questions.

    1. Does FLTK really need pointers, specifically, to it widgets throughout the program? Since this is C++, I'd prefer to go with references and avoid pointers and dereferencing and explicit "new"s and so forth. Not that I'm scared of the C style or anything, I got very comfortable with it in all my C courses. I haven't actually tried yet, so I guess this is more of a lazy thing to ask, but, maybe there's further insight to be gained by asking than just simply trying on its own.
    2. I had found the tutorial at Beginner FLTK Tutorial (among other sites), and it suggested using a class to contain all the widgets you're going to use, and I found that works great. But are there any insights any of you have on this? It seems to work great and be the most sensible way of doing it, but I want to be sure.
    3. To go along with point 2, is it really best for all of the widgets to be public, rather than private? Typically in our programs, data members have been private and most functions have been public, but this seems to suggest doing it the other way around?
    4. I wrote the assignment as a console first, then went and adapted it to the GUI. In doing so, I found that I had to remove the stdin and stdout method of interfacing with the user, and go with passing the buttons/boxes/etc around as needed (I tried passing the whole class [by pointer], but got some funky errors that I can't remember right now). So functions that previously had no arguments since they worked directly with stdin and stdout, now have arguments of the widgets they need for input/output. Is lacing pointers/references (please keep question 1 in mind regarding pointers vs references) throughout the standard code the best way of doing it? Or should I have done composition instead (putting all of my classes as data members inside the GUI's master widget class), or some other method?
    5. I found it harder to track memory leaks than consoles. Between VS2010's built-in memory leak checking, and a memory tracking library some instructors and their non-school colleagues developed, tracking memory leaks in console apps was trivial and took seconds to fix. But I'm finding it a little more difficult in my GUI program. I put everything in main inside a set of braces, and that helped with the thousands of leaks VS claimed the regex library was making, but I still have a few weird ones where the VS2010 debugger leak checker shows the data values in the leaked memory as being "C:\Users" and "arch c" and two or three other weird things that I'm pretty sure I never touched or involved in my program.
    6. Does Fl::run() really need to be in the return statement of main? Or is it just a style/convenience thing? I tried putting it before the return in main and it seems to work just fine, but I want to be sure before getting attached to any specific convention.


    I think that's all I can think of for now. I'd really appreciate some seasoned insight from you guys regarding these thoughts. Thanks.

  2. #2
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    The problem using references is that most of the objects in GUI programs are dynamically allocated with new. To use references, you'd end up with tons of code like this:

    Code:
    Widget &widg = *(new Widget(...));
    ...
    delete &widg;
    You can certainly use references when you pass things around between your own functions and methods, but so much toolkit code is designed around pointers that you'll be going against quite a strong current and things will continually feel awkward.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  3. #3
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,556
    About pointers:
    It seems that the biggest reason they use it here is to defer construction of an object to a later time. If you were to create a window instance otherwise that contains buttons and stuff, you need to initialize them in the initializer list. I don't know how feasible it is since I am not familiar with FTK. But if you do that, you avoid pointers and new altogether. That's nice stuff.
    Otherwise, you should learn smart pointers. Essentially they clean up pointers automatically so you don't have to, and thus avoid memory leaks.
    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.

  4. #4
    Registered User
    Join Date
    Nov 2008
    Location
    Bay Area, CA
    Posts
    53
    Quote Originally Posted by brewbuck View Post
    The problem using references is that most of the objects in GUI programs are dynamically allocated with new.

    ...

    but so much toolkit code is designed around pointers that you'll be going against quite a strong current and things will continually feel awkward.
    Quote Originally Posted by Elysia View Post
    About pointers:
    It seems that the biggest reason they use it here is to defer construction of an object to a later time. If you were to create a window instance otherwise that contains buttons and stuff, you need to initialize them in the initializer list. I don't know how feasible it is since I am not familiar with FTK. But if you do that, you avoid pointers and new altogether. That's nice stuff.
    Otherwise, you should learn smart pointers. Essentially they clean up pointers automatically so you don't have to, and thus avoid memory leaks.
    Thanks for the responses guys. In reply to both of you, do other GUI toolkits work this way too? Qt, WIN32, etc?



    I've found FLTK to be a nice easy step from console programming to gui programming, as the class interfaces are very simple and very easy to use, almost like they were school projects (platform specific underpinnings aside...). Things are named reasonably well, the functions are easy to use, etc. It was a small and helpful learning curve.

    It's really great that FLTK looks the same across all platforms that it's kit is available for, but as FLTK was an option for a class assignment (that or Windows Forms), I'm looking for something more powerful, fully featured, and will do native look and feel for any platform that it is available for. To that end, I was thinking of starting to learn how to use Qt for my personal stuff (and as another tool in the toolbox, which I also want to add WIN32 to). It looks like I'm going to have to pick up the whole signal/slot system though. Any thoughts of Qt? I've looked around online regarding the various gui frameworks, but I value the insight here.

    Also, does anyone else have any thoughts on points 2 to 5 above? Are these questions too specific to FLTK? I was hoping they were general enough to apply to GUI programming as a whole, but maybe they're incompatible with other frameworks.

  5. #5
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    Quote Originally Posted by Sorin View Post
    Qt
    2. Yes, you generally initialize them inside the constructor.
    3. No, why would you expose the widgets in public? What if you ..for example decide to use QTextEdit instead of QLineEdit after writing the code ?(if private, you have to change noting as the interface remains more or less same)
    4. Depends on the toolkit. (signals and slots for Qt, emitting signals when required .)
    ( If you want your console code to remain intact, have all I/O done on a string or stringstream .. and return it, making it the responsibility of the class to display it .)
    5. Read the doc of the library to see if you've to manually delete anything.
    6. Similar in Qt. You return app.exec(); (app is a QApplication object, btw). If you store its return value and return it, it remains the same thing.
    Last edited by manasij7479; 03-20-2012 at 02:02 AM.
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  6. #6
    Registered User
    Join Date
    Nov 2008
    Location
    Bay Area, CA
    Posts
    53
    Quote Originally Posted by manasij7479 View Post
    2. Yes, you generally initialize them inside the constructor.

    3. No, why would you expose the widgets in public? What if you ..for example decide to use QTextEdit instead of QLineEdit after writing the code ?(if private, you have to change noting as the interface remains more or less same)
    2. That's what I did. It seemed the most sensible way, but at the same time it seemed kind of unwieldy. Although maybe that's just because up to this point in my schooling, all the classes we've made have been so small and simple that the constructors were never more than a few lines.

    3. Personally, I wouldn't. It goes against everything I've learned thus far. It was really confusing that the tutorial would do that, so I wanted to ask just to make sure.

    6. So it does specifically have to be in the return statement itself? I'm assuming, then, it's to let the OS know that the program ran normally.

  7. #7
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    Quote Originally Posted by Sorin View Post
    6. So it does specifically have to be in the return statement itself? I'm assuming, then, it's to let the OS know that the program ran normally.
    You can get the value in another variable and then return it, but as in gui programs, you don't usually do anything after the window is closed, it is better left in the return statement itself.
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  8. #8
    Registered User
    Join Date
    Nov 2008
    Location
    Bay Area, CA
    Posts
    53
    Quote Originally Posted by manasij7479 View Post
    You can get the value in another variable and then return it, but as in gui programs, you don't usually do anything after the window is closed, it is better left in the return statement itself.
    Got it. Thanks for the feedback.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Finally, i did it!!!
    By RoD in forum A Brief History of Cprogramming.com
    Replies: 5
    Last Post: 03-21-2004, 06:22 PM
  2. I Think I Finally Get It!
    By LordVirusXXP in forum C++ Programming
    Replies: 2
    Last Post: 12-18-2002, 01:43 PM
  3. I finally got...
    By SyntaxBubble in forum Windows Programming
    Replies: 1
    Last Post: 11-18-2001, 06:38 PM

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