Hacker News new | past | comments | ask | show | jobs | submit login

You can forget to write a using statement. In C++ you can omit your destructor entirely if all the members are already RAII classes, whereas in C# you still need to write a .Dispose() method.

Memory management is by and far the vast majority of resource management in C++ for me, which C# takes care of with garbage collection - so I don't miss RAII too much in C#. But if you tried to give me a C++ with using blocks but no RAII (read: you gave me C) I'd scream.

RAII is no panacea[1] - I'd say C#'s manual resource burden without RAII is still less than C++'s with RAII. Which is why I don't miss it too much. But it'd still be a nice addition. And I missed it dearly during my initial adoption of C#.

[1] e.g. in C++, you still have to worry about reference cycles, implementing the RAII constructs in the first place if existing ones aren't suitable, ensuring parents are kept in scope while referencing children, etc..




> But if you tried to give me a C++ with using blocks but no RAII (read: you gave me C)

If you don't care about MSVC, IMHO new C code should be using the gcc cleanup extension: http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initial...


> If you don't care about MSVC

Even ignoring personal taste: I care about MSVC. I also care about clang. GCC is the one compiler I'm able to not care about.

> IMHO new C code should be using the gcc cleanup extension

Even if I didn't care about MSVC, I'd disagree.

I'm OK with extensions that are "harmless" in that the program will still run without them working if I #if them out on other compilers - error pragmas, deprecation annotations, static analysis hints, pre-C++11 override keywords, etc.

I'm not OK with self inflicting vendor lock-in for something as important as cleanup rely on a specific compiler's extensions - especially not when we have a perfectly standard, portable, significantly better tested (and thus less likely to have bugs) reasonable alternative in the form of C++ destructors.

If I'm not using C++ destructors, it's either because:

1) I'm doing small changes to an existing C project (in which case I'd be stylistically inconsistent with it's preferred cleanup patterns for minimal gain, since it almost certainly doesn't use the gcc cleanup extension)

or

2) because I can't rely on having decent C++ compilers on my target platforms (which means I can't rely on having GCC either, and thus can't rely on the gcc cleanup extension by definition.)


For what its worth, it is only MSVC without support. gcc compiler extensions are otherwise still rather portable. To clang and icc at least.


> For what its worth, it is only MSVC without support.

How recently? I've been enough versions back that clang documented pragmas haven't been available. The cleanup attribute... I can only find docs for GCC. Although I see LLVM bugs for it, so you're right about clang supporting it - at least on HEAD.

> gcc compiler extensions are otherwise still rather portable.

Portable or not, I'd say only about half the extensions I've sought out on clang have actually been available. If that.

> To clang and icc at least.

I should note in scenario #2 above I don't have these available either, since these are decent C++ compilers.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: