Really frustrated when moving from C# to C++

[Nemanja Trifunovic]

Gary R. Wheeler wrote:

Like a lot of other C++ -> C# folks, I'm mainly frustrated by the lack of a deterministic destructor (and don't bring up IDisposable; just don't).

+5. Nothing beats C++ destructors, especially not the complicated and error prone Dispose pattern[^]. I really miss C++ :((

utf8-cpp

[User 4223959]

You probably need to step back a little and write a small program in assembler. C++ is a syntax layer on top of C, which is a macro-assembler of a sorts. That's what makes them different from C#, Java, Python, Lisp... So write a small assembler program ( print an argument + 1) - and then write the same in C or C++. Now run your C program in debugger, step into your code in disassembler and see how the disassembler code compares to your assembler code. Then, I promise, things will click into their places, and you will understand everything :)

[grgran]

It's easy, whenever you get a compiler error just add a "const" keyword near by and keep adding them till the error goes aways. ;-)

[Member 96]

NO it's one thing that distinguishes dinosaurs and modern humans. I coded a crapload of c++ and I wouldn't go back unless forced at gun point.

---

There is no failure only feedback

[patbob]

There's also new, override and virtual functions :) Kpping track of whether a parameter is passed by value or reference because the compile won't help you there. And then there's C# generics vs. C++ templates.. not even close (hint: new, override & virtual). Oh, and let's not forget Dispose() -- blowing the brains out of an instance (that others could still be using) without destructing it. .Net library is worth it, but you could use the C++ implementation of .Net instead.

patbob

[SeattleC]

When you don't know any programming languages, learning your first one is a moderate chore. You have to learn some basic concepts like functions, operator precedence, and of course what the keywords mean (what language #1 uses to spell "for", "procedure", etc). When you know 9 programming languages, learning your tenth is not so hard. You still have to learn how the keywords are put together, and you also have to learn any new concepts implemented in that language. If you're completely switching paradigms (like going from C to haskell) it's a bigger chore. But, when you know exactly one programming language, that second language is pretty tough. It's tough because you already know how to spell "if" and "for". You already know how to define a function, with the certainty you can only have when you only know one way. Learning a second language is hard, because it breaks all your internal rules. Those rules may be wrong, and may be limiting, but the cognitive dissonance caused by breaking them is no less real for that. C++ and C# are both good, useful languages. Both have warts, but neither one is badly broken. They're just for different things. What is broken is just your expectation that you do the exact same things in C++ as you do in C#. And the closer the syntax of the two languages are, the harder it is to get over the notion that they are the same.

[AdamNThompson]

Amen to that. I love coding. Both for my paycheck and in my spare time. I have experimented with lots of languages, frameworks and patterns all for the sake of understanding. One thing I have found to be true is that C# is powerful and time efficient, and flexible. C# and .Net are my go to language/platform of choice. Can I accomplish the same thing in C++? Sure I can, It would just take twice as long and give me a head ache. It's one thing to take the time to understand how a language/platform works behind the scenes to grow as a developer, it's whole other thing to take twice as long to code the same application so that you can go around calling yourself a "real man".

-Adam N. Thompson adam-thompson.com

[Nji Klaus]

Could not have said it any beter.

[S Senthil Kumar]

The features provided by boost don't count as language features, IMO. But yeah, I didn't know about the 0x features. Nice that C++ is evolving with the times. I didn't understand the bad nothing of these features though.

Regards Senthil _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro

[Atique Rahman]

Learning order depends. If someone learns C/C++ first and then he learns C# he will enjoy C# because he knows that things are just easier in C#. It's not like that his knowledge in C/C++ isn't only useful in learning new OOP languages but also to understand how really things work in deeper extent. The `real man` is one who doesn't care about the language/platform but solves the problem in best way using best tools available. Why bother spending years to develop the GUI using C++ if same can be done with C# in months? Why bother using C# when more control over system is necessary i.e., developing device drivers or creating a heavy game with lots of graphics operation requiring direct system API calls. In that case you should C/C++.

[simion314]

Hi, I switched from C# to C++ with Qt4 framework 2 years ago and I love it. Here are some tips that can help you: -you must understand the process of compilation and linking to be able to solve some errors -try using collection classes lice STL vector or Qts QVector instead of C style arrays,you could use .at(index) to access items that will always check the bounds or you could enable some debugging flags that can spot errors like accessing outside of the bounds of this classes -i like the .h and .c++ file separation,it is easy to read the declarations -about pointers, use them only when needed and do not forget to release them at the end ,implement correct destructors(or copy constructors if you nned them) -if you have a SIGSEGV error then the first place to search is in the place you use pointers,the problem usualy is that the pointer points to invalid memory,when you release a pointer make it point to NULL otherwise it will still point at the same memory but the object/data is gone -there are also smart pointers, and you can make the code smart to clean itself,like in Qt where when you delete a parent object it will clean the children automatically I hope this helps and I also ask the "real men" here to also give you tips to make your life easier, I think if i had to program Win32 or MFC apps i would also hate it,if you have a choise in a tool check Qt4 simion314

[n podbielski]

Simple void main(){ } in C use few kb of memory if i remember correctly.

In soviet Russia code debugs You!

[Lost User]

Luckily, the startup code before main() is called is very small on those old computers. It's not like the memory is full when you run a hello world type program. But still, only if you are very careful (= ignoring many principles of writing good code) you will get something similar to what you used to get when writing everything in assembly.

"I just exchanged opinions with my boss. I went in with mine and came out with his." - me, 2011 ---
I am endeavoring, Madam, to construct a mnemonic memory circuit using stone knives and bearskins - Mr. Spock 1935 and me 2011

[AdamNThompson]

I agree with using the right tool for the right job. All I'm saying is just don't be that guy that codes everything with notepad just to prove a point. We had one of those once and in software consulting that kind of crap doesn't fly anymore. A good developer takes advantage of the tools and frameworks that are available to be more productive! That's all I'm saying...

-Adam N. Thompson adam-thompson.com

[Snorri Kristjansson]

Yes life is a bitch - and then you learn C++ - and discover how easy you had it before :) I've had the pleasure to learn C# .NET in the past few months after programming ASM, C, C++ in the past 30 years. It's almost too easy to code in C# .NET compared to C++.

[jschell]

AdamNThompson wrote:

A good developer takes advantage of the tools and frameworks that are available to be more productive

In contrast of course to an excellent developer (or manager) that actually understands that productivity is something that can actually be measured and which very seldom is. And consequently claims that something is "more productive" is often no meaningful than any other subjective notion.

[AdamNThompson]

"excellent developer (or manager)" In my experience "excellent developer"s are not managers. They want to write software... Not manage people. As for measuring productivity, coming from someone that is managed on productivity alone, I can assure you that it is measurable. 1) You meet you deadlines or you don't 2) Your code is maintainable or it's not 3) Your code is documented or it's not 4) Your code meets the business requirements or it doesn't 5) Your peer code reviews ether go well or they don't These are the things that I am measured on, and my team is accountable for. What time I come in, how I dress, an do on, are all a far second to actual productivity. Now that is progressive management based entirely on productivity. The fact is that when faced with a new project there are a lot of decisions to make. Those decisions directly affect productivity. I don't care what you are developing. As a lead developer it is very clear to me that some technologies are going to be more productive than others given the requirements of the project. I am not trying to discount you, I just want to make the point that productivity is indeed measurable, and that it is important to do so.

-Adam N. Thompson adam-thompson.com

[Kenneth Kasajian]

I think part of the problem that people have with C++ is the fact that C++ has such a legacy of usage before it got finalized. For instance, a typical C++ application, used with Win32 and/or MFC, is going to have lots of raw pointers. As an example of ATL, you have a lot of smart pointers, and raw pointers, and it's never quite obvious when ownership of an object is trasnferred. But if you were to write a C++ program from scratch, and not rely on legacy usage patterns, you can make things really clean. I've taken relatively big applications and have completely eliminated all pointer usage. That's not to say pointers aren't useful, but at one time, they were absolutely required. Today, with STL containers and references, they're rarely needed. There's no hard and fast rule, but whenver I see something being "new"ed, I ask -- why are they really doing that? 1. Sometimes there's absolutey no reason to new something. The programmer needs to make a call to another function that accepts a pointer. So they think, "since i need to pass a pointer, i need to declare a pointer variable to pass into it, and since i'm declaring a pointer variable, i need to allocate memory for it". When in reality, they could have just declared the variable inline and passed the address-of the variable to the function expecting a pointer. You'd think that's obvious.. But I come across this more often than not. 2. Use of operator new when they need dynamicly sized arrays of some type. Sometimes, you can just replace with a vector, and it's just as efficient. If it's a string, use std::string 3. Use of operator new because they're using some kind of a data structure, such as linked list. Just use std::list or some other container. 4. In the worst case scenario, used scoped_ptr, shared_ptr, auto_ptr, or some other variant. Back in the days when we only had auto_ptr, it was quite common to return newly allocated memory from a function through the return value of type auto_ptr. If the caller ignores the return value, it gets deleted. Otherwise, the caller is required to copy it to a local auto_ptr variable, which copies the pointer correctly. And you never have to worry about deleting it. So if you have code that has pointers, should you change the code to get rid of them. No -- thhere's no one-size-fits-all soltuion -- and I'm not a purist. But *can* you remove most if not all of the raw pointers from your code, without sacrificing performance, the answer is probably yes. And the fewer raw pointers i

[jschell]

AdamNThompson wrote:

In my experience "excellent developer"s are not managers. They want to write software... Not manage people.

Nothing to do with what I said. I used the word "or" for a reason. <blockquote class="FQ"><div class="FQA">AdamNThompson wrote:</div>As for measuring productivity, coming from someone that is managed on productivity alone, I can assure you that it is measurable.<BR></blockquote> No idea what your point is since I said exactly that.

AdamNThompson wrote:

1. You meet you deadlines or you don't
2. Your code is maintainable or it's not
3. Your code is documented or it's not
4. Your code meets the business requirements or it doesn't
5. Your peer code reviews ether go well or they don't

As stated most of that is not measurable. Certainly item 2 is not. Item 5 can only be measured by documented items that need fixing. And by itself is not a measure of productivity and applying it as criteria for productivity will often be counter productive as it misses the real point of the doing the reviews in the first place as well as promoting the possibility of misuse of the process.

AdamNThompson wrote:

What time I come in, how I dress, an do on, are all a far second to actual productivity. Now that is progressive management based entirely on productivity.

No idea what that statement has to do with anything. Doesn't have anything to do with what I said. Doesn't have anything to do with what I quoted.

AdamNThompson wrote:

I am not trying to discount you, I just want to make the point that productivity is indeed measurable, and that it is important to do so.

I said it was measurable. I said it seldom is. There are any number of proven process control techniques which are almost never performed so importance or not in terms of all of the missed opportunities isn't relevant. But if someone does measure it in a reasonable way then one could make a statement about it. However in contrast to that your list is unlikely to lead to the conclusion that my first response was in response to (specifically what I quoted.)

[dclark299]

Don't know if this has been said yet, sure are a lot of comments on this thread, but to the OP I would contribute: Of course it's going to be a challenge to go from the place you understand and are comfortable to a place where many things are new and strange. And C# and C++ are very nearly the same language, like learning Spanish if you know English -- spend some time in Japan if you want a real jolt. The key is to not make VALUE judgements on the design of the language (whether C++ or Haskell or Lisp or Prolog or ...). Computer languages are not like human languages, they're more like life forms evolving on islands, like those lizards in the Galapagos. They make sense only if you follow their unique evolution; you can't really say a Galapagos lizard is a freak because it doesn't have a pouch like a platypus. A penguin thinks they're BOTH freaks. If you have mastered C# you will master C++ in time. If you are open-minded about it you will come to respect its unique power and beauty. You may never PREFER it, but you will learn from it, and you will be a better programmer for the effort. Best of luck to you.