|
Before I ask a question, I should explain why I'm asking it and what for, to avoid flame, as question is highly flamable.
I'm in software development for 20+ years. I used to work with numerous (over 18) languages, many OSes, frameworks, platforms, etc. Over time I grew tired of learning some "new exciting tool/language/platform/you name it" just to have it disappear year or two later, or got superceeded with something else. I have only one life and don't want to waste it on learning "fashion" things that come and go before you even notice them. Besides, over time I grew to appreciate only two things - performance and "code beauty" (such as readability and maintainability). So, my by far preferred choice is C++. Yes, it is over 40 years old, but I bet it'll stay here for at least same amount of time. STL earned it's way into same league of "yes, we are here forever" (although I'm not big fan of it, but yes, it is well worth learning and sometimes even using  it). And, or course, SQL. The new guy on a block is OpenCL, which was fighting with CUDA for quite some time now, and finally started to get into the same status as C++, STL and SQL.
I want to make myself clear - this is my personal choice, and I'm not advocating anybody else to agree with me, I just want to explain the starting point for my question.
I'm undertaking a new project right now with two goals in mind. First one is obvious - if I succeed, I wouldn't need to work for somebody else ever again . Second goal is - if I'll fail, then at least I will learn something new to make me more marketable, as in "able to find a decent and fun job with high pay" . And this is second goal that gives me headache right now.
Major part of the project is "number crunching", so I'm fine with what I already know and have. But minor part of the project involves GUI, and that is where I was hoping to learn something new AND have value of that skill to be retainable for quite some time. I used to work with Delphi/VCL (which I deem as a very, very good attempt at being perfect framework), Powerbuilder (well, this was not quite a framework, but it was, well, not too bad, and for displaying large amounts of data it was the fastest thing I ever saw), and last few years I worked extensively with MFC/ATL (which I deem as ugliest thing ever invented), and some other libs/frameworks that are not even worth mentioning.
So, I set myself on a search for a new GUI framework that "is here to stay". I code 99.99% of time for Windows, so I didn't care for other platforms. And, yes, I use MSVS - sorry, I like it the most. Call it personal preference, but I'd like to stick with it.
First, I checked Borland's (now Embarcadero) C++ Builder. Took them off the list - can't use VCL in MSVS, and they don't even have 64-bit compiler (which is an absolute must these days).
Then, I checked Qt. Oh, I wanted to try it for some time by now, and believe me, I spent a week reading, reading and reading about Qt 5, trying to convince myself to go this route - after all, they've been around long enough and very successful. But sorry, looks like I have to take this framework off the list also. And the reason is - they made a move that indicates beginning of the end of the Qt. You probably heard it: QML. Jeeze, I seen a zillion attempts of big corporations to introduce language/tool/methodology to "simplify" programming or design, so they can hire low-paid people off the street with no skills, and have them produce programs using this new thing. All of those attempts failed, and failed miserably. And the reason is well versed in this quote: "make a tool that even a fool can use, and only a fool would use it". Well, whatever the reason is under the choice Qt devs made, it takes Qt off the future desktop development. Yes, they will stay in for probaly another 5-10 years, but starting this summer (with inroduction of QtQuick 2) this is a dying framework (from C++ point of view).
Then I saw Ultimate++. Looks excellent, nice, neat and fast code, been here for 11 years, stable enough. Two problems: first, I can't use MSVS with them. Second: well, with all due respect, just how many U++ jobs are out there? Yes, zero.
So, am I stuck with MFC/ATL/WTL? Or can someone recommend a framework/library that "is here to stay" and have a "hire-able" value? I really want to find something, as MFC causes a PITA every time I have to use it.
P.S. Yes, I'm aware of WPF and WinForms, but no, with managed C++ they are not worth it.
|
|
|
|
|
Kosta Cherry wrote: recommend a framework/library that "is here to stay" and have a "hire-able" value?
You are asking people to foretell the future. How can we know what may be in vogue next month or next year, or what experience employers will be looking for? My best advice would be to get away from C++ and look at WPF, HTML 5 etc; but then, what do I know?
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Well, you are right to some extent - nobody can foresee a future. For example, if someone asked me same question six months ago, I'd say - go Qt. And then they blew up. On another hand, it's year 2012, and it amazes me that these is still no widespread good, "industry standard" C++ GUI framework. Or at least I don't know about the one.
MFC/ATL is "industry standard" (on windows), but it is by no means "good". Qt was meeting these requirements for quite some time, but not anymore. So I'm kind of clueless at this moment.
As for HTML5, for example - I can code it; I also know Java, C# and many other things. Yes, they are in demand, but, as I tried to explain, I can't make myself to have fun with them - not after you get with C++. Yes, for someone struggling to find at least some job I might look nitpicking and arrogant, but as long as I have choice, I'd like to stick to something that gives me sense of inner satisfaction and joy. Language-wise, it happend to be C++, so I'll try to ignore other things for as long as I can
modified 26-Sep-12 12:01pm.
|
|
|
|
|
Kosta Cherry wrote: it amazes me that these is still no widespread good, "industry standard" C++ framework.
Well we have choices, that is surely better. The ones that are used by the majority of people tend to become the unofficial standard.
Kosta Cherry wrote: MFC/ATL is "industry standard" (on windows), but it is by no means "good".
How do you define "good"? Lots of people use either one of these and are quite happy with them; others use WinForms in C# or VB.NET, still others use WPF.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Richard MacCutchan wrote: How do you define "good"? Lots of people use either one of these and are quite
happy with them; others use WinForms in C# or VB.NET, still others use WPF.
Well, personally (and others have other views, I'm sure) I deem framework "good" when I:
1) don't need documentation to use it, i.e. it is self-explanatory, and usage is obvious with no hidden surprises. If you need to read hundred doc pages before writing "HelloWorld", it is not good;
2) spend my time using framework, instead of fighting with it, trying to overcome shortcomings/bad design;
3) can use it the way I'd see feasible, and not the "only" way authors force you to go. For example, MFC is bound to Doc/View paradigm. As soon as you even think to try to go other way, you are penalized. I mean, it is still doable, but with much more efforts than it could be and should be.
As for WinForms or WPF - they are very good if you use C# (or other .Net lang). If I'd go with C#, I'd jump on winForms, and there would be no question. Question is about C++ framework...
For example, I'd say that Win32++ is close to ideal, with two exceptions. First one is minor - author uses same names as MFC, so you can't mix'n'match those two, but this is really minor. But second exception is very big, and is very same as U++ problem - who uses it? Very, very few people, so even though I like this one, it is of no use for my goal.
|
|
|
|
|
Well I guess we agree then.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
When I programmed in C++, I never felt comfortable with creating a GUI. What about being a little schizophrenic: stay with C++ for most programming purposes, and use Managed C++ (Windows Forms) for the GUI?
|
|
|
|
|
Well, I tried to explain my goals. For the needs of the project I can use anything available - Qt, Win32++, or even straight Win API - it'll all work out fine, as GUI that I need it very minor. But the goal is not just use some framework to create GUI, but learn it for good and then use in extensively on my next job(s), and not jumping on a new framework every (half)year. I'm already at the age when job should also bring fun, not just money. And Managed C++ is by no means "fun" - whoever designed it was really, really sick, and probably inspired by Brainf.ck language Basically, there is no beauty of C++ left in it, only "Managed" horror 
|
|
|
|
|
Kosta Cherry wrote:
And Managed C++ is by no means "fun"
Depends on your definition of fun. MC is obsolete btw, have you tried C++/CLI? I find C++/CLI very enjoyable with the added satisfaction that I can mix native c++ code like no other managed environment would let me do. For a good amount of time, I struggled to find a decent standardized c++ framework for web applications and even though there were some I didnt like any (just like you) and finally the idea of using C++/CLI to utilize the powerfull .NET framework stuck. Its fun for me because with just a few lines of code I get to expose my native c++ functionality as WCF webservices and from the same executable. It is marketable because you get to learn new .NET stuff as well as the intricacies of mixing with native. Mastering WPF, even though with C++/CLI, will be profitable because WPF is going to stay especially with Metro apps coming out in upcoming Windows8 and the possibilities they open up for Windows App Store are huge.
A downside however is that mono still does not support C++/CLI therefore its not portable yet.
|
|
|
|
|
I'd suggest VB.NET - easy learning curve, and nice for fast prototyping. Additional extra is that it won't be as hard to find new colleges.
Kosta Cherry wrote: I'm already at the age when job should also bring fun, not just money.
There's no such age.
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
I know this is a silly thing to ask, but here it is. I have been working in development for about ten years now, I am pretty much a Google programmer in that I use the internet to find out what I need to fix code problems. I do not have any formal schooling. I have done fine building business applications, but now I want to move into a more corporate formal environment. I don't have the time to go to school to learn OO programming from scratch, nor do I really want to, but looking over questions other people have had from this company in interviews, I would just be clueless. I like to consider myself a practical programmer, the truth is, though, that I am just untrained.
With that said, can anyone recommend a site where I can go to gather some of this information? I think I mostly need help with the data structures and algorithms, as they don't come into my daily work.
Any help would be appreciated.
Cheers, --EA
|
|
|
|
|
Since you've been in the industry for a while, I expect a couple of books on Data Structures + Algorithms and Design Patterns (in the language of your choice) should see you through. When I was a student, I used an earlier edition of Algorithms and Data Structures by Niklaus Wirth[^] (who I also met later - he's a great guy, very personable). For design patterns, it's hard to go wrong with the Gang of Four[^] book.
/ravi
|
|
|
|
|
OO is not so much about algorithms, it is more about design. The "Gang of Four" patterns are a good point. I also like "Applying UML and Patterns" by Craig Larman: he brings patterns, UML, and agile strategies together and explains them with good examples.
|
|
|
|
|
Where in the code do I best put object creation (stateful objects) and where not? In what layers?
For example, I once put an object reference inside a Hibernate DAO class and I was told that this was incorrect because DAO classes are not supposed to have state. State should be inside the 'service layer'.
I have been told that I should not create new objects on recurring method calls such as UpdateCart(). Creation of objects is costly and should not be sitting in your code everywhere. It should be sitting in initialization type methods only. For example, if an e-commerce application needs a cart, put it in the session. If it needs some general main object, put it in the initialization code. Create it once there and let the rest of the application access its instance later. Do not create this instance upon every call.
I'm confused about this whole design principle. The strangest thing I heard is 'an app is not supposed to have state. State should be kept in the data layer where the database is'. Really? I'm quite new to these design concepts and I don't know where to look in order to get more educated on it. GoF? Design Patterns books? The goal is to create qualitative code (i.e. to be used in the business).
Thanks
|
|
|
|
|
CsTreval wrote: Where in the code do I best put object creation (stateful objects) and where not?
"As required".
CsTreval wrote: Creation of objects is costly
No, it's not! This is an incomplete statement, and a fallacy; you can create a huge amount of objects, and very quickly. Creating huge objects in a loop, that is inefficient. The statement should be "do not create costly objects in a tight loop".
CsTreval wrote: and should not be sitting in your code everywhere.
Decompile the Button class using ILSpy or something similar. You'll see efficient code, without a centralized factory. Objects should NOT come from one location, one uses a factory ONLY if appropriate. The "new" keyword isn't there just for the looks of things.
CsTreval wrote: The strangest thing I heard is 'an app is not supposed to have state.
Too much monkey business, I'd be walking out on this statement.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Sorry to say this but you don't seem to be very educated. You never heard of stateless architecture?
|
|
|
|
|
CsTreval wrote: Sorry to say this but you don't seem to be very educated
I did not have any official schooling. Does it show? 
CsTreval wrote: You never heard of stateless architecture?
Heard of it, never worked on it, and I'm doin' this for a few years now. Applications usually have a state, since the components in there have a state. A connection-object is either opened or closed. What you implied is that this information (whether the database-connection is opened or closed) should only be stored in the database.
Being my usual self (the sig was a warning), please educate me, show me where I'd need it. Until you can explain what it's good for, I'll judge it by it's appearance, and it appears to be an abstraction too far for the architecture.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Yes, it shows.. unfortunately.
modified 23-Sep-12 14:37pm.
|
|
|
|
|
CsTreval wrote: Yes, it shows.. unfortunately
You're the first to complain 
I could have bought an official degree a few years ago, sounded like a waste of money. What good is a degree without education?
CsTreval wrote: I'm studying at a very severe university
That does not impress me at all, especially after having to clean up behind some academics.
CsTreval wrote: For example, if you create an object it has to be created in the right place or else you will be criticized on it.
Ehr.. I'll make it worse; you'll have to be able to defend each and every letter you type. I wouldn't accept code in the base that is not completely understood by it's author.
CsTreval wrote: Please see 'Arjan Tijms' answer for a very educated answer
.NET applications are rarely pure in their architecture, and most of them will mix various idea's. A state-machine is cool when you're talking about traffic-lights, but it's not the base for most LOB-apps. And no, it is not said that the traffic-light information "should be" in a database.
One should learn to think; why in a database? Afraid that you'll loose state when there's no power? Then you'd better not use an in-memory database, or learn the memento-pattern and learn to serialize that information.
You still failed to answer my question; what are the benefits, or to quote Garfield; "what's in it for me?"
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
CsTreval wrote: For example, if you create an object it has to be created in the right place or else you will be criticized on it. So eventually I want to follow these strict rules.. because if I start coding carelessly, I will fail.
Nonsense as stated.
There might be rules for the classes you are taken. They might not even explain them to you. They might even be teaching you something that is correct in limited situations.
However your statements as a general rule are wrong.
|
|
|
|
|
Could you let us know where this university is and what, exactly, the course is that you are doing?
|
|
|
|
|
Take my advice: Don't make yourself look worse than you already have.
|
|
|
|
|
Eddy Vluggen wrote: What you implied is that this information (whether the database-connection is opened or closed) should only be stored in the database.
That's not really what's meant by stateless design.
I'd happily agree with you that any information stored anywhere IS "state" but going by this definition we'd be talking about information-free information systems, and I suspect they'd be useless.
What people actually mean when they speak of stateless is that the object instances themselves are stateless. There are no instance members. But there are method parameters and local variables, and they live on the stack. (If they are references to other objects, the objects themselves of course live on the heap. But every reference to them will be on the stack.) This leads to two properties which are sometimes desireable: You can't corrupt the heap in such a way that it affects more than one thread. A service for instance may fail under some condition, but this can't leave the server itself corrupted and subsequent requests still have a chance of succeeding. Secondly, it means the same "objects" can be shared among many threads, because they use the stack of each thread to store all the state they manipulate.
Lest you now become a fan, let me just add this: Stateless design also means throwing OOP out the window! Some will argue on this point, but here's my take. What really defines OOP is 3 things: Encapsulation. Inheritance. Polymorphism. But stateless implies you are creating "objects" that really are nothing more than a bunch of routines. And although you still have inheritance and polymorphism to play with, you can't put them to really good use, because you no longer have any objects, just mini-libraries of routines and subroutines!
Personally, I consider encapsulation the far most powerful - and least understood - aspect of object-oriented programming. It is what makes it object-oriented! You cannot model stuff as an object if you can't encapsulate. You could still do it without inheritance or polymorphism, though they are both *very* useful and powerful concepts. The most I would ever consider using stateless architecture for would be a small part of a server. This would ensure this part couldn't get corrupted. Then I'd make everything else properly object-oriented and build capability to "reset" the state into it. Hence the service could sort of "reboot" in case of trouble, and I could still program the vast majority of the system properly!
|
|
|
|
|
dojohansen wrote: What people actually mean when they speak of stateless is that the object instances themselves are stateless. There are no instance members.
This must be theoretical; I don't see this work with static (shared) members.
It's a nice explanation, but at this point, there's not much I can actually do with it 
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Actually I made a mistake; correct would be no instance *state*, i.e. no instance fields, only local variables and method parameters.
But it sure can work also with only static methods, though in that case you of course *also* lose the ability to use polymorphy.
Note that this doesn't imply there should be any static fields. They too would live on the heap and represent shared state.
Come to think of it, "isolated state" or "local state" would actually be better names for this type of architecture than "stateless". And again, personally I'm no fan of the beast.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
