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)...
Originally Posted by Adak
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.
Last edited by Mario F.; 06-28-2008 at 06:58 PM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
How can you do deep copys in that languages?
clone?
Clone shallow-copies by default. You must override it to achieve deep-copying.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
About garbage collection: Imagine a C++ application is your home. Now, you got to choose if you clean it up yourself, or call someone to do it for you, who doesn't know your house so well...
So one needs (sometimes, sometimes not) a kind of function to describe copy semantics exactly as in C++. No score for java/c# (regarding "easier" programming) again?
What hinders you from re-loading the XRC (I guess it's the wxw term) in the editor, add the control, save und connect it to the backand? I don't really get what an automated tool can do any more for the programmer.
Let's get this straight... I never said an automated tool can't do something (although I certainly could). What I'm addressing exclusively is this false notion, in my opinion, that Qt or wxWidgets based development is faster than C# and, now after Bubba's reply, C++ based MFC.
The debate has now evolved a bit and certainly the wxWidgets resource system answers some of the concerns I expressed on the above list... It does this by abstracting the interface entirely from the application, to the point of it not even needing to be part of the binary. It puts traditional windows resource files to shame and makes such features as community based skinning a kids play.
But a XRC file is XML. It's going to be loaded into the application at runtime. This level of abstraction certainly speeds development. But does so at a new cost, one more layer to your application that slows (careful with the size and complexity of your XRC files!) your application and adds one more level of entropy to your code maintenance tasks.
All in all solutions like wxWidgets or Qt ... I'm repeating myself on every post and I'm still apparently being questioned... are in my opinion, the way to go. No MFC, no .Net, no nothin'. But, and this is the last I have to say of this... I'll be damned if you are going to convince me RAD tools like the ones present in a C# or MFC development environment are less suited to the task than any of the current 3rd party library GUI designers.
We will have to agree to disagree.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
I don't want (or even can) contradict you. Therefore I had to learn the MS techniques first. I really wanted to find out if they can beat the C++ environment as often claimed. I'm not convinced so far
Today I played a bit with the XRC system. It seems really great. Having an extra layer of a gui inside a XML file is only one option. It is also possible to create source code for the gui (which should not be edited, to be able to alter it later through the gui editor). Instead one can derive from it and connect the backend to the gui inside the derived code.
In case you are interested, here is a little video tutorial which shows that (including re-editing the gui)
http://wiki.wxformbuilder.org/upload...b_tutorial.avi
How clean does it need to be? Do you need someone to disassemble your appliances, peel back the carpet and padding, remove all light fixtures, etc? Likely not in most cases, which is why a normal "cleaning" would do.
I mean, GC languages aren't theory, they've been around for decades and used in production systems. For some applications they are not suitable, but for the overwhelming majority I'd say they probably are.
That was a pretty poor example, though.
The thing is just that C++ was not designed for garbage collection.
Therefore, it should be avoided.
Hmm... the other way around perhaps?
When was the last time you developed an application that didn't depend on a deterministic destructor somewhere?
Certainly under some circumstances you can work around it... and definitely under some circumstances a GC is more desirable. But which of the two below will you pick first?
- Under most circumstances you will want to use a memory management system for which the programming language wasn't really designed for. (oops?)
- Under most circumstances you will want to use a memory management system for which the programming language was designed for. (Bingo!)
There's nothing wrong with RAII in C++ that justifies taking the twisted road, for the overwhelming majority of cases.
Last edited by Mario F.; 06-29-2008 at 09:00 AM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
The need for deep-copy in a language that passes by reference is the exception, not the rule, at least the way I program. There's generally no need to be copying objects around willy-nilly in a program anyway.
In C++ you have to adhere to convention (pass by ref or ptr instead of value) to obviate the need for copying objects.
This guy disagrees:
http://www.research.att.com/~bs/bs_faq.html
"If you want automatic garbage collection, there are good commercial and public-domain garbage collectors for C++. For applications where garbage collection is suitable, C++ is an excellent garbage collected language with a performance that compares favorably with other garbage collected languages."
All the time. Do you know how much production Java, C#, Perl, Python, Ruby, etc. is running out there?
