Debugging and examining memory is mostly a function of the system you're using, not the language. It's so intertwined in C because C is so intertwined in Unix. But one needs to do away with these C assumptions when working with C++. I think this is a case of beginner's wisdom, where you have just enough knowledge to get yourself in trouble.
Even if I thought that adding features was always a good thing, I still never made the silly assumption that they don't affect things that they're not directly related to. If they didn't affect these things, we wouldn't be having this argument. So no, I have no clue how you attributed this assumption to me.
Hahahaha. 50% of what I do professionaly is interface with other people's code. Bad MFC-influenced C++ code. Bad traditional C code written when I was in kindergarten. Bad C++ written by VB programmers. Bad VB written by doctors and financial guys. Large projects and small, you don't call in the consultants until you're sure your code is thoroughly screwed. So yes, I work with a lot of other people and yes, I understand the abuse very, very well. Yet still I hold the position that I do. I've come to realize that there's a lot of screwed up code out there, even in "safe" languages like VB. I simply make language recommendations based on the level of ability I perceive of my clients, nothing more. Note how the original poster had a specific goal, and I made a recommendation that would seem counter to what I've been arguing for this entire time. When there is no stated goal, however, everything is on the table and every last possibility must be accounted for.
So this is your answer: People should only avoid features that are "misused, or commonly misused" within languages that people can not understand to an extreme degree. You base this on the fact more people know C to an extreme than C++. Shouldn't this be obvious though? If one is going to master C++, one will naturally master C in the process. Most of the 'serious' programmers I've met know C++, or are not daunted by a simple debugging session with some random C++ code. With any of the competent programmers I've met, syntax means nothing once the basic idioms are mastered, and google is the instant reference for anything =). So from the start we see that this condition will never be met due to C++ being a superset of C. Many people write books using only a subset of a language. It's not impossible to restrict one's vocabulary, and I've worked on several projects with strict rules (mostly for portability, though, I wouldn't trust a manager that hired a guy that couldn't debug a random subset of valid code). So I disagree with that premise as well. Debugging standard code is a simple matter for most programmers I've met -- it's the library stuff that gets ya =). Thus, it is indeed logic, I simply disagree with the premises that excludes VB.
Then the references to which you refer are basically the same as pointers that memory arithmetic operations cannot be applied to. Your beef isn't with pointers, it's with memory address manipulation.
When did I do that? I don't remember doing so... all I remember is responding to your points about C++ and C cleanliness =).
LPC and C++ are two vastly different things. And before you ask -- LPC doesn't have nearly as many features for writing extendable, generic and safe code that C++ does =). Of course I usually forgive this because one can extend LPC from within C (and thus C++).
|