|
This is bad part of the IL...
As you should know, .net isn't compiled.
If you don't want to take advantage of that (like reflection for example) you can compile it directly to native code using ngen.exe
It will perform faster at first start.
|
|
|
|
|
Gary, I think you're wasting time arguing with someone who don't know what he's talking about. When he says C++ is dead, you could know what is all that he knows. May be someone should tell him that all the device drivers, all the high-performance graphic programs, all the high-performance games, all the high-performance embedded programs, linux, windows, etc., are written on C and C++. I would say he shares his IQ with sea cucumbers.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
Rajesh R Subramanian wrote: I would say he shares his IQ with sea cucumbers.
Gentlemen, No fighting in the war room! The Sea Cucumbers are innocent. Leave them out of this.
codito ergo sum
|
|
|
|
|
Gary Wheeler wrote: It's not a myth. Every .NET application I've ever used had an abysmally long startup time. Even "Hello world!" takes forever to start.
Bah! It's your expectations that are the issue here; don't go and blame .NET because you're one of those types that think software shouldn't be slow. 
|
|
|
|
|
<humble><eyes_downcast>
I'm sorry, sir. I'll drink the Kool-Aid™ this time.
</eyes_downcast></humble>
Software Zen: delete this;
|
|
|
|
|
|
AlexCode wrote: and C++ on development process time (cost).
not necessarily, this too is a myth. Much of what you can do in C#, you can also do in C++ in equivalent development speed. The difference is that MS has shifted focus, though they are shifting back. MFC was pushed out in favor of C# and dot net, leaving Qt and others in the real-time rapid C++ UI (even a product called "Ultimate" which based on C++ outperforms UI development under C# and Qt). Basically there is choice, and it is not "old technology" either with new capabilities having existed in Boost in preparation for the latest version of C++, and that latest version coming out later this year or early next, with some capabilities even C# dreams of, MS is considering bringing back MFC in a newer generation capable of accessing the latest, and greatest C++.
There are a lot of myths abounding, C++ never died, and C# is only faster in some areas, and even there, it depends on whos product for C++ you are comparing to.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
"C# is only faster in some areas"
I don't think C# is faster that C++ in any area.
I just know that:
you take longer to develop the same thing in C++ than in C#.
You find cheaper C# resources (developers) for a project that C++ resources.
You have better tools to work on C# than in C++ (like the IDE).
You find cheaper 3rd party controls/tools to use on your products.
These aspects boost productivity, and my main concerns are based on the products.
Ship them as fast, cheap and good as possible.
I also want a program to be easily maintained and I don't want my products to depend on a small C++ guru dev team where it would be hard if any of them left.
This is where .net takes place.
If I make it the way that the customer likes, it will be made in C#.
|
|
|
|
|
AlexCode wrote: you take longer to develop the same thing in C++ than in C#.
No, *you* take longer. I am more productive with C++ 
AlexCode wrote: You find cheaper C# resources (developers) for a project that C++ resources.
True, if that is what you are looking for. The only problem is: you get what you pay for.
|
|
|
|
|
"you get what you pay for"
You have to know what you need... and 2 dev on the same level of knowledge the C# one is cheaper than the C++ dev.
And btw, you get what you design, plan and manage for, not what you pay for.
The problem is that:
1. Designers usually don't do code
2. Teams are allowed to put their imagination on their fingers
3. The development process is poorly conducted (if at all)
You have to choose your team by their qualities and team work, not by their price.
Cheers.
|
|
|
|
|
AlexCode wrote: Designers usually don't do code
no, junior programmers don't design, but junior programmers have been renamed as full programmers under the new "anyone can program with almost no knowlege because C# can turn baboons into expert programmers new way of viewing the world"... except that then you have no baboons typing out the works of shakespear and a lot of code that looks like it was designed by a baboon. So the company at the failing abilities of their programmers call in a designer who is really just a graduated baboon who thinks he knows how shakespear originally typed out the manuscripts by throwing darts while drinking ale, tells the other programmers what to do, they do it, and do it as poorly as it was designed, and the result is still what you pay for.
A good programmer does design code and write it.
AlexCode wrote: Teams are allowed to put their imagination on their fingers
again an issue of inexperienced code-warriors or overly opinionated code-warriors. You have "teams" and you have groups of cowboy programmers working in the same house. A team helps the team and keeps the design to spec.
AlexCode wrote: The development process is poorly conducted (if at all)
again from the view that C++ programmers who are experienced and know how to do things in all aspects of computer development from design to functional capability are outdated and unnecessary, you get what you pay for. If you actually had someone who knew how to program in all aspects of the development cycle, this wouldn't be a problem... but oh yeah, this kind of knowledge and ability is outdated and unnecessary and C# can fix it all like magic with a bunch of programmers right out of school... 
myths hurt everyone even you. You are hurt by the myth that this level of experience and knowledge is no longer necessary, and yet you suffer the effects of loosing that ability. You aren't really at fault because this is a myth that has spread to management and managment now controls some of those aspects, but the myth is still spread and repeated often, that you don't have to be an expert to program C#. With minimal design, with minimal experience, anyone can throw together something that "works". And then the complaints come out that the development process is poorly conducted, because someone actually believes the myth is true, and we all suffer. But maybe that means that people should perpetuate the myth.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
El Corazon wrote: A good programmer does design code and write it.
Sure... but how many of those a project can handle?
How many C++ Juniors do you find on the market? And how good are thy? No one starts programming on C++ these days... college doesn't teach it anymore (in most cases) and if they do it's just to do the standard compiler project and that's it... How good is this for the real world?
El Corazon wrote: A team helps the team and keeps the design to spec.
Sure... but again... why do I need 10 top notch developers on my team?
El Corazon wrote: If you actually had someone who knew how to program in all aspects of the development cycle, this wouldn't be a problem... but oh yeah, this kind of knowledge and ability is outdated and unnecessary and C# can fix it all like magic with a bunch of programmers right out of school...
This is not a language issue... there are bad developers everywhere.
I know very good VB programmers, and VB is widely considered (by mistake) a noobs language.
El Corazon wrote: You are hurt by the myth that this level of experience and knowledge is no longer necessary
I like and certainly need the level of expertise you keep mentioning but it has nothing to do with C++. Like I said, there's good and bad everywhere.
The knowledge is fundamental... you wouldn't loose your knowledge if you were to develop an application in C# would you?
I think you got my point worng from the start...
I never said C++ was better or worst than anything. I just said that each have their place.
I know several languages, technologies, DB engines, etc... and choose the one to use on each project depending on the demands, not based on which I like best on myths.
Also... I don't go following hypes...
I tend to use only proven technologies and languages.
I also try to use the environment that will let me earn more money keeping the customers specs and happiness...
Designing and Managing with direct impact on revenues is way more complex than a language fight.
|
|
|
|
|
AlexCode wrote: you wouldn't loose your knowledge if you were to develop an application in C# would you?
no, in fact I program in it, for specific reasons. I do not see one technology as having replaced the other. Each has their time and place. Many people have not expressed this idea, and the result is a world with fewer and fewer experienced programmers because the goal was to make a language easier where training was not required.
C++ and C have actually rarely been taught in school. Long before the advent of C# there were many a school language. Ada, Pascal, Algol, and others. In the 80's it was Pascal. Now it is C# and Java. I see no reason this should ever have affected C++, nor should it, it didn't then, it still does not. Schools have never been designed to make employees, they were designed to make graduates, there is a big difference. Those who can, do, those who can't, teach. It has been more truth than myth for as long as colleges have existed, well over 100 years now, and shows no desire to change. Every business who knows business knows they must retrain their graduates, anyone who doesn't suffers. Now we suffer. C# is strong, and I use it, but many people have advertised it as having replaced C++ and we all suffer for that myth.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
After all we have been discussing the same idea.
C# doesn't replace C++ and neither the other way around.
They overlap in most cases, so the next criterias are:
- which is cheaper?
- which have more resources available on the market for me to choose from?
This is my point...
We can argue about the technologies but it all ends up about the end-user result and, of course, the money
Cheers!
|
|
|
|
|
AlexCode wrote: which is cheaper?
neither, either, both, depends on your person. There is no definitive answer in all situations, or really in any situation.
AlexCode wrote: which have more resources available on the market for me to choose from?
C++, they are simply ignored by everyone in the C# world.
AlexCode wrote: but it all ends up about the end-user result and, of course, the money
Then you need to forget C# and go Ultimate, you'll save a ton. C# is designed for managed abilities, it does not always get you RAD, but it is claimed to do so much to the myth. C++ has all the power, all the speed, all the money savings, IF you want to use it. The fact that C# users have STOPPED allowing themselves to see what still remains in C++ and the latest generation of C++ that continues to move forward in technology and time and capability and RAD. Thus C++ stays in the game.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
 this is being a good chat pal... :p
El Corazon wrote: C++, they are simply ignored by everyone in the C# world.
Almost everyone I know, specially that works for me or with me that have a C++ background prefers to code in C# than in C++.
Same thing about job offers.
For outsourcing's it's way more easy to find .net (managed) projects to work on that either managed or unmanaged C++ projects. This is a fact and we must live with it.
Unless you run a closed environment like a baking system or such, that you can choose whatever you want has the base technology you have to go with the flow... It's not a matter of what's best... it's a matter of what makes the final result easy on the overall aspects of the problem.
|
|
|
|
|
AlexCode wrote: Almost everyone I know, specially that works for me or with me that have a C++ background prefers to code in C# than in C++.
almost everyone I know who programmed in (past tense) C++ and moved to C# has absolutely no knowledge of advances in C++ since they moved to C#, so are usually comparing C# now (as it has advanced through several generations also) which they have followed with C++ they "knew" (past tense) and therefore are not making a valid comparison. True they made the choice, and they are still making the comparison that they are familiar with, but that does not necessarily mean they know enough about C++ (now) following '99 and '03 and the new '08/'09 changes to make a valid comparison, let alone a comparison to 3rd party support (free or otherwise) that benefit the comparison. Therefore it may be true that it is in fact easier for them to program in C#, but that does not in any way reflect that C++ is more difficult than C#, simply that they have left the C++ business and now know more about C#.
both languages are good, and I do use both, regularly now. There are valid distinctions in intent between the two language, and it is pretty obvious why C++ is still around and moving forward in technology based on the differing intent of the two.
AlexCode wrote: It's not a matter of what's best... it's a matter of what makes the final result easy on the overall aspects of the problem.
which is exactly the problem. Too many programmers, and salesmen have sold .Net and C# as a complete replacement of C++ on all fronts. This is a disservice to business in general. And it is pretty obvious why development in general has suffered since. You cannot fit a square peg in a round whole without a lot of knife work and even then the fit will always look forced. And that is a fact that we are in fact living with now.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
El Corazon wrote: Too many programmers, and salesmen have sold .Net and C# as a complete replacement of C++ on all fronts.
I don't know any forced replacement in person, but I believe they have occurred.
Whet I think it happened in most cases was that when old systems were to be updated, many had to be completely replaced for several reasons, not all related to technology but also to enterprise business logic changes.
So, a salesman who has more .net resources than C++ resources available sells what it's company have to offer.
This is no competition between C++ and C#... it's marketing!
Most upgrades were also made from Windows Apps to Web Apps, and ASP.net with C# is a very good option.
|
|
|
|
|
AlexCode wrote: For outsourcing's it's way more easy to find .net (managed) projects to work on that either managed or unmanaged C++ projects. This is a fact and we must live with it.
That is true as well. At my previous job, the only programming positions in the U.S. were for C++ development. All .NET work was performed in India and Ireland.
|
|
|
|
|
Why .net outsourcing?
Simply because it's cheap and delivers exactly what it's expected, nothing more or less...
That's the Microsoft flag when "selling" the C# language.
|
|
|
|
|
AlexCode wrote: They overlap in most cases
They don't. C# is an "enterprise" language and overlaps with languages like Java and VB. C++ is a system language and overlaps with C and Ada. If you have switched from C++ to C# and are happy with it, chances are you were using C++ for a wrong purpose in the first place.
|
|
|
|
|
So... you end up agreeing with me that these are separated languages with its main usage on different scenarios, none of them with any reason to extinction.
I keep thinking that they overlap tho.
There are many things you can do on both languages... in fact most things.
Considering benchmarks, you find that C++ is more performant on I/O operations, so you should use it on heavy loaded I/O systems like ETL for example.
Nemanja Trifunovic wrote: you were using C++ for a wrong purpose in the first place
I don't think so... I just don't use it for everything like I understand you are trying to state.
And with the evolution of the languages and computers I keep needing it less.
|
|
|
|
|
AlexCode wrote: you take longer to develop the same thing in C++ than in C#.
no, I can develop a C++ GUI with database query in a fraction of the code and time using Ultimate++ in C++, it only depends on what you believe. YOU believe what you have heard, and refuse to believe anything else, therefore it is true as long as you never accept anything other than what you already believe. The tools are out there to do a lot of things in C++ that C# can do, the only thing C++ doesn't do well is compile on the fly and interpreted language slowdowns. But then some C++ programmers can do that, but then some C# programmers can too.
There really are a lot of myths around from those who want C# to disappear, and those who want C++ to disappear. I don't consider either going to do so. C++ has a purpose and that purpose is different than that of C#, the two languages overlap enough that it seems one could have been a replacement of the other, but I do not believe so. You will always have instances of native EXE/DLL use, even if only for the benefit of providing a native DLL for C# to use to speed it up, you have access to hardware levels and speed that exceeds C# in capability. C++0x is also offering a few things that only C# and a few other languages had, though boost had some of the abilities, C++0x will make it part of the standard. C# and C++ are still growing. C# took a portion of the C++ market for specific tasks for which it was specifically designed, and in that it shines. but that does not necessarily mean that all the myths about C# or C++ are true.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
Hey, thanks for Ultimate++: hadn't heard of it before, and those code comparisons show promise for its claim of RAD. So far, I've had to separate logic and presentation, so I can prototype GUI's in an app that's good at it, then use a tool to generate equivalent source code for it in another framework, like wxWidgets, which has excellent features and portability. Now, perhaps, I can just use one tool for all the work. Thanks, again!
|
|
|
|
|
NimitySSJ wrote: Thanks, again!
there are a few bugs I found, though they can be fixed by doing some better code (in other words poor but legal code can crash, better designed code and designed the way they prefer it to be designed works good -- its an "all possible error control areas have not been covered type thing".
and I use it for GNU, and several MS compilers and even same code between them.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
