Actual real FLTK problem now.
After my recent exploits... with getting FLTK (v 1.1.10) installed successfully... I think I've actually run into a real problem now.
The book instructs us to include the following headers:
"Simple_window.h" AND "Graph.h"
The FULL code is below and I get a single error: "Can NOT include file: Simple_window.h: No such file or directory" This is ALSO the case with "Graph.h" when I comment out Simple_window.h
I am brand new to GUI programming so I have no idea where these might be found since all the other library files for the project are included and are located
Suggestions from anyone who has done this before?
Not sure how to proceed at this point.
Xanadu
The book instructs us to include the following headers:
"Simple_window.h" AND "Graph.h"
The FULL code is below and I get a single error: "Can NOT include file: Simple_window.h: No such file or directory" This is ALSO the case with "Graph.h" when I comment out Simple_window.h
I am brand new to GUI programming so I have no idea where these might be found since all the other library files for the project are included and are located
Suggestions from anyone who has done this before?
|
|
Not sure how to proceed at this point.
Xanadu
Thanks Dutch,
I figured someone would have a bead on this stuff. Now, when I have these files, where would I put them? In the INCLUDE directory for VS like the others??
Xanadu
I figured someone would have a bead on this stuff. Now, when I have these files, where would I put them? In the INCLUDE directory for VS like the others??
Xanadu
I'm not sure where to put them. I don't use Windows or VS.
Maybe experiment a little. :-)
If all else fails, putting the required ones in the directory with the source code should work.
Maybe experiment a little. :-)
If all else fails, putting the required ones in the directory with the source code should work.
Gotcha Dutch,
I'll put it into a directory where all the projects can see it and try that.
Much obliged Dutch
Xanadu
I'll put it into a directory where all the projects can see it and try that.
Much obliged Dutch
Xanadu
OK Dutch,
Placed those headers in a location in the "include" directory and they are being located and seen.... so I think we're almost there. Just down to 2 anomalies and I think I'll be ok.....
Here's the code verbatim from the book and using the headers you found (but NOT using the .cpp files that were in that location! use those as well???)
I compile the code and I get the following 2 errors:
Severity Code Description Project File Line
Error C2440 '<function-style-cast>': cannot convert from 'initializer list' to 'Graph_lib::Point' Chapter12_GUI_test c:\program files (x86)\microsoft visual studio 14.0\vc\include\extra\simple_window.h 13
Error C2661 'Graph_lib::Button::Button': no overloaded function takes 4 arguments Chapter12_GUI_test c:\program files (x86)\microsoft visual studio 14.0\vc\include\extra\simple_window.h 13
BOTH of these errors point to one line in the supplied header from the files you found. The header is simple_window.h. Not sure what these errors are indicating except some sort of implicit type casting is attempting to take place... and evidently failing.
Ideas?
Xanadu
Placed those headers in a location in the "include" directory and they are being located and seen.... so I think we're almost there. Just down to 2 anomalies and I think I'll be ok.....
Here's the code verbatim from the book and using the headers you found (but NOT using the .cpp files that were in that location! use those as well???)
|
|
I compile the code and I get the following 2 errors:
Severity Code Description Project File Line
Error C2440 '<function-style-cast>': cannot convert from 'initializer list' to 'Graph_lib::Point' Chapter12_GUI_test c:\program files (x86)\microsoft visual studio 14.0\vc\include\extra\simple_window.h 13
Error C2661 'Graph_lib::Button::Button': no overloaded function takes 4 arguments Chapter12_GUI_test c:\program files (x86)\microsoft visual studio 14.0\vc\include\extra\simple_window.h 13
BOTH of these errors point to one line in the supplied header from the files you found. The header is simple_window.h. Not sure what these errors are indicating except some sort of implicit type casting is attempting to take place... and evidently failing.
Ideas?
Xanadu
Examine the source for Point.h.
In my copy it appears the constructor is commented out, meaning there's no constructor taking two parameters.
You may be required to "fix" that.
In my copy it appears the constructor is commented out, meaning there's no constructor taking two parameters.
You may be required to "fix" that.
Niccolo,
I saw that too...…. but there are two constructors...… one where the member functions are assigned values passed in as arguments and the other where both members are defaulted to "0" .
I uncommented both of those.
How about the operator definition/overload - leave that alone for now in your opinion or will that have a major impact on how things go??
OK, after uncommenting those two constructors in the "Point.h" file...… now I am getting a whole slew of Linker errors. We're making progress...…. I think??
This attempt at using FLTK is definitely proving to be a real "challenge" as far as getting things ready to simply learn how to program GUI concepts. LOL
Xanadu
I saw that too...…. but there are two constructors...… one where the member functions are assigned values passed in as arguments and the other where both members are defaulted to "0" .
I uncommented both of those.
How about the operator definition/overload - leave that alone for now in your opinion or will that have a major impact on how things go??
OK, after uncommenting those two constructors in the "Point.h" file...… now I am getting a whole slew of Linker errors. We're making progress...…. I think??
This attempt at using FLTK is definitely proving to be a real "challenge" as far as getting things ready to simply learn how to program GUI concepts. LOL
Xanadu
Last edited on
To fix the linker errors you might try including one or more of those cpp files from that link above. Those should have the missing code that the linker is pining for.
I can definitely do that....
Do you have any idea where those might go? I put the headers in the include folder perhaps there is one for additional source code? I know you're a Unix guy but I figured I'd ask anyhow.
I definitely will "splice" them into the code however. Thanks for the heads up. Maybe that is why they put all that code together? (LOL!)
Thanks again Dutch. Hopefully that will solve all the issues.
Xanadu
Do you have any idea where those might go? I put the headers in the include folder perhaps there is one for additional source code? I know you're a Unix guy but I figured I'd ask anyhow.
I definitely will "splice" them into the code however. Thanks for the heads up. Maybe that is why they put all that code together? (LOL!)
Thanks again Dutch. Hopefully that will solve all the issues.
Xanadu
I don't know guys...….
I've incorporated everything that Stroustrup provided in the link that Dutch provided earlier and it feels like I'm the kid on the outside of the dike...… as soon as I plug one hole...…. 120 spring up in its place. That's no exaggeration either. I was down to two errors and I incorporated those .cpp files the good Doctor provided..... and everything has just gone straight to &^$%*@#.
There are so many errors now...… I don't believe it would fit in a post to show you all! LOL! Things are definitely looking up!
So, in my opinion..... it really is just his (Strousstrup's) code that is crapping out. It appears from the test that I ran that FLTK has installed correctly and it is all there! As Niccolo will attest...… for some reason some of Stroustrup's header files and I assume the .cpp files have some errors that need repaired. Perhaps I am fighting a C++14/17 or whatever thing at the moment?? Not really sure due to my ignorance of GUI programming in general.
Should I abandon FLTK or just try to learn it and then try to write my code while following along with the book??
Do you guys think that I would still be able to follow along with the book's lesson even though I don't go with FLTK and try QT or wxwidgets or what have you?
I also have to confess one thing..... the header that Stroustrup provided for the earlier chapters (std_lib_facilities.h) - I never used it once in the earlier chapters! I literally just looked up other included facilities found on Cplusplus.com and powered through.
IF I knew enough to avoid his code for the GUI sections of the book..... I would do the identical things for these chapters as well and just include the facilities in FLTK that make writing the code he shows possible.
Problem is, I don't know enough about GUI programming or FLTK to just use the library includes and not worry about his code (since his code seems to be the major problem at this point)
So I have a dilemma..... the FLTK DID install correctly and the full library is there and the check out worked...… I just can't use any of Stroustrup's recommended provided files to do a "literal" walk through of the lessons.
So, should I just try to learn as much as possible about FLTK real quick and just muddle through and try to follow along OR just abandon FLTK and get QT and work with that instead?
Also, do you think I would be able to "follow along" easily enough using the QT GUI library since it might be "easier" (not sure how much??) to use?
What say all of you?
Xanadu
I've incorporated everything that Stroustrup provided in the link that Dutch provided earlier and it feels like I'm the kid on the outside of the dike...… as soon as I plug one hole...…. 120 spring up in its place. That's no exaggeration either. I was down to two errors and I incorporated those .cpp files the good Doctor provided..... and everything has just gone straight to &^$%*@#.
There are so many errors now...… I don't believe it would fit in a post to show you all! LOL! Things are definitely looking up!
So, in my opinion..... it really is just his (Strousstrup's) code that is crapping out. It appears from the test that I ran that FLTK has installed correctly and it is all there! As Niccolo will attest...… for some reason some of Stroustrup's header files and I assume the .cpp files have some errors that need repaired. Perhaps I am fighting a C++14/17 or whatever thing at the moment?? Not really sure due to my ignorance of GUI programming in general.
Should I abandon FLTK or just try to learn it and then try to write my code while following along with the book??
Do you guys think that I would still be able to follow along with the book's lesson even though I don't go with FLTK and try QT or wxwidgets or what have you?
I also have to confess one thing..... the header that Stroustrup provided for the earlier chapters (std_lib_facilities.h) - I never used it once in the earlier chapters! I literally just looked up other included facilities found on Cplusplus.com and powered through.
IF I knew enough to avoid his code for the GUI sections of the book..... I would do the identical things for these chapters as well and just include the facilities in FLTK that make writing the code he shows possible.
Problem is, I don't know enough about GUI programming or FLTK to just use the library includes and not worry about his code (since his code seems to be the major problem at this point)
So I have a dilemma..... the FLTK DID install correctly and the full library is there and the check out worked...… I just can't use any of Stroustrup's recommended provided files to do a "literal" walk through of the lessons.
So, should I just try to learn as much as possible about FLTK real quick and just muddle through and try to follow along OR just abandon FLTK and get QT and work with that instead?
Also, do you think I would be able to "follow along" easily enough using the QT GUI library since it might be "easier" (not sure how much??) to use?
What say all of you?
Xanadu
Taking a peek at that book I see that there are previous chapters that use fltk. Were you able to get those working? Or did you skip those chapters?
I think you need to work through the book in order since the code on that webpage I linked above is kind of strange. It has various parts commented out, like you are supposed to maybe have written them yourself. It also has code repeated in both the headers and cpp files in some instances. I have no idea what you are supposed to do with that.
If the book doesn't explain things properly then it's Stroustrup's fault. It has nothing to do with fltk, so switching to Qt is not going to fix anything.
I think you need to work through the book in order since the code on that webpage I linked above is kind of strange. It has various parts commented out, like you are supposed to maybe have written them yourself. It also has code repeated in both the headers and cpp files in some instances. I have no idea what you are supposed to do with that.
If the book doesn't explain things properly then it's Stroustrup's fault. It has nothing to do with fltk, so switching to Qt is not going to fix anything.
Dutch,
You bring up great points. Unless I missed something, up to chapter 12 we never had to do anything with FLTK. We did have that other header file (the std_lib_facilities.h) like I mentioned above but that didn't seem to contain anything with FLTK and it only has standard includes for the most part (I think)
You are absolutely right about the code being very odd and having tons of bugs. He sometimes does that to prove a point of what NOT to do and so he makes it overly difficult BUT since he is newly introducing this topic (in chapter 12) he hasn't said anything about throwing any curve balls for us to figure out.
I didn't use his other header and like I said, IF QT is a bit more straight forward and simpler than FLTK I'm willing to give it a try. Just not sure if I'd be trading one set of problems for another.
The book definitely doesn't explain things properly and that is why you guys are awesome...… especially on stuff like this. In the appendix he pretty much says: "If you're having problems installing and working with this stuff.... talk to a friend!"
So I think he definitely believes difficulty is the best teacher and I agree.... but there are limits to that when you are first learning something entirely.
Xanadu
You bring up great points. Unless I missed something, up to chapter 12 we never had to do anything with FLTK. We did have that other header file (the std_lib_facilities.h) like I mentioned above but that didn't seem to contain anything with FLTK and it only has standard includes for the most part (I think)
You are absolutely right about the code being very odd and having tons of bugs. He sometimes does that to prove a point of what NOT to do and so he makes it overly difficult BUT since he is newly introducing this topic (in chapter 12) he hasn't said anything about throwing any curve balls for us to figure out.
I didn't use his other header and like I said, IF QT is a bit more straight forward and simpler than FLTK I'm willing to give it a try. Just not sure if I'd be trading one set of problems for another.
The book definitely doesn't explain things properly and that is why you guys are awesome...… especially on stuff like this. In the appendix he pretty much says: "If you're having problems installing and working with this stuff.... talk to a friend!"
So I think he definitely believes difficulty is the best teacher and I agree.... but there are limits to that when you are first learning something entirely.
Xanadu
FLTK v1.1.1.0 is almost 10 years old. The latest stable version is v.1.3.5, released in March of 2019.
Stroustrup's PPPC++ code doesn't use the latest and greatest C++ language version(s), modern compilers could have problems the older FLTK library code.
I know older Win32 API code can make Visual Studio 2017 and 2019 go loopy if it isn't updated.
https://www.fltk.org/articles.php?L825
Stroustrup's book is derived from classroom lectures, not reading from start to finish is going to introduce easily prevented errors. His "std_lib_facilities.h" header file is almost a requirement the way his book is structured.
Stroustrup's PPPC++ code doesn't use the latest and greatest C++ language version(s), modern compilers could have problems the older FLTK library code.
I know older Win32 API code can make Visual Studio 2017 and 2019 go loopy if it isn't updated.
| FLTK-1.3.5 is basically FLTK-1.1.10's API with extra features |
https://www.fltk.org/articles.php?L825
Stroustrup's book is derived from classroom lectures, not reading from start to finish is going to introduce easily prevented errors. His "std_lib_facilities.h" header file is almost a requirement the way his book is structured.
Did you go through Appendix D? Can you run the example program there? It doesn't use any of the Stroustrup stuff.
If you are having this kind of trouble with it then there must be others in the same boat. Check around.
And I'm pretty sure FLTK is easier than Qt. It's just the Stroustrup stuff that's making it weird.
Maybe try an FLTK tutorial. https://www.fltk.org/doc-1.3/basics.html
If you are having this kind of trouble with it then there must be others in the same boat. Check around.
And I'm pretty sure FLTK is easier than Qt. It's just the Stroustrup stuff that's making it weird.
Maybe try an FLTK tutorial. https://www.fltk.org/doc-1.3/basics.html
@Xanadu4ever,
I got this compiled on VS2019 and the example code from OP ran.
First, make sure you did follow a few instruction in the appendix, like ignore libcd.lib in the linker.
Next, in the source from the web there are two "gui.h" files - one is apparently outdated. On of them defines a constructor which is also defined in gui.cpp - so use the "gui.h" spelled "Gui.h", not "GUI.h" from the site linked above for the book's source.
Next, there are a couple of functions in std_lib_facilities.h which are not declared inline, but must be when that file is included in multiple translation units. Declare inline "default_random_engine" and "seed_randint"...
Next, there's a rather odd behavior in the graph.cpp translation unit. If you get to the point I did, files like "main.cpp" compile ok (a few signed/unsigned warnings)...but graph.cpp would not compile (lots of strange errors).
The matter there is simple. For graph.cpp to compile, these includes must appear before including graph.h:
The header structure is a bit brittle.
Anyway, I got the application built and it ran, drawing a triangle as expected.
Sometimes I just "do things" - after 40+ years, you develop reflex reactions to problems and I can't say I have detailed all that I did to get this working because I may have fixed something without thinking about it.
I got this compiled on VS2019 and the example code from OP ran.
First, make sure you did follow a few instruction in the appendix, like ignore libcd.lib in the linker.
Next, in the source from the web there are two "gui.h" files - one is apparently outdated. On of them defines a constructor which is also defined in gui.cpp - so use the "gui.h" spelled "Gui.h", not "GUI.h" from the site linked above for the book's source.
Next, there are a couple of functions in std_lib_facilities.h which are not declared inline, but must be when that file is included in multiple translation units. Declare inline "default_random_engine" and "seed_randint"...
Next, there's a rather odd behavior in the graph.cpp translation unit. If you get to the point I did, files like "main.cpp" compile ok (a few signed/unsigned warnings)...but graph.cpp would not compile (lots of strange errors).
The matter there is simple. For graph.cpp to compile, these includes must appear before including graph.h:
|
|
The header structure is a bit brittle.
Anyway, I got the application built and it ran, drawing a triangle as expected.
Sometimes I just "do things" - after 40+ years, you develop reflex reactions to problems and I can't say I have detailed all that I did to get this working because I may have fixed something without thinking about it.
Dutch and Niccolo,
My answers to your inquiries==>
1.) Dutch, YES I did do the Appendix D test and it DID work completely! You are correct - it doesn't use Stroustrup code and it worked great! I'm just stupid when it comes to FLTK! Thank you for identifying the tutorial (I started reading it after I downloaded it to see what I need to do to be able to by-pass Strousstrup's code and still follow along in the book.) That is one option and I'm pursuing it currently - I'm still a moron though! LOL
If this ends up being a total Charles Foxtrot - I even thought of just "reading" through the chapters and learning the main points and then get back to the coding in Chapter 17 or so in Part 3 of the book. Not sure if I would be cheating my learning (by skipping the GUI parts) or just leave it until I finished the rest of the book and then swing back around and take another swing at it after I had more education in the other parts of C++ like templates, LHV and RHV's, auto pointers, etc???
2.) Niccolo, As you can see from point #1 above - Appendix D was a success! Yes, 2 GUI files and I RENAMED one GUI2.h (from GUI.h since windows was telling me it already existed as gui.h and did I want to replace it?) I didn't know any better so I kept them both and renamed the one thinking that might work! Maybe this little hack on my part is causing my BIG problems?? Anyhow, any other file that referred to that header I changed to my new name! An attempted work around that may have caused the snow ball to keep getting larger!
I don't doubt that you fixed a couple of things with your vast knowledge..... I can TRY to eliminate the GUI.h (renamed by ME to GUI2.h) and try to redirect all the other files that use it to the Gui.h one - hopefully that will be able to resurrect my attempt??
The in-line functions that you pointed out.... I will take a look at them and will I have to explicitly call them "inline" in front of the declarations and definitions??
Dumb question but I'm still a noob so that is why this sounds dumb! (Do you recommend skipping to OTHER sections of the book and coming back??)
Yes, calling this stuff "brittle" seems to be a massive understatement from a beginner's point of view. I hope I haven't screwed this crap up too much. As you MAY or MAY NOT know..... I'm using VS2015 - not sure if it is going to go nuts in a different way than your 2019?? It's anyone's guess at this point! Man I wish I was a Unix guy!
Anyways, I will attempt to repair the damage based on what you guys said and I'll get back to you regardless of outcome!
Thank you guys again for all your help and guidance. It's good to know I'm only a partial idiot when it comes to this stuff.
Xanadu
My answers to your inquiries==>
1.) Dutch, YES I did do the Appendix D test and it DID work completely! You are correct - it doesn't use Stroustrup code and it worked great! I'm just stupid when it comes to FLTK! Thank you for identifying the tutorial (I started reading it after I downloaded it to see what I need to do to be able to by-pass Strousstrup's code and still follow along in the book.) That is one option and I'm pursuing it currently - I'm still a moron though! LOL
If this ends up being a total Charles Foxtrot - I even thought of just "reading" through the chapters and learning the main points and then get back to the coding in Chapter 17 or so in Part 3 of the book. Not sure if I would be cheating my learning (by skipping the GUI parts) or just leave it until I finished the rest of the book and then swing back around and take another swing at it after I had more education in the other parts of C++ like templates, LHV and RHV's, auto pointers, etc???
2.) Niccolo, As you can see from point #1 above - Appendix D was a success! Yes, 2 GUI files and I RENAMED one GUI2.h (from GUI.h since windows was telling me it already existed as gui.h and did I want to replace it?) I didn't know any better so I kept them both and renamed the one thinking that might work! Maybe this little hack on my part is causing my BIG problems?? Anyhow, any other file that referred to that header I changed to my new name! An attempted work around that may have caused the snow ball to keep getting larger!
I don't doubt that you fixed a couple of things with your vast knowledge..... I can TRY to eliminate the GUI.h (renamed by ME to GUI2.h) and try to redirect all the other files that use it to the Gui.h one - hopefully that will be able to resurrect my attempt??
The in-line functions that you pointed out.... I will take a look at them and will I have to explicitly call them "inline" in front of the declarations and definitions??
Dumb question but I'm still a noob so that is why this sounds dumb! (Do you recommend skipping to OTHER sections of the book and coming back??)
Yes, calling this stuff "brittle" seems to be a massive understatement from a beginner's point of view. I hope I haven't screwed this crap up too much. As you MAY or MAY NOT know..... I'm using VS2015 - not sure if it is going to go nuts in a different way than your 2019?? It's anyone's guess at this point! Man I wish I was a Unix guy!
Anyways, I will attempt to repair the damage based on what you guys said and I'll get back to you regardless of outcome!
Thank you guys again for all your help and guidance. It's good to know I'm only a partial idiot when it comes to this stuff.
Xanadu
@Xanadu4ever,
Yes, just put the keyword "inline" in front of the two functions I mentioned - it takes care of some linker errors referencing mersenne twister as already defined (it's a related notion to random values those functions use).
Don't forget about graph.cpp. The files I show to add to the include section reduce hundreds, possibly thousands of very strange errors (it would make you think std::vector is no longer valid code).
Why...I didn't research. I just noticed a depenency on other translation units. I compiled them one at a time, where main, window and gui all compiled with minor warnings, but graph blew up.
Also, I added the appropriate dependencies from the build of FLTK, and set input directories for the linker, and include directories for the compiler which aid in directory structure (which is what Stroustrup references with the "call a friend" suggestion).
Not much else was required as I recall.
I set the compiler for VC++14 compliance, so I expect VS2015 would be fine if it has been updated.
As to skipping to other sections....well, the work is from elementary to upper intermediate C++11/14, so to me it seems reasonable to skip what you already know. That said, if what you know is C++03, then reviewing what is new about C++11/14 would suggest not to skip. Even with decades behind me, I found skimming through informative as to Stroustrup's points, though I didn't need to do more than skim - that's just because of the decades behind me.
Well...there's two points on that. First, I was and am a "*Nix" guy, though I value Linux over UNIX in the present tense (they are identical designs, but Linux is what UNIX was supposed to be).
Still, acknowledging that there is no operating system on the planet as reliable, or efficient, as *Nix, it does deserve the reputation for being complicated. Having said that, so is Windows. At the same time, much of what users find "nice" about Windows configuration/updating is the same basic thing on many Linux distributions.
However, there is one thing that keeps me in Windows more than all else. I do require some applications for which there are either only Windows versions, or there are MAC versions "too". One of those is Visual Studio. Frankly, if you have ever tried to get a Linux workstation configured for development in C++, and compared that to the experience of getting Visual Studio installed and ready on Windows - there is no comparison. Nothing goes from zero to ready as easily or quickly as Visual Studio. QtCreator does offer a close comparison, but it really is not quite the same in operation.
You are actually well served in Windows under Visual Studio, with one caveat. The Microsoft compiler is not going to be among the more current with C++ standards. Some regard it is poor, though it is fairly good through C++14 in VS 2019, and does support much of C++17. On the other hand, configuring and using CLang in Visual Studio 2019 is nearly trivial, which is much better C++ conformance. GCC I've never figured out for Visual Studio, though I know it's possible.
Key to VS productivity is the project configuration. For anything short of a massively complex project, the ability to configure a project in VS is extremely simple. Compared to, say, Eclipse, it's effortless. Most other IDE's very quickly become little more than a front end to CMake, Make or other command line build tools.
Eventually we all should learn to use those command line build tools, but for the early years, and for quick "start to working" - nothing beats VS for quickly making a project grow fast.
The other is the debugger. It's fast, reliable (surprisingly robust), and full featured. Comparing other debuggers is just no fun. KDevelop is fair, so was Eclipse (lately I can't get a Linux Eclipse installation to stay configured and working). QtDevelop is like KDevelop in the way the debugger works, which is ok, but not nearly as full featured as VS Studio in Windows.
I'm not trying to sell you on VS. I otherwise despise Windows itself. It's a pig. If you ever really test performance, especially I/O (disks) and processes, you'll recognize just how powerful and advanced Linux really is (even UNIX, depending on which release, is superior - like from another planet superior).
I simply must hand it to VS, though. The compiler itself isn't all that impressive, but the IDE has not been exceeded in many years. I wish they made Linux and MAC versions, but they don't. They offer Visual Studio Code - which ultimately is a "also ran" version of the same kind of result I see with everything from KDevelop to Eclipse, IntelliJ, QtDevelop and all else on *Nix.
Yes, just put the keyword "inline" in front of the two functions I mentioned - it takes care of some linker errors referencing mersenne twister as already defined (it's a related notion to random values those functions use).
Don't forget about graph.cpp. The files I show to add to the include section reduce hundreds, possibly thousands of very strange errors (it would make you think std::vector is no longer valid code).
Why...I didn't research. I just noticed a depenency on other translation units. I compiled them one at a time, where main, window and gui all compiled with minor warnings, but graph blew up.
Also, I added the appropriate dependencies from the build of FLTK, and set input directories for the linker, and include directories for the compiler which aid in directory structure (which is what Stroustrup references with the "call a friend" suggestion).
Not much else was required as I recall.
I set the compiler for VC++14 compliance, so I expect VS2015 would be fine if it has been updated.
As to skipping to other sections....well, the work is from elementary to upper intermediate C++11/14, so to me it seems reasonable to skip what you already know. That said, if what you know is C++03, then reviewing what is new about C++11/14 would suggest not to skip. Even with decades behind me, I found skimming through informative as to Stroustrup's points, though I didn't need to do more than skim - that's just because of the decades behind me.
| Man I wish I was a Unix guy! |
Well...there's two points on that. First, I was and am a "*Nix" guy, though I value Linux over UNIX in the present tense (they are identical designs, but Linux is what UNIX was supposed to be).
Still, acknowledging that there is no operating system on the planet as reliable, or efficient, as *Nix, it does deserve the reputation for being complicated. Having said that, so is Windows. At the same time, much of what users find "nice" about Windows configuration/updating is the same basic thing on many Linux distributions.
However, there is one thing that keeps me in Windows more than all else. I do require some applications for which there are either only Windows versions, or there are MAC versions "too". One of those is Visual Studio. Frankly, if you have ever tried to get a Linux workstation configured for development in C++, and compared that to the experience of getting Visual Studio installed and ready on Windows - there is no comparison. Nothing goes from zero to ready as easily or quickly as Visual Studio. QtCreator does offer a close comparison, but it really is not quite the same in operation.
You are actually well served in Windows under Visual Studio, with one caveat. The Microsoft compiler is not going to be among the more current with C++ standards. Some regard it is poor, though it is fairly good through C++14 in VS 2019, and does support much of C++17. On the other hand, configuring and using CLang in Visual Studio 2019 is nearly trivial, which is much better C++ conformance. GCC I've never figured out for Visual Studio, though I know it's possible.
Key to VS productivity is the project configuration. For anything short of a massively complex project, the ability to configure a project in VS is extremely simple. Compared to, say, Eclipse, it's effortless. Most other IDE's very quickly become little more than a front end to CMake, Make or other command line build tools.
Eventually we all should learn to use those command line build tools, but for the early years, and for quick "start to working" - nothing beats VS for quickly making a project grow fast.
The other is the debugger. It's fast, reliable (surprisingly robust), and full featured. Comparing other debuggers is just no fun. KDevelop is fair, so was Eclipse (lately I can't get a Linux Eclipse installation to stay configured and working). QtDevelop is like KDevelop in the way the debugger works, which is ok, but not nearly as full featured as VS Studio in Windows.
I'm not trying to sell you on VS. I otherwise despise Windows itself. It's a pig. If you ever really test performance, especially I/O (disks) and processes, you'll recognize just how powerful and advanced Linux really is (even UNIX, depending on which release, is superior - like from another planet superior).
I simply must hand it to VS, though. The compiler itself isn't all that impressive, but the IDE has not been exceeded in many years. I wish they made Linux and MAC versions, but they don't. They offer Visual Studio Code - which ultimately is a "also ran" version of the same kind of result I see with everything from KDevelop to Eclipse, IntelliJ, QtDevelop and all else on *Nix.
Niccolo,
I will definitely compile a list (not on the computer - on paper!) of the changes you made and I will be touching base with you as I try to repair the FLTK mess I created. I did remember what you said about Graph.h's placement in the include "chain" and I will place it at the very bottom of the list so that it can't complain about dependencies not being available.
I'll inline those functions you detialed (a lesson in itself about what inline does for overhead and also functionality!!) and then I'll DELETE GUI.h and make sure only Gui.h is left and make everything that invoked GUI.h redirected to Gui.h.
I HOPE this goes smoothly but I'll be in touch I'm sure! I also read his instructions at the end of chapter 12 and he says that the .cpp files (I forget their names at the moment: Windows.cpp or maybe Simple_window.cpp there might be another there too...) need to be placed into the project under sources with my main source file so that the headers work properly. There's that brittle crap again. Did you have to to do this as well?
I originally learned on UNIX machines in college and have since fallen away and I agree with you - it is light years beyond Microsloth and Windblows in multiple areas but then it just seems like the *Nix community keeps it purposefully vague and nebulous and even artificially "complex" on purpose to limit (it would seem.... not a reality I'm sure??) who actually jumps into it. It is hands down way more secure and impregnable compared to all the holes and patches that Microsloth needs constantly.
As you point out though, being able to "manipulate" the *nix OS of choice easily to be able to do anything with it in a relatively short period of time (not in years of one's life...) is frustratingly mind-numbing and odd and almost demands an advanced degree in Computer science in and of itself. You would think that the *nix community would just be able to say at some point: "Look, *nix blows the competition away and here are applications that prove it - anything MS can try to do.... we do WAY better AND now we've made it just as easy to do so!!
So there is NO reason for you to stick with the crap OS's of the world any longer" They wouldn't have to offer it as free-ware either!
I would purchase an OS that had the best of both worlds that you described. Also, if it was able to run all the engineering programs and regular text editors and spreadsheets etc. then they would be in business.
I realize most of the *nix community is private small developers - but you're telling me that if a couple of these guys leveraged their skills and the power of *nix OS and was able to offer the software that is MORE powerful and just as "easy" to set up as VS that we wouldn't buy it? I would buy it!
Hell, knowing that I would never have to have my machine talking to MS HQ every other dang day just to update some obscure piece of crap social media code that I could give a flying damn about (not to mention the ever growing loss of privacy AND control of one's own damn computer...) would have me in the *nix camp in a second!
I wouldn't need convincing!
Thank you for your help again, I will attempt the "repairs" tonight when I get home and see if I can't pull this crap show out of the circular file in the manner you detailed!
Xanadu
I will definitely compile a list (not on the computer - on paper!) of the changes you made and I will be touching base with you as I try to repair the FLTK mess I created. I did remember what you said about Graph.h's placement in the include "chain" and I will place it at the very bottom of the list so that it can't complain about dependencies not being available.
I'll inline those functions you detialed (a lesson in itself about what inline does for overhead and also functionality!!) and then I'll DELETE GUI.h and make sure only Gui.h is left and make everything that invoked GUI.h redirected to Gui.h.
I HOPE this goes smoothly but I'll be in touch I'm sure! I also read his instructions at the end of chapter 12 and he says that the .cpp files (I forget their names at the moment: Windows.cpp or maybe Simple_window.cpp there might be another there too...) need to be placed into the project under sources with my main source file so that the headers work properly. There's that brittle crap again. Did you have to to do this as well?
I originally learned on UNIX machines in college and have since fallen away and I agree with you - it is light years beyond Microsloth and Windblows in multiple areas but then it just seems like the *Nix community keeps it purposefully vague and nebulous and even artificially "complex" on purpose to limit (it would seem.... not a reality I'm sure??) who actually jumps into it. It is hands down way more secure and impregnable compared to all the holes and patches that Microsloth needs constantly.
As you point out though, being able to "manipulate" the *nix OS of choice easily to be able to do anything with it in a relatively short period of time (not in years of one's life...) is frustratingly mind-numbing and odd and almost demands an advanced degree in Computer science in and of itself. You would think that the *nix community would just be able to say at some point: "Look, *nix blows the competition away and here are applications that prove it - anything MS can try to do.... we do WAY better AND now we've made it just as easy to do so!!
So there is NO reason for you to stick with the crap OS's of the world any longer" They wouldn't have to offer it as free-ware either!
I would purchase an OS that had the best of both worlds that you described. Also, if it was able to run all the engineering programs and regular text editors and spreadsheets etc. then they would be in business.
I realize most of the *nix community is private small developers - but you're telling me that if a couple of these guys leveraged their skills and the power of *nix OS and was able to offer the software that is MORE powerful and just as "easy" to set up as VS that we wouldn't buy it? I would buy it!
Hell, knowing that I would never have to have my machine talking to MS HQ every other dang day just to update some obscure piece of crap social media code that I could give a flying damn about (not to mention the ever growing loss of privacy AND control of one's own damn computer...) would have me in the *nix camp in a second!
I wouldn't need convincing!
Thank you for your help again, I will attempt the "repairs" tonight when I get home and see if I can't pull this crap show out of the circular file in the manner you detailed!
Xanadu
Niccolo,
I THINK I did everything you said to do ….. and I have reduced the errors from 184 to 135..... so something is still wrong.
I don't know if I can send you the error list?? Recommendations?
Xanadu
I THINK I did everything you said to do ….. and I have reduced the errors from 184 to 135..... so something is still wrong.
I don't know if I can send you the error list?? Recommendations?
Xanadu