Really frustrated when moving from C# to C++
-
Simple void main(){ } in C use few kb of memory if i remember correctly.
In soviet Russia code debugs You!
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 -
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++.
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
-
Mostly because of how pointers and references work, and also function definition seems very different. :((
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++.
-
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
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 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.
"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
-
Mostly because of how pointers and references work, and also function definition seems very different. :((
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
-
"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
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:
- You meet you deadlines or you don't
- Your code is maintainable or it's not
- Your code is documented or it's not
- Your code meets the business requirements or it doesn't
- 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.)
-
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
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.
-
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:
- You meet you deadlines or you don't
- Your code is maintainable or it's not
- Your code is documented or it's not
- Your code meets the business requirements or it doesn't
- 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.)
Fair enough. Maybe I get a little carried away. I would like it if you would elaborate though on how you go about measuring productivity, and why you feel that number 2 on my list is not measurable. I feel like I can look at code and tell if it's going to me maintainable. I look for things like meaningful abstraction, IOC, layered architecture, and so on. If someone is making database calls in a code behind file in their UI project, or is cut and pasting the same block of code throughout their work (both of which I have seen done before), I would consider that suboptimal to maintain, and therefor unproductive.
-Adam N. Thompson adam-thompson.com
-
Fair enough. Maybe I get a little carried away. I would like it if you would elaborate though on how you go about measuring productivity, and why you feel that number 2 on my list is not measurable. I feel like I can look at code and tell if it's going to me maintainable. I look for things like meaningful abstraction, IOC, layered architecture, and so on. If someone is making database calls in a code behind file in their UI project, or is cut and pasting the same block of code throughout their work (both of which I have seen done before), I would consider that suboptimal to maintain, and therefor unproductive.
-Adam N. Thompson adam-thompson.com
AdamNThompson wrote:
I would like it if you would elaborate though on how you go about measuring productivity, and why you feel that number 2 on my list is not measurable.
Some ways that have been tried for absolute productivity. - Bug count/lines of code - lines of code - Bug origination (integration, system, production) None of them are very good and all have problems. They are however all objective. Myself I doubt delivery time is viable as it is often dependent on other things. Additionally it isn't a matter of when but rather how accurate the schedule was in the first place. That last is a measurement that can be made and one that can improve over time but that is a process specific to project/task management and not code development. In terms of "maintainable" you woud first need to provide a definition that leads to measurable stats. For example is your code more maintainable because it takes you less time to deliver the next release? Or someone else? And do the requirements of the next release have nothing to do with the release time? What about the time between release updates - would you expect an app that was written in 2000 and is only now being updated to be comparable to another that was released in March (2011) and will have the second release in June?
AdamNThompson wrote:
I feel like I can look at code and tell if it's going to me maintainable. I look for things like meaningful abstraction, IOC, layered architecture, and so on. If someone is making database calls in a code behind file in their UI project, or is cut and pasting the same block of code throughout their work (both of which I have seen done before), I would consider that suboptimal to maintain, and therefor unproductive.
I can look at a plate of food and guess whether I am going to enjoy it a lot, a little or not at all. And whether I could cook it myself and even make it better. That however has nothing to do with whether there is anyway to measure, in concrete business terms, how 'good' the food is nor if my attempt will be 'better'.