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.
- 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.
- 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.
- 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?
- 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?
- 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.
- 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.