Printable View
I would be very interested if you found a tangible benefit for general application development.Quote:
C++/CLI offers some tangible benefits over C#.
For me to consider it tangible it would have to either:
1) Be significantly easier to write and maintain.
2) Be measurably more performant.
3) Provide access to functionallity that is not possible with C#.
Keep me posted [PM's are fine] :wave:
This is a bit off topic, but inspite of the benefits of an RAII approach to thread locking, I find it interesting that many programmers still seem to take the explicit lock/unlock approach where a lock call is made in the try block and the unlock call is made in the finally block. I wonder why this is?
How come the topic of the thread has changed?
Is it possible for just anybody to do that or is it some freaking administrator who's had a mental breakdown? Set it back immediately.
Of course , anyone can post anything on any topic on any thread.
Are you suprised??? :confused:
I'm not complaining. I'm trying to compare the pros and cons of C# and C++/CLI.Quote:
Originally Posted by cjard
And I actually was negative towards Java in my post #102. Have a look. It was a reply to you.
I wouldn't call it snobbery. In a sense complexity equals freedom. It gives you many options and I like that.Quote:
So, there's an element of snobbery here? If you could do the job in either C# or C++, you'd choose C++ because it's more "elite" and your programming peers are less likely to be "uneducated/inexperienced"?
Not at all :) I meant the name of the thread has changed. I called it "Why C#". Now it's something else. Who ever changed it, change it back!Quote:
Originally Posted by TheCPUWizard
Have you read Scott Meyers' "Effective C++" and "Effective STL books"?Quote:
In a sense complexity equals freedom. It gives you many options and I like that.
If so, then I take it you disagree with his points, and have the ability to back it up.
If not, then I strongly suggest you read them.
I don't know what you consider to be Scott Meyers' points. That's "best practice" books aren't they. What has that to do with what I said about complexity?Quote:
Originally Posted by TheCPUWizard
Yes thet are "Best Practices" for C++ and STL respectively.
One of the key points in the book (which I alluded to earlier), is that choices can often be a BAD thing. If you have one methodology to accomplish a goal, and that methodology provides acceptable results from all aspects, then additional methodologies (especially if they are roughly equivilant) serve no purpose, and typically cause a decrease in productivity and maintainability of the resultant code.
To me this is in direct opposition to your previous statements on the "benefits" of C++. So I was wondering if you had some authoritive input to refute one of the most respected authors in this arena.....
Again, who the heck changed the name of my thread?
That's your interpretation of something you read. What was it you read actually? Can you refer to the actual statement where the author is against choises? If nothing else it allows him to sell his books on how to best navigate the complexities of C++.Quote:
Originally Posted by TheCPUWizard
I can recommend an even better "best practicies" book where the authors don't claim choise is bad. It's C++ Coding Standards by Sutter/Alexandrescu.
I don't need an authoritative source to tell me whether I like to have options. I just like it. I think it's fun. This is in no way in opposition to the importance of codified experience and guidance. I like that too.Quote:
To me this is in direct opposition to your previous statements on the "benefits" of C++. So I was wondering if you had some authoritive input to refute one of the most respected authors in this arena.....
On a more philosophical note most people agree choise is good. In fact you're the first one I've met in a long time who seems to think you've have found evidence to the contrary.
Admin, can this thread title be changed to "Why [did you choose] C# and other assorted rantings?"
Ok, I'll bite.Quote:
Originally Posted by TheCPUWizard
:)
1) Real template classes in pure managed code.
2) Implementing IDispose is simpler in C++/CLI because the compiler adds a lot of boilerplate code for you automatically (and correctly!).
But as I've said, these benefits are outweighed by far bigger benefits found in C#.
I agree true templates are much more powerful than generics. However when you combine generics with reflection and dynamic code generation, I have yet to find an actual scenario where I was not able to accomplish the goal with readable, maintainable code that was less performant (when measured at the application level). [i]Do you have a concrete sample?[/b]Quote:
1) Real template classes in pure managed code.
Yes it does add boilerplate, and that can be a little helpful. However, the biggest problem with IDisposable, is that it is be definition illegal to access an objects method after it has been disposed. Yet very few programmers (in any language) actually put the check inside of every method and property like they are supposed to. As an FYI: with "code snippets", adding the boilerplate to C# is literally 3 key strokes. Hard to be able to measure the impact of three keystrokes per class that implements IDisposable as a percentage of total development. Do you have any metrics that would indicate otherwise?Quote:
2) Implementing IDispose is simpler in C++/CLI because the compiler adds a lot of boilerplate code for you automatically (and correctly!).
Templates and generics have different purposes. You cannot accomplish with generics what you can do with templates. Templates are probably the single most important addition to C++ ever.Quote:
Originally Posted by TheCPUWizard
Concrete samples are everywhere. The C++ standard library depends on them. Boost depends on them. Another good example is Modern C++ Design by Alexandrescu presenting a concept called policy based class design. The book has resulted in a C++ library called Loki.