|
I have passed C++ exams (at Uni) & interviews but don't really feel happy with it. I have never felt the need to write something in C++ one firm I worked for the software guy was if it's not C++ it won't work despite my doing everything in C# a lot quicker. Mostly as I tend to think I need to so & so I know how do it in one language and translate it. I don't think that works with C++...
|
|
|
|
|
glennPattonWork wrote: don't really feel happy with it.
You have never used a pointer, then. Pointers make happy.
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Do not feed the troll ! - Common proverb
|
|
|
|
|
Oh I have used a pointer as it was one of the few ways to get at the memory address to interface to outside world. Personally I never found pointers as confusing as some do (I am an old school basic programmer who used peek & poke a lot, I guess  ).
|
|
|
|
|
I was serious, pointers do make happy. Is there something comparable in C# (I am an oldskool C++ programmer, so ...) ? There is probably no use of it.
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Do not feed the troll ! - Common proverb
|
|
|
|
|
Well Pointers do exist and you can use them (expect to banished to a dark corner if you) with P/Invoke but I never have (well once for a demo in house using the Parallel Port) and you can use them (I am told) for accessing DLL's (but why?)... So they exist but are not really used (like appendix!)
|
|
|
|
|
In C++ pointers indicate where something is. In C# they indicate where it was
(Unless you pin them down, things can wander around)
|
|
|
|
|
Rage wrote: You have never used a pointer, then. Pointers make happy.
Do you think you are a better software engineer that the folks that wrote the C# compiler? Can you see a marked improvement in efficiency? I doubt it.
I liked pointers when I coded in C++ but have not yet found a reason where I just couldn't do something without using pointer arithmetic. If I do find a situation where I need pointers I can always implement that bit of code using them.
|
|
|
|
|
I have never talked about better or worse, which is a pretty useless discussion (use the right tool for the right problem).
I merely mentioned that pointers make happy.
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Do not feed the troll ! - Common proverb
|
|
|
|
|
Rage wrote: pointers make happy
Here is a ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif) to being happy.
|
|
|
|
|
The C# compiler is written in C++, by the way.
|
|
|
|
|
harold aptroot wrote: The C# compiler is written in C++, by the way.
Irrelevant what language it is written in as long as it does the job.
|
|
|
|
|
Actually, it is relevant this time. Not to the product, but to the discussion. Specifically, it shows that
JimmyRopes wrote: Do you think you are a better software engineer that the folks that wrote the C# compiler? Can you see a marked improvement in efficiency? I doubt it.
either makes no sense, or is unclear enough that I completely misunderstood it (or maybe even both).
|
|
|
|
|
JimmyRopes wrote: Do you think you are a better software engineer that the folks that wrote the C# compiler? Can you see a marked improvement in efficiency?
I was questioning why pointer arithmetic is so glamorous. I have spoken with some people who think they are "computer scientists" because they work with pointer arithmetic and that anyone who doesn't is somehow inferior.
It is only arithmetic after all.
I coded professionally for 18 years in assembler before going to C++ so I wasn't so enamored with pointer arithmetic. It was just something you did.
|
|
|
|
|
All right, that makes sense
|
|
|
|
|
glennPattonWork wrote: the software guy was if it's not C++ it won't work despite my doing everything in C# a lot quicker
I have run into this very same problem. These people are not open to change in the way they do things. They know how to do it in C++ and don't want to learn a new way of doing things regardless of any advantages.
I coded in C++ for 10 years and C# for 6 years and the major reason I prefer C# for Windows systems is the .NET runtime.
If I release something in C++ it is frozen in time. If subsequently some system DLL I used is found to have , lets say, a security flaw and is re-released with a fix I need to know about it and re-compile my system and re-release it to all my customers. Not an easy task.
With C# I don't have to do anything because Microsoft updates the runtime modules and all is well. No effort on my part.
The person who started this discussion stated that he wanted to do some cross platform work so C# isn't in the equation, but C++ is distributed on many platforms so it would be the language of choice for cross platform compatibility.
modified 6-Feb-14 9:01am.
|
|
|
|
|
Mmmm, C# is not really cross platform I agree, I use C for that. I have found that if you compare an object oriented properly designed exe to a functional C coded exe the C is smaller and runs with less resources! 
|
|
|
|
|
JimmyRopes wrote: If I release something in C++ it is frozen in time....With C# I don't have to do anything
Just curious...
Do you write a lot of applications which you never update again?
Do you do any testing of existing applications with new updates to windows or do you just assume that they will work?
|
|
|
|
|
jschell wrote: Do you write a lot of applications which you never update again?
Sometimes yes and sometimes no.
I have had applications which have never been changed after initial release (good specifications of the problem at hand) and I have had applications that were scheduled to be changed while still in development or system test and due to be released (planned enhancement to avoid feature creep resulting in never getting a product to market).
I would have to concede that multiple releases are more prevalent (in which case the latest system dll will be used), but there have been cases where the product was frozen and no further enhancements will be forthcoming.
jschell wrote: Do you do any testing of existing applications with new updates to windows or do you just assume that they will work?
Yes and no.
Sometimes I am aware of the changes that have taken place and I run some regression testing to see if anything is broken with a new release of the .NET runtime, and other times, either don't know about a change that has been implemented or the application is history and no longer actively supported.
That is not to say that if a problem ticket is opened for a specific problem that it will not be addressed. It is just saying at some point one must move on and concentrate on on-going development.
In a perfect world we would re-test every application we have ever written, but in the world I live in, sorry to say, that only happens in theory. 
|
|
|
|
|
This is a general thread reply, not an original post reply.
Seeing the C++ / C# discussion, coming from a BASIC / FORTRAN / VB background, it is VERY humourous...
|
|
|
|
|
Always a good tool for your toolbox.
If you ever do any embedded you will need C/C++!
|
|
|
|
|
C++ Embedded? I always thought the size too large, mind you I have seen a couple of C++ compatible compilers from TI and Atmel, not Microchip though...
|
|
|
|
|
With the memory footprint on uControllers increasing the need for shoehorning code on some of the chips is not necessary, mind you it all depends on what you're doing.
I've used C++ on a couple of large projects on the ATMega1280/ATMega2560 boards and not had a bit of problems. There are limitations; you can't do a lot of dynamic memory allocation because the memory management on them is pitiful, if timing is an issue you have to use assembler but you have to do that in C also and interrupts are a bit tricky.
I don't use uChip so can't comment on there platform but for AVR I've had no problems and have written many libraries using C++.
|
|
|
|
|
I've done a lot of programming over the past 25 years (started with Fortran for mainframes, C for 8 bit microcontrollers, and C++ with some VB for Windows apps). Now I use C# almost exclusively precisely because of the .NET framework.
I have also done some C++/CLI for interoperating .NET DLLs with native applications.
My point?
Language and tools are just that.... Tools to get a job done. Pick the best one for the job at hand.
Having said that, if I were doing cross platform work I would use Mono and avoid the parts of the .NET framework not supported by Mono. Frankly, it takes me a lot fewer lines of code to do the same thing using C# and .NET versus C++.
|
|
|
|
|
Hi All,
I feel suitably humbled I know I should "ask the duck" as Richard Deeming suggested on Tuesday.
I just find the syntax more awkward that I should. I really only have done this style of program in VB6 and not VB.Net, C# is preferred for this kind of job but I can't use it as the end customer only has a VB kiddie (who I bet wears a base ball cap backwards, doesn't believe in belts & says "Dude" every five minutes). I am suitably humbled by asking the most obvious questions & offer thanks to CPallini & Griff (sorry!!!)
|
|
|
|
|
You didn't read the warning at the top of the file -
Option Suspicious
speramus in juniperus
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
