C++/Java/C#

For a C programmer, knowing the basics of OOP, which of the title's language you think is better?
If you cannot define better, then which is more easy to use knowing plain C? For example, should somebody learn C++ or just go to the newer C#?

I vote C++.
C# is tied to dotNet, which, at the moment, is unportable.
Further, it is slow, it is easily reverse engineered, it gives no control over memory (uses a garbage collector) and the language itself is flawed, especially in the eyes of many C++ programmers.
Java is also interpreted which means easy reverse engineering and slow execution.

No, C++ is the best language today IMO, because it gives you control over what you want to do and how.
C# limits you to a slow framework, limiting your options.
C++ is as fast as, or faster, than C. It is also backwards compatible with C. And C++ has a great deal of pre-written code.
This means you can fall back to C if you need to communicate with hardware, for example, and yet you can program in high-level programming without sacrificing much speed.

If you already know C, then C++ is definitely the easiest to learn (all you need to learn is the ++ ;) )
Java has these things they call "references", which aren't really references, they're more like pointers, but not quite. It also doesn't have a lot of basic things like a const keyword, destructors, and the option of whether you want to pass by value or by reference...

I would learn Java or C# rather than C++. It would be too easy to get stuck using C habits if you moved on to C++, and it would be easier to learn C# or Java without that burden.

Once you learn either of those two language you can always go back and learn C++ with a different mindset and combine that with your C experience to get the most out of C++.

What kind of development do you want to do? A lot depends on that.

Yeah, everything depends on what you do. Well, don't have anything in mind. I just like "thinking in simple way". Thus more like in C. But I would also want to "upgrade" to something more modern so I can use more modern libraries and all the such.

What you say Dave is the best thing to do. I would advise it for someone new in programming. But since I have learned to program in C I would like first to go to something similar, learn its new features but still programming C-like. Then little by little I ll learn more and more features more and more functions and have a more varied way of programming.

The 3 languages just look very similar to me. And I am kind of indecisive :) But I ll listen to most advises to go to C++.

>> But since I have learned to program in C I would like first to go to something similar, learn its new features but still programming C-like.

The problem is that to get the most out of C++ you need to avoid many of the habits you learn from C. Modern C++ is very different from C even though you can still code with C style in a C++ program. New C++ programmers with C backgrounds often fall back on their C knowledge instead of learning the new (and usually better) solutions available in C++. This is why I suggest starting with a language that won't let you fall into that trap.

Then would you suggest learning Java before C++?

I'd say it is a tough call, if all you want is to learn more programming languages. Daved's argument is that learning C++ right after learning C tends to cause the learner to stick to C techniques, thus missing out on C++ techniques. On the other hand, learning Java next would mean that you may pick up habits in Java that do not normally apply to C++.

In the end, I think that the choice does not really matter: you will always have to "unlearn" something that does not apply.

C++ is my first language I am learning. I am doing the tutorials online and will be taking C++ classes at my local college soon. After C++, I plan to try and tackle Java.

>> Then would you suggest learning Java before C++?
In reference to the original question, yes I would choose Java or C# first because the OP already knows C. In general, it really depends. There's nothing wrong with learning C++ first, especially if you've already started.

I think the choice matters, but it won't stop you from being a good programmer, it will just take you down a different path. I would suggest learning a language well enough to use it to learn broader programming concepts before moving on to another language.

You could learn something radically different from C, if you just want to broaden your horizons. You could learn Smalltalk. You could learn Lisp. You could learn Haskell.

Java and C# are pretty much purely object-oriented, but they're still strictly typed (more strictly than C, actually), they use C-style syntax, and generally have a lot of C heritage.

Smalltalk is purely object-oriented (one of the earliest object-oriented languages) - and I mean extremely pure - dynamically typed, and has hardly any similarity to C at all.

Lisp (Common Lisp in particular) is a functional/imperative hybrid with strong meta-programming capabilities. Radically different from C.

Haskell is a strictly functional language. It requires a completely different way of thinking.

Quote:

---

Java is also interpreted which means easy reverse engineering and slow execution.

---

Modern JRE's do dynamic recompilation (compiling sections of frequently run code to native code based on runtime profiling), and some people have tried to show that it can be faster than a compiled language such as C++ (with optimizations based on runtime profiling which C++ programs don't have). Theoretically true, but practically, as of now, Java can only be faster than C++ on specially crafted code. But still, while it is generally slower, it's not like 5 times slower like it used to be.

That aside, I vote for C++. C# is too proprietary for my liking, and Java is incomplete (operator overloading, and what people mentioned above). I have a feeling that Java's design assumes that programmers don't know what they are doing. While it is true that I don't know what I am doing, I don't like that feeling :). Operator overloading is an example (funny how they have to use it with their string class, but allows no one else to). Pointers, too (what are references doing in there then?).

Not to open a different topic, but can someone tell me what are the BIG differences in Java and C++. Differences on what you can do easily and what you can't. Lets not consider the differences in performance, safety, etc etc

I can't say much details, but as some have already mentioned: Java can't overload operators and Java is purely object-oriented.
That means there are no free functions - everything is inside objects.
Numbers and strings and all that are not objects in C++ - they are data types, so you can't expect "something".length() to work, as it might in Java.

Java does not support generic programming and templates to my knowledge. And I'm sure there's more.
Oh, and Java can't do multiple inheritance, can it (C++ can)?

Java has huge, easily available libraries for server-side web programming. So many, in fact, that learning just a few for comparison is quite a task. C++ has far fewer there, and of lower quality. So for the web, Java is the better choice.

For the desktop, C++ has the better libraries available, IMO.

Language capabilities are much more about available libraries than the language itself. The libraries tell you what you can do (with reasonable effort), while the language capabilities merely decide how you do it.

C++ has crap support for classes in libraries (dlls). Compile a dll in one compiler and u get face-slapped when trying to use it in another. And you're limited to the most basic types in library interfaces, you can't use std::string as an example.

Quote:

---

That means there are no free functions - everything is inside objects.

---

Static functions

Quote:

---

Numbers are not objects in C++

---

Neither in java, though they have wrapper classes that objectify them

Quote:

---

Java does not support generic programming and templates to my knowledge.

---

Java has generics. Both templates and generics have their pros and cons.

Quote:

---

Oh, and Java can't do multiple inheritance, can it (C++ can)?

---

Multiple inheritance isn't neccessarily a good thing

Quote:

---

Originally Posted by Magos

C++ has crap support for classes in libraries (dlls).

---

C++ has no support for it at all. You mean operating systems specific compiler/loader/linker.

Quote:

---

Originally Posted by Magos

And you're limited to the most basic types in library interfaces, you can't use std::string as an example.

---

Why that? Thats a function of mine I call from a lot of different DLLs for example

Code:

---

const std::pair<int, std::string>
get_type()
{
        return std::make_pair<int, std::string>(ut), std::string("T72"););       
}

---

Another option that hasn't been mentioned: learn a scripting language like Python or Ruby, as well as how to interface with C and C++ from said scripting language (I'd recommend SWIG for that).

Quote:

---

Originally Posted by Elysia

That means there are no free functions - everything is inside objects.

---

Not 100% true. You can have static functions that don't require an object. You still need to put it in a class but you never need to make an instance of it.

Quote:

---

Java has huge, easily available libraries for server-side web programming. So many, in fact, that learning just a few for comparison is quite a task. C++ has far fewer there, and of lower quality. So for the web, Java is the better choice.

---

For web I like PHP. Loosely typed works well for the web IMO.

Quote:

---

You could learn something radically different from C, if you just want to broaden your horizons. You could learn Smalltalk. You could learn Lisp. You could learn Haskell.

---

Lisp was interesting but the overuse of parenthesis make it a bear at times. I would also recommend prolog for something different.

Quote:

---

Originally Posted by pheres

Why that? Thats a function of mine I call from a lot of different DLLs for example

Code:

---

const std::pair<int, std::string>
get_type()
{
        return std::make_pair<int, std::string>(ut), std::string("T72"););       
}

---

---

That opens a whole can of worms for support & program updates:
Chapter 63. Use sufficiently portable types in a module's interface

Quote:

---

Originally Posted by C_ntua

Not to open a different topic, but can someone tell me what are the BIG differences in Java and C++. Differences on what you can do easily and what you can't. Lets not consider the differences in performance, safety, etc etc

---

In addition to what I already said about Java above, Java does almost everything at runtime instead of compile time. So the "Generics" that Java has is crap... If you have a List<int> and List<String>, you only have 2 List's of objects after you compile it.

Quote:

---

In addition to what I already said about Java above, Java does almost everything at runtime instead of compile time. So the "Generics" that Java has is crap... If you have a List<int> and List<String>, you only have 2 List's of objects after you compile it.

---

Type erasure is not crap. It's less powerful than substitution generics, but has the advantage of producing much leaner code.

Quote:

---

Originally Posted by C_ntua

Not to open a different topic, but can someone tell me what are the BIG differences in Java and C++. Differences on what you can do easily and what you can't. Lets not consider the differences in performance, safety, etc etc

---

• In C++ you can very easily crash your computer. In Java it is a little harder.
• In C++ you can very easily create unsafe applications. In Java it is a little harder.
• In Java you can very easily find a job. In C++ it is a little harder.

• In C++ it is very hard to find something you can't do with it. In java it is a little easier.
• In C++ it is easy to interface with hardware devices. In java it is harder.
• In C++ it is very easy imbue other languages or access application APIs. In java it is a little harder (not necessarily java fault in most cases, but because of a general lack of proper language specific APIs).

Off the top of my head.

Quote:

---

Why that? Thats a function of mine I call from a lot of different DLLs for example

---

Try to compile and use on different compilers and you'll soon notice why. I did a while back on VS and Mingw I believe with unstable results.

Quote:

---

Originally Posted by Mario F.

• In Java you can very easily find a job. In C++ it is a little harder.

---

Really? That surprises me. I guess I'm looking for work as an engineer and not a programmer, but I know from experience that me and almost all of my friends were asked if we knew C++ (and/or Matlab) when applying for jobs. I don't know of anyone who was asked about Java.

Meaning there's usually more demand for java than for C++. Not that you can't find C++ jobs.

I can though be biased my own own job market trends, although I noticed similar tends in other countries. Notably Australia, Canada and Spain.

In certain industries - like the trading industry here in Chicago and also in NY - C++ is the preferred language. In general IT, it's Java/J2EE and C#/.NET. Still some C++ there, but not nearly as much as the others.

That's why I ask what type of programming one is interested in when asked which language to choose.

Quote:

---

Originally Posted by cpjust

That opens a whole can of worms for support & program updates:
Chapter 63. Use sufficiently portable types in a module's interface

---

The link says:

Quote:

---

Typically, either you control the compiler and options used to build the module and all its clients, and you can use any typeor you don't, and you can use only platform-provided types and C++ built-in types (even then, document the size and representation you expect for the latter). In particular, never mention standard library types in the interface of a module unless all other modules that use it will be compiled at the same time and with the same standard library source image.

---

Fortunately I control the compiler for all modules. But it was an interesting read, so thanks.

Quote:

---

Originally Posted by pheres

The link says:

Fortunately I control the compiler for all modules. But it was an interesting read, so thanks.

---

I would still avoid using non-primitive types across modules though, because if you apply any compiler service packs, or even change some compile settings and then fix a bug in one of your DLL's and release a patch to customers, the ABI might not be compattible anymore.

So much for the Standard template library.

>> So much for the Standard template library.
Why? It's a standard interface, not a standard implementation.

It's quite disgusting to see that you cannot use standard library types in an interface.
Then what is the whole point of using C++? It is, maybe, the single, biggest flaw in the entire language.
Use any types except for the standard library types and it works well.
It severely limits C++ interfaces.

>> Use any types except for the standard library types and it works well.

This is wrong. The problem exists for any non-primitive type.

True, in a sense, but not as much.
They are more compatible, although may still cause some problems.
But that's just another thing to add to the list of things C++ can do better.
It's pretty inexcusable for a modern language not to be able to create a stable interface.

>> They are more compatible, although may still cause some problems.
I don't understand what you're trying to say. Any library type will cause problems if you link to different implementations of that library. The only reasons the standard library is used as an example are that it is used often and there are different library implementation available.

>> It's pretty inexcusable for a modern language not to be able to create a stable interface.
You can create a "stable" interface, just not one using all the library additions you'd like to. I'm not saying that these issues aren't a burden, but you're making things up to complain about.

Quote:

---

Originally Posted by Daved

>> They are more compatible, although may still cause some problems.
I don't understand what you're trying to say. Any library type will cause problems if you link to different implementations of that library. The only reasons the standard library is used as an example are that it is used often and there are different library implementation available.

---

Well, the idea was that in implementation X, std::string has a member called, say, m_str of type const T*, and then a size of type size_t.
In implementation Y, those are switched, so it would likely cause rubbish data or a crash when passing it through an interface between those two.
However, if it were a custom data type, this would not occur because they would always be placed at the same location.
What might cause problems may be padding or such.
Thus custom data types are not as prone to errors as standard library types. They're less error prone, but still error prone.

Quote:

---

>> It's pretty inexcusable for a modern language not to be able to create a stable interface.
You can create a "stable" interface, just not one using all the library additions you'd like to. I'm not saying that these issues aren't a burden, but you're making things up to complain about.

---

No, not really. You would expect to be able to pass C++ types across boundaries, but the fact that you cannot makes this a big deal that is worth complaining about.
I haven't heard of many such issues with other languages. Especially not Java, C# and the like.
C++ cannot compare to those languages in this respect and it's a real drawback that is limiting the language's potential.

Am I overreacting?

>> However, if it were a custom data type, this would not occur because they would always
>> be placed at the same location.

This is (again) missing the point. Any custom type will have a problem if you link to different implementations of it. Of course it will be less of a problem if you completely control the building of your own custom type, but that wasn't my point. My point was that all libraries have this potential issue, it is not specific to the standard library. There are many other libraries available that you do not control and you will can have the same problem with those. The problem is not with the standard C++ library, the problem is with the language itself and the lack of ability to ensure a consistent implementation.

>> You would expect to be able to pass C++ types across boundaries, but the fact that you
>> cannot makes this a big deal that is worth complaining about.

Sure, but you're complaining about the wrong thing and basing it off of (or backing it up with) erroneous information.

Quote:

---

Originally Posted by Daved

The problem is not with the standard C++ library, the problem is with the language itself and the lack of ability to ensure a consistent implementation.

---

Ah well, in the end it boils down to that. And that is the problem, indeed.
And that is the problem they really must address.
The End :)

Quote:

---

Originally Posted by Daved

>> So much for the Standard template library.
Why? It's a standard interface, not a standard implementation.

---

The code example provided that spurred this last discussion was entirely made of built-in types and STL interfaces (an int, an std:: pair and a std:: string). Naturally I couldn't agree more with you when you mention this is necessarily a problem with any libraries that provides an interface to built-in types.

However, I think this should be addressed exclusively from the perspective of different programming languages (where the argument does make a lot of sense). Not for fear of different C++ implementations. The STL interface should be only one, the implementation however can vary.

Hence my comment. It was an alert that it shouldn't be discussed as the latter.

EDIT: In the interest of portability I'm of course happy to ignore my own comments on this. And I'm glad I was following this thread when the comment from cpjust came. I hade never thought of it before. But I cannot ignore the irony behind what now becomes lack of portability feature of the STL, according to the text.

It's not just STL objects that have problems across modules, it's any object. Even though the API of the STL (or custom) objects don't change between various compilers (or compile options), the ABI does.

FUD.

Compiler vendors take great care not to change their ABI between compiler versions, especially minor compiler versions. You can safely do any micro version upgrade in GCC, for example, because the rules of development state that no such incompatibilities are allowed to exist. The same applies to minor versions, but there are a few exceptions (there was big trouble during the GCC 3.2 to 3.4 versions). Only major GCC upgrades (from 3 to 4) make no guarantees about ABI compatibility.

Pretty much the same applies to Microsoft's compilers. I don't know exactly when they break ABI compatibility, but I'll bet it's not very often.

Any vendor that breaks the ABI more than once in several years is using a completely idiotic development methodology, and that's not C++'s fault.



No, the only real problem is interoperability between different implementations.

Surprisingly, there's still a lot of companies using VC++ 6.0. If they suddenly decided to get out of the stone age and upgrade to the latest version, I'm almost certain the ABI would be different. As for minor compiler patches, sure it's unlikely they would change the ABI, but not impossible.

You never know how long a particular version of your software will be around, so unless you want to get stuck using the same compiler forever when you release product fixes, use only primitive types across DLLs...

Plus, I believe small incompatibilities can creep in even if you just change some of the compile/link settings.

Quote:

---

Originally Posted by cpjust

Surprisingly, there's still a lot of companies using VC++ 6.0. If they suddenly decided to get out of the stone age and upgrade to the latest version.

---

My client is one of them. There's just no real business case to upgrade 100s of thousands of LOC to get "out of the stone age". Some of the code hasn't been touched in 10 years but it's still running in production and bringing home the bacon.

Quote:

---

Originally Posted by medievalelks

My client is one of them. There's just no real business case to upgrade 100s of thousands of LOC to get "out of the stone age". Some of the code hasn't been touched in 10 years but it's still running in production and bringing home the bacon.

---

Well I highly doubt you'd need to change much of the actual code itself (unless they've been compiling with really low warning levels like my company has), but definitely the project settings.

Umm, are you missing that MSVC6 is not very standards compliant?
For example, pointers to member class functions were not fixed until 2005.
(Or maybe it's that the compiler is missing a lot of stuff, like partial template specializations.)

Quote:

---

Originally Posted by Elysia

Umm, are you missing that MSVC6 is not very standards compliant?
For example, pointers to member class functions were not fixed until 2005.
(Or maybe it's that the compiler is missing a lot of stuff, like partial template specializations.)

---

But most of that should only affect if you want to downgrade to VC++ 6.0. Upgrading should be pretty backwards compatible.

Well, as I mentioned, VC2005 breaks a lot of stuff from earlier versions because it's more strict and standards compliant.
Class member functions is only one example of where it will break existing code.

Quote:

---

Originally Posted by cpjust

I would still avoid using non-primitive types across modules though, because if you apply any compiler service packs, or even change some compile settings and then fix a bug in one of your DLL's and release a patch to customers, the ABI might not be compattible anymore.

---

Why not just update all modules in an atomic manner, after compiler/ SP/ settings changed?
Of course, this is not doable in all circumstances. So I think the rule to avoid complex types in interfaces is a bit strict and should be only applied if the project type demands it.

For example, for lot of projects my company specifies whole buildings, containing computers, containing OS and modules (built only by us) :) Never will there be a situation there we need to upgrade single components build with a different compiler or something similar.

Necessarily the advice needs to be taken with a grain of salt. The notion that "just because it may happen one day" is not always (rarely is from a business perspective) a good argument.

Do the rest agree that C++ has the best libraries? Or in any case very good ones?

Also, does it has good libraries for making a GUI compared to the others?

Generally, in which fields each of the above languages would be A LOT more useful? That would help me choose :)

GUI development in C++ is terror (IMO) and takes like 10x-50x as long to develop compared with say C#. Sure you could get a faster UI in C++ but this is neglectable in 90&#37; of the cases.

It depends on the frameworks much more than on the language. Most frameworks have bindings for several languages. What makes it in C# easier to say: "draw a window and put some controls in it" than in c++ in your opinion?
Using frameworks linke wxw or qt you even don't need to do that. instead just compose the gui with a wysiwyg editor and interface it from your application.

In general, the only thing which may increase development productivity while using other procedural/OO languages than C++ in my experience is the bundling of extended frameworks together with the compiler/interpreter/ide. In C++ you need to put this together yourself. But that matters only for very small projects (<1 week) I think.
Other stuff like memory management is just FUD imo. I can't remember more than one or two situations in which I had to deal with it myself. And that was things you just can not do in some other languages at all.

Quote:

---

Originally Posted by pheres

Other stuff like memory management is just FUD imo. I can't remember more than one or two situations in which I had to deal with it myself.

---

I can't imagine anything but a toy C++ program that wouldn't have to deal with memory management in some fashion. I'm not saying it's hard, it's just necessary and bothersome, whether it's ensuring RAII, using smart pointers, copy/assignment semantics, etc.

Bothersome? Nonsense, says I.
Unlike some other languages, C++ makes you carefully think about your design, and memory should be no different.
It's what makes C++ C++! The language we all love :D

Quote:

---

Originally Posted by medievalelks

I can't imagine anything but a toy C++ program that wouldn't have to deal with memory management in some fashion. I'm not saying it's hard, it's just necessary and bothersome, whether it's ensuring RAII, using smart pointers, copy/assignment semantics, etc.

---

what do you have to think about memory management if you just push your objects into an stl::vector for example any more than say in java?

I'm not all too familiar with C#, but I wouldn't dismiss Magos comment on a rush. Drawing from my VB experience, it's undeniable that I could produce complex GUI applications for Windows only in a fraction of the time I can today with C++.

Languages like C# and VB.Net are tailored to handle these environments. What would be surprising was if they didn't offer rapid application development at a higher satisfaction rate than C++ based libraries, or even MFC based RADs. WxWidgets, for instance offers RAD development through some of the tools you can purchase separately. They are however not nearly as sophisticated as Windows Forms nor they provide the necessary features to extend RAD development to anything but the simplest GUI applications. And definitely, they are too tied to the code to offer a real alternative for complex applications since only a fool would sacrifice functionality for design on this case.

I base all my wxWidgets application GUI development on the following sub phases. I include also average development times (1, being some unit of time)... Take this with a grain of salt, naturally.

1 - RAD development of window's controls layout (time: 1)

2 - Go back to code, alter generated code to conform with code design decisions, trim and optimize the unnecessary bits and provide at least minimum extensibility. (time: 1.5 to 2 or 3 depending on the complexity of the layout).

It's phase two that most RADs need to concentrate on in order to earn the title. I have only very minimal experience in Windows Forms, having tried it out of curiosity a couple of times while looking at C# features some 12 months ago. But I have many flight hours under wxWidgets (being my current and favorite C++ GUI library), and by no means any of its the RAD tools match real life needs on a scale larger than the simplest applications.

Despite my obvious bias towards C++ and my obvious preference for wxWidgets, anyone will have an hard time convincing me some C++/Qt/wxWidgets/MFC combination can match the development speeds and the features of C# or VB.Net under Windows Forms.

Quote:

---

Originally Posted by pheres

what do you have to think about memory management if you just push your objects into an stl::vector for example any more than say in java?

---

If you're pushing objects, you have to worry about copy semantics. Maybe that's not memory management per se, but it's a language feature that you always have to be concerned about.

C++'s power and versatility are indispensable for application domains you really need it for. For others, however, the language tends to get in the way. Just my $0.02.

You may to worry a bit more about memory when you do real designs such as memory allocators, functors, etc.

"Real" design?

It seems logical also to me that newer language offer better libraries/tools. But I would like to know one language for everything. So, considering that I don't know what my feature job will require, do you think I should go for C++ or something newer, like C# or Java?

What do companies prefer for you to know. Which language is better on what field?

Quote:

---

Originally Posted by C_ntua

But I would like to know one language for everything.

---

Why on earth would you want that? If you only know how to use a hammer, as they say, everything begins to look like a nail. Pick the right tool for the job.

Quote:

---

Originally Posted by medievalelks

"Real" design?

---

You know, all those little C++ stuff that allows you to do generic programming. Advanced stuff.
Using vectors is easy stuff.
Things as such are in Modern C++ Design. Complex code that's perfect for generics.

Quote:

---

But I would like to know one language for everything. So, considering that I don't know what my feature job will require, do you think I should go for C++ or something newer, like C# or Java?

---

If you will be in an English speaking environment, then English would be a good choice, since being able to express yourself clearly in a discussion is very useful, regardless of what programming language your future job will require.

Honestly, what's stopping you from learning C++, C# and Java? And Common Lisp? And Haskell? And Prolog? Why must your choice be limited to exactly one of them? You can always start with one, then when you are reasonably proficient in your first choice, go on to your second choice. You will develop general programming skills along the way, and that will serve you better in the long run than any one language.

And yes, I mean it when I say that English is a good choice. Likewise, having some understanding of say, UML, design patterns, software development methodology, etc, will all come in handy at some point. Oh, and of course, algorithms and data structures, which you may already have some grounding in. Programming is not all about programming languages, after all.

Quote:

---

Despite my obvious bias towards C++ and my obvious preference for wxWidgets, anyone will have an hard time convincing me some C++/Qt/wxWidgets/MFC combination can match the development speeds and the features of C# or VB.Net under Windows Forms.

---

I'm sorry I have to completely disagree on this one having used both at work and home. I have not use wxWidgets but the continual mentions of it is making me a bit curious. Personally my development time with C# and with MFC are about equal. In the end the most time is spent on getting the controls to do what you want. The actual placement of controls and addition of the controls into code takes about the exact amount of time in both.

MFC is extremely easy and gets a bad rep for the MDI horrors and document/view architecture. Usually this is the fault of the programmer because MFC forces you to use OOP concepts when using doc/view and quite honestly most programmers try to break that at every turn in an MFC app. I will not say that MFC is easier than C# because MFC, in my opinion, is a bit lacking in controls. This is more the fault of the Win32 API than MFC but it is true that .NET offers far more when it comes to complete controls. .NET concentrated on making their controls complete and workable while Win32 concentrated on ...well...I dunno what they concentrated on but it was not the controls.

C# is also extremely easy. There is one thing about C# that bugs me to death. The fact that everything is a message which means that calling certain functions for the control may lead to some very unexpected results. This means I had to make use of the user defined data quite often in a control to ensure my control acted as it should. MFC does not suffer from this problem.
C# now has some very nice generics (in later version of .NET) but the early container types were a bit ugly.

I'm a fan of both of these but they both have their downfalls. However a blanket statement saying that GUI in C++ with MFC is much harder than C# is simply not true. Most people who say that rarely use MFC and the less you use something the more you forget which inevitably makes it harder to use. MFC is not hard and is extremely easy to use for dialog-based apps which most GUI apps fall into. C# is not hard and is extremely easy to use for dialog-based apps. However, both get a little more involved if you want to create something robust like an SDI or MDI application.

As always development time is proportional to the programmer's experience in that language or API. If you have a programmer who is familiar with both MFC and C# choosing which one to use usually comes down to what the company has been using thus far in their tools. The only route I would never take is to use pure Win32 since it is just ugly.

If we are going to compare languages, as we so often do here, let's compare them on how well they do what they were designed to do. C++ was not designed to create GUIs so using that as a measuring stick of it's usefulness is unfair.

Moved to GD board.

Quote:

---

Originally Posted by medievalelks

If you're pushing objects, you have to worry about copy semantics. Maybe that's not memory management per se, but it's a language feature that you always have to be concerned about.

---

And in java for example you have not to care about semantics? how is that possible?

I didn't mean to put MFC in there, really. Only reason I did was because I reasoned since .Net Framework is meant to replace MFC, new more improved features would be present. But on second thought, that alone still doesn't make it; I must remember at all times when discussing anything to do with MFC, my experience with it was entirely with a different programming language.

I will however stick to my arguments on the issue of 3rd party GUI libraries the likes of Qt and wxWidgets that despite being excellent alternatives to MFC, by no means their own tools can match MFC based RAD tools, and necessarily Windows Forms (or WPF, the one technology that could bring back my interest in post-Vista windows development). Libraries like Qt or wxWidgets are simply not RAD friendly... so far.

Quote:

---

Originally Posted by Mario F.

Libraries like Qt or wxWidgets are simply not RAD friendly... so far.

---

Could you elaborate a bit more what you mean?
For example I run the gui designer, place all windows, dialogs and controls I need and save. Then I run the code editor and connect my backend functionality to signals/events and controls.

How exactly can this be improved by C# (in which I've no experience)?

Forms are a hideous way to design a GUI. Fair enough it may be a little faster if youre doing something simple, but you cant dynamically change the content and they generally tend to lock you out of the code. Blegh. Once you know the API laying out content is not going to be much harder than laying out a webpage, unless the API sucks.

Quote:

---

Originally Posted by pheres

Could you elaborate a bit more what you mean?

---

Certainly. Although I though I already did.

These tools have several problems, mainly to do with the fact they run by basically applying generic code to your design choices.

I run a GUI layout and place my controls for either resizeable or fixed windows. Then I'm forced to alter the generated code. Because of several reasons:

- It doesn't conform to my code practices.
- Those variable names that are automatically generated are never acceptable names.
- Many times, after adding, deleting, and moving controls on the designer, you are left with code artifacts that need to be removed.
- Code is generic. Consequently is often not acceptable in the presence of performance requirements or in the interest of code maintenance. You need to trim and rearrange the code.
- Control indexing system is offered in several forms. wxWidgets, of the top of my head, offers 4 different ways to index your controls. However, the best option is usually a combination of 2 of them or your own personal and entirely customized system. As you know, this is an essential feature since you are going to address those controls often in your code. Either you adapt to what the GUI designer offers you, or you are forced to also here alter the code.
- Code is tied to the designer one way. This is essentially a code generator and parser with little to no heuristics coded in. If you alter the code, the designer can no longer understand it.

If you wish I can further that list, but it will probably become a boring read.

Quote:

---

Originally Posted by pheres

For example I run the gui designer, place all windows, dialogs and controls I need and save. Then I run the code editor and connect my backend functionality to signals/events and controls.

---

I don't know exactly what kind of applications you have been developing on Qt (I believe that's the one you use, right? I use wxWidgets. But have already studied Qt - which I must say also liked). But pheres, that is simply not true for anything other than simple applications. Heck! Even on most cases adding your application functionality to the generated code is enough to break the designer.

I quickly learned, when I started learning GUI development with these libraries, that their GUI designers are excellent choices for quick window layout. This is after all, a boring and error prone task to be done in code only. But that's that. While I fully support these libraries for their unquestionable worth (free, powerful, portable), I cannot defend their RAD capabilities.

Quote:

---

Originally Posted by pheres

And in java for example you have not to care about semantics? how is that possible?

---

How is it possible that I've never written a copy constructor in Java (or Python or C#)?

i think I see there our differences in usage experiences come from, so your extended elaborations was not useless :)
it seems you expect some form of round trip engineering capability from your gui design tools (work on gui->work on code->continue to work on gui).
Do you really need that? Can't you just completely seperate the gui from the logic, I think the wxw XRC system should be able to do what, doesn't it? Then you should be able to edit the gui continuousely. And I'm pretty shure most of the editors allow to edit the names of the controls.

Quote:

---

Originally Posted by medievalelks

How is it possible that I've never written a copy constructor in Java (or Python or C#)?

---

I've no idea. Somehow must the semantics be selected. if not by the programmer, than by the language?

Quote:

---

Originally Posted by pheres

it seems you expect some form of round trip engineering capability from your gui design tools (work on gui->work on code->continue to work on gui).
Do you really need that?

---

Absolutely. Especially because being a one man's job (and a poor man's job at that) I cannot afford for extensive analysis that would allow me to develop in one go without having to go back (not that I even think that is possible). On the other hand, application maintenance, by definition, forces you to go back and often need to change the screen layout either to introduce new features or to answer user requests.

Quote:

---

Originally Posted by pheres

Can't you just completely seperate the gui from the logic, I think the wxw XRC system should be able to do what, doesn't it?

---

Well, we are talking of GUI logic here. Not application logic. I work by separating application logic from presentation, certainly. What I cannot do however is separate presentation logic from err,... presentation.

If the tool ties its functionality to the code and can't parse outside it's limited set of rules, that tool cannot help me past the initial stages of development.

Quote:

---

Originally Posted by pheres

I've no idea. Somehow must the semantics be selected. if not by the programmer, than by the language?

---

Well, that's the whole point, isn't it? If I don't need the speed and flexibility of C++, I'd largely prefer to use a language that makes those decisions for me.

But you don't need to define a copy constructor in C++ unless you do something different.
Smart pointers gets rid of the whole copy problem with classes.
In Java you wouldn't need to worry about memory at all due to the GC, but with smart pointers in C++, it's the same.

Quote:

---

Originally Posted by Elysia

But you don't need to define a copy constructor in C++ unless you do something different.
Smart pointers gets rid of the whole copy problem with classes.
In Java you wouldn't need to worry about memory at all due to the GC, but with smart pointers in C++, it's the same.

---

You've defined my C++ M.O. almost to a T, Elysia :-). In fact, I usually deny copy and assignment through boost::noncopyable by default, and use smart pointers or if raw, RAII. Like I said, it's not really hard, it's just more verbose that I like to be anymore.

Hey, I'm getting old. I cherish time that would otherwise be spent in traffic, in line at the supermarket, or managing memory. :-)

Maybe I should use a C++ GC and stop complaining so much.

I think smart pointers have been left out of C++ for a far too long time. It's not even included in the current C++ standard (well, auto_ptr is).
Some techniques such a high-level programming is just becoming possible with all the new tools we're getting available right now.
It may be a lot of work to make a generic design, but it's pretty high level.

Oh, and to GC :|
I hate those things. They disgust me. Thankfully C++ doesn't have one (by default)...

Quote:

---

Originally Posted by medievalelks

Maybe I should use a C++ GC and stop complaining so much.

---

Well, C++ wasn't really designed for garbage collection and under most circumstances you will probably have to face more problems than you should need. The major problem being finalizers taking hold of your class; Your destructors will get called only when the object is finally destroyed (and that is when the garbage collector sees fit, not when you tell it to).

I think there are ways around this... but they too come at an expense. In the end however, for the vast majority of applications manual memory management is the way to go under C++. You'll retain the deterministic nature of destructors, an essential aspect of the language.

Quote:

---

Originally Posted by medievalelks

Well, that's the whole point, isn't it? If I don't need the speed and flexibility of C++, I'd largely prefer to use a language that makes those decisions for me.

---

How can you do deep copys in that languages?

clone?

Clone shallow-copies by default. You must override it to achieve deep-copying.