I've spent a lot of time messing around with C, having struggled with object-oriented programming (due to not really knowing how best to structure things, not knowing when to apply certain design patterns).

When writing C code, I'd write OOP-esque code (pass around a struct to routines to do things with it) and enjoyed just making things happen without having to think too much about the overall design. But then I'd crave being able to use namespaces, and think about how the code would be tidier if I used exceptions instead of having every routine return an error code...

Working with Python and Node over the past couple of years has allowed me to easily get into OOP (no separate declaration/definition, loose typing etc.) and from that I've made some fairly good design decisions. I'd implemented a few design patterns without even realising which patterns they were - later reading up on them and thinking "hey, that's what I used earlier!"

I've also had a bit of an obsession with small executable files - using templates and other features of C++ add some bloat (on Windows at least) compared to C. There were other gripes I had with C++, mostly to do with making things modular (dynamic linking etc.) but really it's irrelevant/unreasonable.

And yes, for someone who doesn't like code bloat, working with Node is somewhat ironic... (hello, node_modules...)

So today I decided to revisit C++ and dust off my old copy of C++ in a Nutshell, and try to see if I could write some code to do things that I struggled with before. One nice thing is that this book was printed in 2003, yet all of its content is still relevant. Of course, there are newer C++ standards, but I can happily just hack away and avoid using anything that has been deprecated.

One thing I've always avoided is dynamic_cast because every time I read about it, I read that "it's slow". So I just tried to work around it when really if it's the right tool for the job, I might as well use it... It's really useful!

Anyway, now I've typed all this positivity about C++ I will probably find a little later on that I hit a wall with what I'm doing and give up again... :p

  • 1
    Have you ever looked into libcello.org? Claims to give you best of both worlds: performant C with higher-level stuff in it
  • 0
    @irene My programs tend to be small but I always liked to qualify things with a prefix to indicate the functional area things were in. C++ namespaces seem visually nicer and can be omitted when writing code within that namespace.
  • 1
    @awwws0m3 This is the first time I've seen it. It looks like a better version of something I was going to try and do. I've experimented with duktape (ecmascript interpreter with LUA-style C routines for using it) and wanted a way to be able to interact with objects from C in a more natural way - the kind of interface libcello provides seems like it would work.
  • 1
    I have heard this sort of issue before with OOP --> Not knowing where to put things and what design patterns to use. And honestly dude it ain't your fault. Most people that write documentation for certain libs/apis/etc do so believing that you are FULLY aware of the architecture in which they designed the product. Which to a certain extent it make sense, if you want to develop for something you should be familiar with the overall project. But it has always annoyed me how often the docs of something(say android) would display 2 lines of code...ok...but...where do they go? So either you know enough of the framework to know where they go or how to structure them, or you go deep into the docs till you find out, making something simple an unintuitive time consuming task.

    There was a humble bundle a couple of weeks ago concerning design patterns. It was one of those funky o reilly books, but that book is reaaally good.
  • 1
    C++11/14/17 are great, you really shouldn't miss out on all the stuff that has been added to the language, it's much nicer to write in the "modern" style. I would say 2003 is seriously out of date, C++11 especially had a lot of major additions. Though the fundamentals are still the same(ish).
  • 0
    @RememberMe I might try and get my hands on an up-to-date copy of this book then. I've briefly read about some of the things that were added in the newer standards, but always thought that following older standards was a good habit (since some compilers might lag behind a bit with compatibility and I might one day be constrained by whatever standard an existing project has been written against).

    Even for C, I tend to compile against C99. I could go lower if I didn't want // comments and stdint.h :)

    I know it's not necessary for my own projects but anyway...
  • 0
    @nightowl as far as I know the major C++ compilers already implement the C++17 standard. The next version (20?) is already under discussion. C++11 and 14 have been supported for quite a while now.

    You are right about projects using older compilers. But C++11 was a fair old time ago and I think it's pretty safe to learn, been in production for quite a while now.

    Seriously. Do C++11 at least. It's a pretty big set of additions.
Add Comment