|
Tell us, what language was used for making C++? Tell us, what language was used to write assembly? Hmmm...
I don't think that the lowest-level language is necessarily always the best language for the job. Sometimes we have to sacrifice a little speed (and it is only a little) for numerous other benefits - security, the excellent type system, etc.
|
|
|
|
|
Security? Do you really believe that?
What about the numerous benefits in using C++... I'm not willing to sacrifice those… give me a list of benefits of using C# and .NET and I will give you a list of problems with this framework and advantages of C++ without .NET.
Oh and if you try to reason with arguments like garbage collection then you will make me write a hole article 
|
|
|
|
|
|
Not only can C/C++ make use of a garbage collector or not, but it can use diferent collection management schemes!!!
I never said garbage collection was not a worthwhile thing to have, but you should have control of when and where it should be used in your code.
Miguel Hasse
|
|
|
|
|
Miguel Hasse de Oliveira wrote:
Not only can C/C++ make use of a garbage collector or not, but it can use diferent collection management schemes!!!
But ultimately, you have to settle on a single memory management model. If you're really worrying about which one, then you've got bigger design problems....
Miguel Hasse de Oliveira wrote:
I never said garbage collection was not a worthwhile thing to have, but you should have control of when and where it should be used in your code.
Which misses the point of garbage collection. You shouldn't control it, because the chances are it has a better idea of when to do things than you do, 99% of the time. You either adopt garbage collection and let it get on with it (saving you time and development costs), or you do it yourself, and spend 30% longer on your app avoiding memory corruption and memory leaks.
Doing it yourself doesn't even guarantee a better use of memory than garbage collection, because you usually have to put in your own reference counting schemes and smart pointer management code and so forth, and if you're using custom allocators, you have to store all that info too (which is normally punted off to new/malloc/whatever). Then you have write code to avoid memory fragmentation issues too (which we've encountered here in C++ apps, but never C# ones).
Ian Darling
The world is a thing of utter inordinate complexity ... that such complexity can arise ... out of such simplicity ... is the most fabulous extraordinary idea ... once you get some kind of inkling of how that might have happened - it's just wonderful ... the opportunity to spend 70 or 80 years of your life in such a universe is time well spent as far as I am concerned - Douglas Adams
|
|
|
|
|
Miguel Hasse de Oliveira wrote:
but, how many large or small commercial software has been developed using VB?
I'd say a hell of a lot. Lots of internal apps within businesses are written in RAD tools like VB because you can get applications that meet the requirements of the business done really quickly - and any inefficiency trade off that results is usually acceptable. A lot of ASP sites will be written with VB as the scripting language, too.
Given VB programming is an order of magnitude more productive than C++ for your general "grab some data and process it" apps (the sort of thing COBOL was popular for a few decades ago), businesses will (and do) adopt it because it's just plain cheaper to meet your aims!
Code "efficiency" is a terrible metric to use much of the time, because a lot of software has business requirements of some sort, and meeting those quickly is more important than a VB app being a couple of seconds slower than the equivalent C++ one. You might also note that VC++6 and VB6 used the same compiler backends, so speed criticisms may not even apply that much.
I used to be a C++-is-the-best-and-only-tool-to-use guy one time. But not anymore. Ever heard the aphorism "when all you have is a hammer, everything looks like a nail?". C++ is a good hammer, but you need more tools than that.
A good developer will know several tools, and know when it's appropriate to use them. C# is an excellent tool for much general application development because for many things it's easily fast enough, it has less headaches than C++ does, yet it's sufficiently familiar in style that it's easy to pick up. It (like C++) can interop with other components/languages through P-Invoke - and the ability to "break-out" of the language is one thing that helps makes a useful tool. This is why also VB is popular and useful too - you can use C and COM based libraries.
Oh, and a lot of the .NET libraries are written in C#.
Ian Darling
The world is a thing of utter inordinate complexity ... that such complexity can arise ... out of such simplicity ... is the most fabulous extraordinary idea ... once you get some kind of inkling of how that might have happened - it's just wonderful ... the opportunity to spend 70 or 80 years of your life in such a universe is time well spent as far as I am concerned - Douglas Adams
|
|
|
|
|
I would say most RAD implemented solutions are for internal business use! And in most cases this makes total sense...
...but I was referring to boxed off-the-shelf products, mainstream products like Office, Photoshop, CorelDraw, SolidWorks, AutoCAD and millions of others
A developer that uses to many tools will never use the full power of any!
Oh, and have of compared .NET libraries written in C# with ActiveX libraries written with C++?
Miguel Hasse
|
|
|
|
|
Miguel Hasse de Oliveira wrote:
...but I was referring to boxed off-the-shelf products, mainstream products like Office, Photoshop, CorelDraw, SolidWorks, AutoCAD and millions of others
All of which have been around for years and would therefore obviously have been written in C or C++ - you don't just throw away that level of work just so you can use recent tools. But as I mentioned in my other post, there are starting to be mainstream applications written in .NET such as Newsgator. You may not get a nice box in the shops for it, but it is the same sort of mainstream application. And I think you'll start to see more of them. Office will likely gain a managed codebase of some sort over the next few years.
Miguel Hasse de Oliveira wrote:
A developer that uses to many tools will never use the full power of any!
You really misunderstand my point. A developer uses the tools that help him get the job done in an appropriate way - and this will usually involve more than one tool. Tools have different benefits - C# and VB make good general application development languages because they're powerful enough for most purposes and can be used with other tools too. C++ is good for low-level work like drivers and some server platforms, but is also extremely complicated and unwieldy (Stroustrup even admits that there's a smaller language fighting to get out of C++). Java is good when you need to develop cross-platform. SQL makes a great query language. Python makes a great glue language (and is frequently used in conjunction with C++).
Knowing multiple tools well makes me a better developer, because I can see where one tool is better for something than another.
Of course if you just throw everything together in one pot you will get a mess, but that isn't my point! Relying on just one tool (doesn't matter what) means you waste a lot of time on things you shouldn't need to. This is why any significantly large project will frequently use two or more tools.
Miguel Hasse de Oliveira wrote:
Oh, and have of compared .NET libraries written in C# with ActiveX libraries written with C++?
Yes - I've written libraries using both (being a developer who knows multiple tools). So far, no significant differences in efficiency, and the .NET ones are generally less problematic to develop and deploy (particularly on the mobile and web platforms I work with most often).
There's only one control I've seen that would be tricky to do well in .NET - a mobile device control for signatures - and half of that was due to the smaller platform library missing a API needed for drwaing the lines the right way. But I've written owner-drawn multi-line, grouping list controls for mobile devices in both C++ and C#, and the C# one was as fast, and easier to maintain and deploy. If a mobile device can manage .NET, and web applications can, then the desktop will too.
Ian Darling
The world is a thing of utter inordinate complexity ... that such complexity can arise ... out of such simplicity ... is the most fabulous extraordinary idea ... once you get some kind of inkling of how that might have happened - it's just wonderful ... the opportunity to spend 70 or 80 years of your life in such a universe is time well spent as far as I am concerned - Douglas Adams
|
|
|
|
|
At least Flash Player will never be written in C#, as it needs to be efficient. Also, memory managment in .NET sucks, so important programs like a program that controls a production plant and is required to work for a year without restart, will never be written in any interpreted language like C#.
Tell me, what kind of programs do you write??? It seems they all are small and a bit futil... there are thousand of situations besides games where C# wont be used!!
|
|
|
|
|
Sure, buy a faster machine to get .NET programs running almost as fast as C++ compiled applications on slower machines... oh, and don't forget to double that RAM (because that managed code is hungry).
Imagine that MS ever came around to rewriting Word 2003 in C#, what kind of machine would we be talking about here? (of course this is strictly hypothetical)
Do you really thing getting more powerful machines so you can do as much and as smoothly as do now is positive evolution?
Miguel Hasse
|
|
|
|
|
|
Are you certain you've tried to run .NET applications... I have two main work machines a 2.6Ghz with 1GB RAM and a 2.8Ghz with 512Mb... Small .NET applications don't run only these machines they walk and eat RAM.
MIguel HAsse
|
|
|
|
|
|
MicroSoft is trying to slow down the speed of PCs with their newer OSs developed by new languages. It reminds me in the old Dos days, 80386 PCs with dos platform and 640kb ram or several MGs runs dos program much faster than 686 with Win9x, Win2000/XP with 256/512 MG Rams.
I by chance have had the opportunity to support such a program with customers using OS from Dos to WinXP. The program gets slower and slower with faster and faster PC, newer and newer platform. I didn't and I don't want to complain about M$ which gives me opp to earn my bread on table. In fact M$ has created alot of working opportunities for millions people, eg. VB, VC and now it is C#. I will put my hands on C# some days in the future just in case it disappears too soon.
Just a kidding;P, don't take it too serious .
Regards,
Ke
|
|
|
|
|
Alvaro Mendez wrote:
But if you're so concerned about execution speed, by all means write your programs in Assembly. I hear it's super duper fast.
Only if you are very, VERY good in assembly programming, which I am not. Modern C++ compilers are damn good these days, and I don't think I would be able to write any non-trivial application in assembly that would outperform the same application I would write in C or C++.
However, I agree that this argument about "slow C# vs fast C++" is 
|
|
|
|
|
I think the real problem with using is that it is only truly helpful in situations where object lifetime is extremely simple. This method of resource cleanup falls apart when a resource is used more than once ( i.e. we maintain a reference to this resource for later use ). The object that holds a reference to an IDisposable can itself implement IDisposable but this also assumes that this object has simple lifetime patterns. And what about resources whose lifetimes don't match those of their owner? What about collections? Do they know anything about IDisposable? Do I need to keep track of everything I throw into a collection and never reference again? How would I even know when to reclaim those resources that are just sitting around, cached, waiting to be used again? I know there are ways around these problems but all of those solutions highlight the inherent disconnect between the purely managed world ( where the CLR manages everything for us ) and the world where I have to keep track of the lifetimes of my objects in very detailed ways. Coming from the C++ world where this is all explicit makes the problem here seem like a flaw of architecture, but I think that the real problem is that C++ programmers are lazy ( I'm not excluding myself from this ). Scoped resource reclamation is no longer possible and we have to actually think about disposing of our resources instead of allowing the compiler to handle it for us. It took me a while to figure out why I am a little uneasy with .Net, but it turns out that it has everything to do with managing details I've never had to manage before. I know that I had to call delete or free or RegCloseKey before but that was all right because the entire language is structured that way and its fairly easy to see where you are not releasing resources, but in the CLR, where the world is very dynamic and where I never have to think about reclamation, IDisposable and using look like hacks elevated to the level of infrastructure. Well, maybe its not quite that bad
-Lonnie
|
|
|
|
|
|
It allows me greater productivity, then c++ ever. Some projects show even 50% decrease in lines of code.
Sorry, I am not a student to code for fun, I code for money (mostly at least) so les code -> more money
|
|
|
|
|
Never a true word my friend, I couldn't of put it any better.
|
|
|
|
|
In school I worked on an application. This application was implemented in C#. The .NET nightmare started after a few days when I discovered that I couldn't use the pre-processor.
Short after that discovery, I figured that everything I love C++ for is gone in C#. Beside that, All the things I hate Java for should be the power of C#.
I guess that I enjoy freedom and small/fast apps rather than rapid development and dirty programming.
My opinion on .NET/repid development is:
A rapid developer is a bad developer.
Now that the project is done, I stick to C++.
A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.
|
|
|
|
|
Bob Stanneveld wrote:
A rapid developer is a bad developer.
I don't know about that. IMO, that a rapid developer is either a "bad" developer, or a really good developer.
Aaron Eldreth
TheCollective4.com
My Articles
While much is too strange to be believed,
Nothing is too strange to have happened.
- T. Hardy
|
|
|
|
|
Development comes with fast fevelopment time, huge distributables and slow programs.
I prefer small and efficient programs. If this comes with more development time, so be it. My name stands for quality instead of quantity..
A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.
|
|
|
|
|
Programs written in C# can be small and efficient, and in many cases, every bit as fast as an equivalent C++ program, but with fewer security risks and fewer bugs and memory leaks.
You have a point about the distributable size, but the advantages of .NET, and C# in particular, far outweigh this minor issue.
My guess is that you never really gave C# the chance that it deserved. You can't code in C# in the same way that you would in C++. It's something new you have learn and get used to. Just because the preprocessor in C# won't let you do what you could with C++'s doesn't mean that it is inferior. Instead, there is simply other (usually far more elegant) ways of doing the task.
That said, there are plenty of reasons to stick with C++. It's always a case of what is the best tool for the job. But these days, C# is more and more often turning out to be that best tool.
|
|
|
|
|
Bob Stanneveld wrote:
The .NET nightmare started after a few days when I discovered that I couldn't use the pre-processor.
A good C++ developer shouldn't be using any preprocessor magic anyway. It's not typesafe and in many cases not even portable.
Granted I don't use .NET, but my reasoning is that it doesn't bring anything to the table that would benefit desktop or embedded (as in RTOS VxWorks stuff, not WinCE) development. I've seen very clean elegant C# code from many people here on CP, and for the right job, .NET very well may be the right tool. I guess I don't know what my point is other than to let you know your drivel about .NET wasn't very well substantiated by your empty whining.
~Nitron.
ññòòïðïðB A
start
|
|
|
|
|
Nitron wrote:
A good C++ developer shouldn't be using any preprocessor magic anyway. It's not typesafe and in many cases not even portable.
I don't use all the pre-processor magic, I just use the simple #ifdef and related for building different releases.
IMO this functionality should be available for every language, but this will newver happen even is there's world peace..
A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
