quick question on c++ with respect to c#

Do many of you C++ coders also code with C#? I am completely brand new and am wasting a lot of time trying to decide which route to take, sighs.

I am interested in all sorts of applications for programming skills from simple handy tools to have around the desktop to reverse engineering to device drivers.

As I understand, C++ uses native code and is entirely portable, C# uses the .net framework which makes it hard to code programs that are easily deployable on host machines without the appropriate .net framework installed. Thats not really a worry to me since I will be coding purely for me anway.

I was close to settling on C++ until I read an interesting article comparing the two which suggested that for every 1 line of code in C# you would need to write between 3-5 in C++ to achieve the same task (later learning that this is because of the class modules that C# can make use of).

Whilst my motivation for learning programming is for my desire to learn about computing and everything in it, I know myself think I could get demotivated by not being able to figure out the myriad of problems that unmanaged code presents.

Sorry this is turning into an essay so I will stop clearing my throat.

These are some of my coding goals whichever route I take:

1. automating the web like a web scraper/filler
2. a team-viewer like application
3. being able to extend functionality of existing programs by hooking and creating ad-ons without source code
4. automating the windows invironment like predicting what I am going to do based on my historic behaviour (eg. I go to documents and it learns that I normally next go to downloads so just opens downloads folder, stuff like that).
6. manipulating memory/graphics
7. controling packets and network activity.

And thats about it so far.

Quote:

---

As I understand, C++ uses native code and is entirely portable

---

It turns to almost totally untrue when it comes to using third party libraries, frameworks, components, compiler specific extensions, porting to exotic platforms having no C++ compiler, etc. :D Ultimately you find yourself bound to a couple of frameworks and few platforms only. ;)

Quote:

---

Whilst my motivation for learning programming is for my desire to learn about computing and everything in it

---

...then you avoid making your mind beforehand just to learn this or that language, and start learning one language you prefer right now, being prepared to learn others when required/desired. As you said, "to learn ... everything" you need to learn everything. :)

Quote:

---

an interesting article comparing the two which suggested that for every 1 line of code in C# you would need to write between 3-5 in C++ to achieve the same task

---

You know, even if to admit that partially, ultimately this proves really nothing. The real time consuming effort is design, analysis and debugging, not writing lines of code. And to start writing safe and effective code and do fault proof architecture you need an experience, whatever language(s) you use.

@OP:
:D See? The C++ community (...well, Igor) is telling you more or less the same thing.

For those interested: >>> the twin thread at the C# section >>>

You know, deciding on a language is only the start to building world class applications.

In reality your application needs to interact with the OS and that means using the native api or a framework that wraps the api.

In non-managed world, besides learning the language, in order to be productive, you need to learn the different ways to interact with the OS, such as the special ways to do printing and file system operations.

The bottom line is all this is easier to learn and do in C#.

Quote:

---

See? The C++ community (...well, Igor) is telling you more or less the same thing.

---

Well, glad to be heard as a member of C++ community. :) But just for the record, as well I typically do PHP, HTML, JavaScript, XML, C#, a tiny bit of Java, installers of few flavors, and lots of database programming. So there are lots of programming languages in everyday use. I'm pretty sure all the people on the forum here are not focused exceptionally on C++ too. ;)

Quote:

---

Originally Posted by cheatson

I was close to settling on C++ until I read an interesting article comparing the two which suggested that for every 1 line of code in C# you would need to write between 3-5 in C++ to achieve the same task (later learning that this is because of the class modules that C# can make use of).

---

That's not really true. Syntactically, they're pretty similar languages. The biggest difference is C# requires the .Net library which has a lot of functionality already written. Visual C++ comes with MFC, which while not as extensive as .Net also makes writing Window apps much simpler. How many lines of code you save, if any, writing C# vs C++ depends a lot on what type of apps you're writing, and what class libraries you're using in C++.

For someone just starting out and wanting to write Windows apps and make some money ad it, I'd recommend C#, mainly just because you'll be more productive quicker.

C# consumes more computer resources than C++ does but it offers better GUI effects that are user-friendly added features. C# performance in terms of speed is worse than that of C++, so rarely would complex computation in fields such as AI, neural etc use C# for their applications. Yet, C# is more widely used in web applications.

Quote:

---

Originally Posted by Igor Vartanov

Well, glad to be heard as a member of C++ community. :) But just for the record, as well I typically do PHP, HTML, JavaScript, XML, C#, a tiny bit of Java, installers of few flavors, and lots of database programming. So there are lots of programming languages in everyday use. I'm pretty sure all the people on the forum here are not focused exceptionally on C++ too. ;)

---

Well OK, you're right - my categorization was pretty liberal, anyway, based on dominant forum activity. BTW, I'm under the impression that most native C++ developers active here on the forums (you and Arjay excluded, and maybe someone else who posted here), don't do much coding with C# and .NET in general, and sometimes even have a few misconceptions about them. Maybe I'm wrong.

Quote:

---

Originally Posted by GCDEF

That's not really true. [...] How many lines of code you save, if any, writing C# vs C++ depends a lot on what type of apps you're writing, and what class libraries you're using in C++.

---

I agree - it is neither really true, nor as simple as that statement makes it, nor really relevant. Besides the fact that C# doesn't require the header files, which does make the code a bit shorter (the longer the code, the less significant this is), it really comes down to what APIs you use and how granular they are.

Quote:

---

Originally Posted by Arjay

The bottom line is all this is easier to learn and do in C#.

---

ideally speaking, :)

I'd say it's also a matter of "mindset" with respect to learning new things ... someone happens to be more suited to a working-knowledge oriented attitude, whereas someone else is more comfortable with rigorously defined formal rules and systems;

I'm not saying that languages like C# trade rigour or formal sophistication for intuitiveness or productivity; I claim that if one has a I-want-to-know-exactly-what-I-m-doing mindset then all real world general purpose languages are comparable with respect to formal complexity or learning curve, essentially because they all try to solve the very same problems ... and there's no easy or cost-free way of solving them;

therefore, as long as such minded people are considered, if one has to choose how to invest his/her time and energy it makes more sense investing them in the most flexible language, that is, IMHO, C++ ( simply in the sense that it's hard to imagine something you can do in C# and you cannot do in C++; of course, I'd be glad to be contradicted :) ).

I started working professionally doing C++ work in 1995. Other than a 6 month period (where I temporarily lost my mind), I have always coded for Windows exclusively.

During that time, I have picked up Win32 programming, MFC, COM, ATL and WTL. Also database programming using ODBC (straight Win32), with the MFC CRecordset classes, the ATL OLEDB consumer classes and ADO.

I consider myself an expert in Windows programming using C++. As such, I feel I know what it takes to create professional Windows applications.

If you use C++ to develop Windows applications, it isn't enough to just know the C++ language, you must also be familiar with a variety libraries, api's and technologies in order to get your work done.

In C#, the 'extra' learning besides the language is simply because the libraries tend to all follow a similar programming idiom. In C++, getting something done requires a dev to have knowledge all over the map. Want to do some Xml programming using the XmlDocument that ships with Internet Explorer? Well, you need to understand COM (and that's about a 6 month learning curve).

Want to do some string manipulation? There's CString (MFC in VC6 and earlier), std::string, std::wstring, and CString (ATL and MFC in VC7.1 and above). How about understanding the difference between ANSI and UNICODE strings and the proper way to code them for Windows apps. If you code the string like you learn them in school (i.e. "my string"), you are going to have problems when you convert your ANSI app to a UNICODE app (not that you should be writing ANSI apps anyway). In C#, there is only one string class and it's already UNICODE.

In addition, what C# offers is that it abstracts much of the details and provides a cohesive programming interface.

I am in the business of making quality applications. I'm not in the business of feeling good about my programming because I've successfully navigated how to do some operation that required a whole bunch of domain knowledge (like using COM).

What language/programming environment someone uses is ultimately up to each individual. For me, I'm going to go with the one that lets me develop quality apps that have rich feature sets with the minimum amount of effort.

yes, that's why I started my post with "ideally speaking" :)

anyway, I'm still persuaded that my point stands, at least as far as full-control-minded people is concerned, that the amount of things you need to know at the end are essentially the same.

Quote:

---

Originally Posted by Arjay

Want to do some Xml programming using the XmlDocument that ships with Internet Explorer? Well, you need to understand COM (and that's about a 6 month learning curve).

---

this sounds a bit unfair, bacause I doubt C++ programmers learn COM just by accident, say, while doing some "Xml programming using the XmlDocument that ships with Internet Explorer" :); moreover, you should weight those 6-months of learning curve ( maybe an overstatement, BTW ? ) with respect to the whole opportunities that knowing COM opens to you in windows programming, which clearly go much beyond xml manipulation :)

Quote:

---

Originally Posted by Arjay

If you use C++ to develop Windows applications, it isn't enough to just know the C++ language, you must also be familiar with a variety libraries, api's and technologies in order to get your work done.

---

well, the same comment applies to C# as well, unless you consider the whole .NET framework as part of the language, which, I suppose, in any case has its own learning curve ... anyway, as long as we accept that

Quote:

---

Originally Posted by Arjay

C# [..] abstracts much of the details and provides a cohesive programming interface.

---

... then I cannot disagree with you ( because I don't know/use the .net framework and have no reason not to believe you :) ).

Quote:

---

Originally Posted by Arjay

For me, I'm going to go with the one that lets me develop quality apps that have rich feature sets with the minimum amount of effort.

---

so, if you were charged with programming from the ground up, say, a 3d modeling\game\scientifc visualization\processing software or any other software in which the majority of the intellectual investment needed for its development lies in its original content rather then its "supporting technologies", would you prefer a C# based-solution to a C++ based-solution ?

Quote:

---

Originally Posted by superbonzo

so, if you were charged with programming from the ground up, say, a 3d modeling\game\scientifc visualization\processing software or any other software in which the majority of the intellectual investment needed for its development lies in its original content rather then its "supporting technologies", would you prefer a C# based-solution to a C++ based-solution ?

---

I'd like to hear an answer to that, too.

BTW, the way you enumerated those, IMO, fits perfectly on this diagram:

Code:

---

<<< 3d modeling  --  game  -- scientifc visualization -- processing software -- scientific simulation >>>
 
<<<---- more C# friendly ----------------------------------------------------- more C++ suitable------>>>

---

But, this also depends what you consider the ground level: will any supporting hardware be used (GPUs, FPUs, something else), build on top of DirectX or OpenGL, or implementing all in software (well, not for games, but sci-simulations maybe, depending on the purpose and precision required), stuff like that.

However, it's maybe more be realistic to use both C# and C++, especially towards the middle and the right part of the graph. C# GUI and high-level code and structuring, C++ the CPU (or whatever-PU)-intensive work. Note that it's possible to write a game entirely in C# - I think a recent Sims series entry was written in C#, not sure.

Quote:

---

Originally Posted by superbonzo

this sounds a bit unfair, bacause I doubt C++ programmers learn COM just by accident, say, while doing some "Xml programming using the XmlDocument that ships with Internet Explorer" :);

---

I'd say back 10 years or so, and many C++ programmers who wanted to learn Xml, learned COM 'by accident'.

Quote:

---

Originally Posted by superbonzo

moreover, you should weight those 6-months of learning curve ( maybe an overstatement, BTW ? ) with respect to the whole opportunities that knowing COM opens to you in windows programming, which clearly go much beyond xml manipulation :)

---

There is no doubt that learming COM is beneficial, but many folks started learning COM out of necessity, rather than learning it for the sake of picking up a new technology.

Btw, Don Box (the father of COM) referred to learning COM as "6 months of fog". The 6 month estimate was his, not mine.

Lastly, try comparing a technology like COM with one similar in .Net like WCF services. Have you ever tried to configure COM (DCOM) services for security across a different network domain? It's like pulling teeth. It's a breeze doing this with WCF services. This is just one example where the newer technology has a richer feature set and is easier to use.

Quote:

---

Originally Posted by superbonzo

well, the same comment applies to C# as well, unless you consider the whole .NET framework as part of the language, which, I suppose, in any case has its own learning curve ... anyway, as long as we accept that

---

Keep in mind that knowing a language isn't enough. As I mentioned, with C++ you are going to need to know much more than the language (like COM and the Win32 api). Sure in C#, you'll need to know which .Net classes to use, but unlike C++, you don't have to learn 10 different technologies to get your work done.

Quote:

---

Originally Posted by superbonzo

so, if you were charged with programming from the ground up, say, a 3d modeling\game\scientifc visualization\processing software or any other software in which the majority of the intellectual investment needed for its development lies in its original content rather then its "supporting technologies", would you prefer a C# based-solution to a C++ based-solution ?

---

I'm not talking about on particular area, like game or graphic programming - I'm talking about general programming areas. Of course in order to see this, one needs to actually code in C# to see it's benefits. If you only code in C++ (on VC6), one likely isn't going to see how much simpler things have become.

P.S. Sorry about the mini-slam on the folks still using VC6. For the life of me, I can't figure why some programmers feel that working on a 13 year old compiler is a good idea. But that's one of the great things about software development - folks can do whatever works for them.

:)

Quote:

---

I can't figure why some programmers feel that working on a 13 year old compiler is a good idea. But that's one of the great things about software development - folks can do whatever works for them

---

(Only to add) A large portion of code, libraries in industries (industrial robots, medical applications, IC related etc) are still using VC6 as a must. These companies are not usually not IT oriented, which may be why they don't care about upgrade, it costs a lot and upgrading old libraries source code is always a nightmare, even to those in IT mainstream.

don't get me wrong, I'm neither prejudicially sceptic towards C# or any other newer technology, nor I want to call your experience into question ...

I simply don't buy the idea that in all generality, C# "lets me develop quality apps that have rich feature sets with the minimum amount of effort." but C++ not. Especially in those cases when, as I said, the majority of the development effort lies in the "original content" of a software product ...

Quote:

---

Originally Posted by Arjay

I'm not talking about on particular area, like game or graphic programming - I'm talking about general programming areas.

---

ok, so, what's your answer in the cases I mentioned ? ;)

Quote:

---

Originally Posted by PumpoBee

(Only to add)It costs a lot and upgrading old libraries source code is always a nightmare.

---

It's worse the longer you wait. Going from VC6 to VC7.1 equals a little pain. Going from VC6 to VC10 equals a lot of pain.

Maybe I've been fortunate, but I've been able to successfuly encourage the vendors I've worked with to support more recent VC versions.

Btw, on the .Net side, new source code can usually run with older libraries, so you are less likely to run into the "stuck in 1998 technology" problem.