Flutterby™! : C++ 2005-05-25 00:15:17.015676+00

C++

2005-05-25 00:15:17.015676+00 by Dan Lyke 7 comments

For years I've been using C++ as a better C, and ignoring most of the evolution of the language. While I've kept up on the conceptual advances in other languages, I haven't been tracking them in C++. However, the new gig involves a lot of unabashedly C++ code, and there's a lot of it, and it needs to use a lot of the language features, so I'm reading a bunch of books to get back current.

Wow. No wonder people are willing to stand for some of the issues in Java and C#. I mean, it's cool what all you can do, but I'm shocked and amazed that someone hasn't done a high level language that compiles to native code, because sometimes the speed of the interpreter does get in the way, but I can imagine that trying to bring beginning programmers up through the usual C pitfalls in a C++ environment is beyond scary.

Aaand, C++ brings back the old differences between post and pre increment and decrement operators. Something I hadn't thought about in years, especially since I'd discounted it as a performance issue with compiler technology as of two decades ago.

In your new C++ endeavors, are you running into any of the more interesting ISO C++ changes? Specifically things like, reinterpert_cast<>, et al as the "right" way to cast?

I've still got a copy of the ARM that has an appendix in the back describing "experimential" features like exception handling, RTTI, and templates. Other than STL (which, granted, is a big change but implemented using aforementioned features) and the whole for loop variable declaration scoping change nonsense, the C++ I touch every now and then and the C++ I used back in the day are pretty much the same. I'm a bit surprised that there's not a natural, backwards compatible evolutionary step forward for the language. Maybe something around aspects?

Just ranting... Although I'd like to know if you still try and use Zortech C++ extensions in your current coding. <g>

I found a pile of bugs when I decided to go through code splatting casts and replacing them with reinterpret_cast / const_cast / etc as appropriate. Not all of the newer C++ features are a bad thing...

I actually think that the STL makes C++ into a really nice language. You can express a lot of stuff in well understood idiomatic code. That doesn't really cross over very much with the old-style 'C upgraded to C++' code though.

nb. The high level language which compiles to machine code that you want is probably OCaML. Or haskell possibly, although that has a bit of a steeper learning curve.

Of course, I've always defaulted to the post-increment because I mostly learned C from Dan's code... And I was about to say that it's been a decade since I looked at the assembly output of a compiler, but I was mostly thinking of trying to find what optimizations in the "latest" version of the Microsoft C compiler were causing a specific piece of code to fail (so I could either recode it or turn off the optimization). But then I remembered that as recent as 1998, I was looking at the assembly output of the Metrowerks C compiler for the Mac trying to figure out why I was getting a SCSI parity error on one particular model Macintosh about 30 minutes into Aladin MathQuest. Apple's resolution for the problem was to turn off the SCSI parity checking by removing the jumper on the CD-ROM drive. Needless to say, that wasn't an acceptable solution for Disney Interactive...

In academia, I'm finding that using C++ is more like a badge of courage. Undergrads and MS-level grad students use Java. PhD and post-doc use C++. But I think the reason there is that as an undergrad and MS, you really need to know how to leverage other people's code. As a PhD student, you get/have had the time to build your own classes.

I'm actually long familiar with the various different forms of cast, and we've got RTTI turned on so there's more than there should be of dynamic_cast<...>s flying around.

The things that have really leaped out at me are some of the implications of what those experimental features in the ARM meant. All the semantics of public and private constructors and destructors and overloaded new and delete. There's a couple new keywords I've had to look up (mutable does what we used to do with const_cast<...>), but, for instance, I'm still getting used to what using means in terms of declaring that you'll be referencing from parent objects (as opposed to just namespace defaulting).

It's not like there are any new concepts here, but for the first time in years I'm reading technique books and not thinking "yeah, whatever, I could have written this."

Oh yeah: Pre-(inc|dec)rement is better because the operator could be overloaded, and if this isn't inline and the object is moderately heavyweight then the copy operation could get expensive.

And it's C++ rather than ++C because ++C wouldn't return C before the increment. Backwards compatibility would be lost.

#Comment Re: made: 2005-05-26 16:43:14.847171+00 by: ebradway [edit history]

Where Orwell refers to George Orwell's 1984, and I'm sure he's refering to DoubleSpeak...