Stand in silent tribute for the code which I write use C++.
-
I don't know of any good books, for style in C#. I guess it's just a case of looking at code where you can, and learning from it, and being open to rethink how you do things. I still think C# sucks for not supporting const, especially when classes are always passed by ref.
Christian Graus - C++ MVP
-
How did you even figure out what that guy was saying? I mean, I think I have certain skill at understanding people who are trying to communicate in English when it's not their native tongue (and believe, I have great respect for them), but this fellow, whew, I've heard more intelligent babble from someone in an insane asylum! Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithAre you sure you're reading the same post ? It seemed clear to me ( although not good English, I admit, I bet there's another language he speaks a lot better than I do )
Christian Graus - C++ MVP
-
Christian Graus wrote:
I still think C# sucks for not supporting const
This is my biggest peeve with dot net. Trying to write good CLI wrappers around a large set of interrelated c++ classes has involved a lot of const_cast-ing
And it's not like there aren't other places that the C# compiler adds complexity compared to the framework, out has no meaning in .NET, the compiler enforces it as a ref that must be assigned a value. Isn't const just a reversal of that code - check that a value is NOT assigned ? OK, if it gets passed again, it gets complex, but cry me a river. Even if const only worked for methods that were self contained, it would be *something*. And isn't C# supposed to be protecting us from ourselves ( such as the situation with switch statements ) ? Surely we need protection from code that changes the values of our classes, when we pass them in, by reference, with no say in the matter ?
Christian Graus - C++ MVP
-
I don't know of any good books, for style in C#. I guess it's just a case of looking at code where you can, and learning from it, and being open to rethink how you do things. I still think C# sucks for not supporting const, especially when classes are always passed by ref.
Christian Graus - C++ MVP
Christian Graus wrote:
I still think C# sucks for not supporting const
What was MS's justification for that? I can't think of a good one, so I'm curious to know.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
Christian Graus wrote:
I still think C# sucks for not supporting const
What was MS's justification for that? I can't think of a good one, so I'm curious to know.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
It's got me beat. I went to an MVP summit and I raised that, the stupidity of the switch thing, and the lack of default params, and their response was 'we're going to keep making it as easy to use as possible'. In other words - 'we're gonna assume our users are stupid' Sometimes, I really miss C++.
Christian Graus - C++ MVP
-
It's got me beat. I went to an MVP summit and I raised that, the stupidity of the switch thing, and the lack of default params, and their response was 'we're going to keep making it as easy to use as possible'. In other words - 'we're gonna assume our users are stupid' Sometimes, I really miss C++.
Christian Graus - C++ MVP
Christian Graus wrote:
Sometimes, I really miss C++.
Can you hear it? It's calling you Christian. Come back to the dark side, yeeeessss! ;P
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
Christian Graus wrote:
Sometimes, I really miss C++.
Can you hear it? It's calling you Christian. Come back to the dark side, yeeeessss! ;P
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
Well, I *have* done a lot of MFC/C++ for the toolbox of late, which has been pretty cool. It's good to be up to date as well, to know the newer stuff, but still....
Christian Graus - C++ MVP
-
How did you even figure out what that guy was saying? I mean, I think I have certain skill at understanding people who are trying to communicate in English when it's not their native tongue (and believe, I have great respect for them), but this fellow, whew, I've heard more intelligent babble from someone in an insane asylum! Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithIf what you say is my post, I would apologized for it. Maybe it's also babble, so I will say this use Chinese.It is: 如果你指的是我写的帖子的话,那么我要为它向你道歉. 不好意思了,虽然我学习英语很多年了,可是仍然不能说一口漂亮的英语.直到工作后大量接触英语,这时才有所长进(在学校时的英语水平更差)
========================================= 中国，昆明
-
Are you sure you're reading the same post ? It seemed clear to me ( although not good English, I admit, I bet there's another language he speaks a lot better than I do )
Christian Graus - C++ MVP
-
Christian Graus wrote:
Sometimes, I really miss C++.
Can you hear it? It's calling you Christian. Come back to the dark side, yeeeessss! ;P
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
Jeremy Falcon wrote:
Come back to the dark side, yeeeessss!
Yes after being on diet code for several years, it feels so good to be back on regular code. :)
-
Yes, it's a common problem that people teaching C++ are C programmers, and so they fail to teach C++, barely teaching 'C with classes'. C style string and file handling is the biggest area where people are just taught to do stuff the hard way.
Christian Graus - C++ MVP
Of course, I didn't go to school to learn programming, but I can see teaching the fundamentals of the language in C during the first part of the course and then advancing to the full blown features of C++ and OOP in the second part. Like many of us, I migrated to C++ from C, so I didn't have to bite it all off in one chunk. I remember the days of learning to program (C was my first language) and struggling with the concept of pointers, memory management, etc. So, there's a benefit I think in an incremental approach, but I suspect that this isn't what's happening out there. Just a bunch of tenured professors who don't want to bother with any of that newfangled stuff, I suspect.
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
-
Of course, I didn't go to school to learn programming, but I can see teaching the fundamentals of the language in C during the first part of the course and then advancing to the full blown features of C++ and OOP in the second part. Like many of us, I migrated to C++ from C, so I didn't have to bite it all off in one chunk. I remember the days of learning to program (C was my first language) and struggling with the concept of pointers, memory management, etc. So, there's a benefit I think in an incremental approach, but I suspect that this isn't what's happening out there. Just a bunch of tenured professors who don't want to bother with any of that newfangled stuff, I suspect.
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
Christopher Duncan wrote:
Of course, I didn't go to school to learn programming, but I can see teaching the fundamentals of the language in C during the first part of the course and then advancing to the full blown features of C++ and OOP in the second part.
I think that's the wrong way to go, and so does Bjarne Stroustrup. C is more complex than C++, unless you're just talking about creating (non-pointer) variables and adding them. But, even to show output, you need to start with C++ so you use iostreams.
Christian Graus - C++ MVP
-
Christopher Duncan wrote:
Of course, I didn't go to school to learn programming, but I can see teaching the fundamentals of the language in C during the first part of the course and then advancing to the full blown features of C++ and OOP in the second part.
I think that's the wrong way to go, and so does Bjarne Stroustrup. C is more complex than C++, unless you're just talking about creating (non-pointer) variables and adding them. But, even to show output, you need to start with C++ so you use iostreams.
Christian Graus - C++ MVP
Although I've been doing this for a lot of years, I really don't consider myself to be a language guru, and I'm certainly not qualified to argue with the likes of Stroustrup. Shucks, I'm not even qualified to argue with a language guru. :) That being said, I do see it differently. When I started with C, I first read up on the basic architecture of the IBM compatible PC (such were they called in those days), and in the process got at least a basic understanding of the 8086 instruction set and how things worked at that level. Then, when I started dealing with pointers, memory management, interrupts, etc., I had a better foundation for understanding why my code kept rebooting the PC things worked the way they did. Although they are to a certian extent separate languages, C++ is in many ways an extension of C. If you don't understand some of the basics, you're going to make a mess of things regardless of which language you're using, and whether you're using some of the more abstracted features of C++ or you're down to the metal and twiddling the bits. Visual Basic programmers aren't taken seriously by a lot of developers. While that's often a bad rap, to a degree there's a reason for this poor reputation. Because VB was designed to be a drag & drop development environment "so easy even an idiot could use it," a lot of idiots did just that. What followed was an explosion of people buying it and kicking out apps. People who had no grounding in the fundamentals of the PC, the workings of the Windows operating system, or any number of other things more seasoned programmers take for granted. You can get away with having your secretary throw together a quick form that crunches three numbers together and displays the total, but that doesn't make her a professional developer. Do you need to know the finer points of an event driven architecture to kick out a quick and simple app? No, not always. However, if you're going to make a living at this, it won't be long before you find yourself floundering because you never got a grip on the basics. The first 75% of the app doesn't really point out the rookie developer. That doesn't become evident until the last 25% that takes ten times as long (as a result of the first 75%). Basics matter. My point in this digression is not to make fun of all the seasoned and pro quality VB guys out there, because a good developer is a good developer regardless of the tool used. Rather, it's to illustrate that to an admittedly smaller degree, I see a benefit in understanding the
-
Although I've been doing this for a lot of years, I really don't consider myself to be a language guru, and I'm certainly not qualified to argue with the likes of Stroustrup. Shucks, I'm not even qualified to argue with a language guru. :) That being said, I do see it differently. When I started with C, I first read up on the basic architecture of the IBM compatible PC (such were they called in those days), and in the process got at least a basic understanding of the 8086 instruction set and how things worked at that level. Then, when I started dealing with pointers, memory management, interrupts, etc., I had a better foundation for understanding why my code kept rebooting the PC things worked the way they did. Although they are to a certian extent separate languages, C++ is in many ways an extension of C. If you don't understand some of the basics, you're going to make a mess of things regardless of which language you're using, and whether you're using some of the more abstracted features of C++ or you're down to the metal and twiddling the bits. Visual Basic programmers aren't taken seriously by a lot of developers. While that's often a bad rap, to a degree there's a reason for this poor reputation. Because VB was designed to be a drag & drop development environment "so easy even an idiot could use it," a lot of idiots did just that. What followed was an explosion of people buying it and kicking out apps. People who had no grounding in the fundamentals of the PC, the workings of the Windows operating system, or any number of other things more seasoned programmers take for granted. You can get away with having your secretary throw together a quick form that crunches three numbers together and displays the total, but that doesn't make her a professional developer. Do you need to know the finer points of an event driven architecture to kick out a quick and simple app? No, not always. However, if you're going to make a living at this, it won't be long before you find yourself floundering because you never got a grip on the basics. The first 75% of the app doesn't really point out the rookie developer. That doesn't become evident until the last 25% that takes ten times as long (as a result of the first 75%). Basics matter. My point in this digression is not to make fun of all the seasoned and pro quality VB guys out there, because a good developer is a good developer regardless of the tool used. Rather, it's to illustrate that to an admittedly smaller degree, I see a benefit in understanding the
Christopher Duncan wrote:
Although they are to a certian extent separate languages, C++ is in many ways an extension of C.
That is true.
Christopher Duncan wrote:
If you don't understand some of the basics, you're going to make a mess of things regardless of which language you're using, and whether you're using some of the more abstracted features of C++ or you're down to the metal and twiddling the bits.
Not really. It depends entirely on what you're doing. A person who wants to store some strings, allow the user to input them, and spit out the result, on the console, actually DOESN'T need to understand how pointers work, they can use std::string. Anyone with half a brain, no matter how experienced, would use std::string, or CString, rather than TCHAR* anyhow. Of course, the time comes when you need to know what std::string is wrapping for you, in order to progress, in order to use the class intelligently ( to understand the cost of an operation, for example ), and in the end, a C++ programmer will need to understand pointers. There's just no need for pointers to be part of lesson number 2. In the same way, I did a fair whack of MFC before digging in to find out how Win32 works. And, I discovered that I'd learned a lot of it 'by accident', as I made a lot of Win32 calls already in places. So, it was easy to start with a broad, shallow understanding, and make parts of it deeper as time progressed. It was also more productive.
Christopher Duncan wrote:
However, if you're going to make a living at this, it won't be long before you find yourself floundering because you never got a grip on the basics.
Sure - I wasn't suggesting anyone work as a C++ dev without knowing C++ *well*. I'm really talking about the order in which the parts should be learned, by someone who knows they are still learning, and not up to writing production quality code. In the end, what happens is people learn the C way first, and end up using FILE and char * instead of the superior C++ alternatives, because that's what they remember learning.
Christian Graus - C++ MVP
-
Christopher Duncan wrote:
Although they are to a certian extent separate languages, C++ is in many ways an extension of C.
That is true.
Christopher Duncan wrote:
If you don't understand some of the basics, you're going to make a mess of things regardless of which language you're using, and whether you're using some of the more abstracted features of C++ or you're down to the metal and twiddling the bits.
Not really. It depends entirely on what you're doing. A person who wants to store some strings, allow the user to input them, and spit out the result, on the console, actually DOESN'T need to understand how pointers work, they can use std::string. Anyone with half a brain, no matter how experienced, would use std::string, or CString, rather than TCHAR* anyhow. Of course, the time comes when you need to know what std::string is wrapping for you, in order to progress, in order to use the class intelligently ( to understand the cost of an operation, for example ), and in the end, a C++ programmer will need to understand pointers. There's just no need for pointers to be part of lesson number 2. In the same way, I did a fair whack of MFC before digging in to find out how Win32 works. And, I discovered that I'd learned a lot of it 'by accident', as I made a lot of Win32 calls already in places. So, it was easy to start with a broad, shallow understanding, and make parts of it deeper as time progressed. It was also more productive.
Christopher Duncan wrote:
However, if you're going to make a living at this, it won't be long before you find yourself floundering because you never got a grip on the basics.
Sure - I wasn't suggesting anyone work as a C++ dev without knowing C++ *well*. I'm really talking about the order in which the parts should be learned, by someone who knows they are still learning, and not up to writing production quality code. In the end, what happens is people learn the C way first, and end up using FILE and char * instead of the superior C++ alternatives, because that's what they remember learning.
Christian Graus - C++ MVP
Christian Graus wrote:
In the end, what happens is people learn the C way first, and end up using FILE and char * instead of the superior C++ alternatives, because that's what they remember learning.
Or because that's all the profs taught them. This is the part where I definitely agree.
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com