| |||||||||||||
|
| |||||||||||||
C++, the steampunk languageC++, the steampunk languagePosted Sep 14, 2009 17:37 UTC (Mon) by jgg (guest, #55211)In reply to: C++, the steampunk language by felixfix Parent article: Writing kernel modules in Haskell
> My experience with C++ is summed up by having replaced the simple malloc/free paradigm with THREE different ways to allocate : new/delete, new[]/delete[], and the original. Heaven help you if you mix them up. (I may have details wrong here; it's been a good long time since I had to deal with that muck.)
And C has an infinite variety of alloc/free functions..
Foo *foo = calloc(1,sizeof(Foo));
It is ever so much fun in mixing and matching them! Heaven help you if you use the incorrect free for the alloc that was chosen!!
new/new [] is actually a substantial increase in API uniformity compared to C and the multitude of libraries.
(Log in to post comments)
C++, the steampunk language Posted Sep 14, 2009 18:28 UTC (Mon) by felixfix (subscriber, #242) [Link]
Why are you dragging in library routines? They have nothing to do with core C.
C++, the steampunk language Posted Sep 14, 2009 20:06 UTC (Mon) by jgg (guest, #55211) [Link]
> Why are you dragging in library routines? They have nothing to do with core C.
Wow, that is just so pedantic. You do realize that the ISO C standard includes a library and that library includes functions like I described (fopen/fclose for instance). SUS adds more. It isn't like there is another way to do this ..
C++, the steampunk language Posted Sep 14, 2009 19:46 UTC (Mon) by bronson (subscriber, #4806) [Link]
Er, by definition C++ has all of C's "infinite variety" of alloc/free functions. Plus it adds more of its own (it's great fun watching people incorrectly override delete[]... from a distance).
If you say, "well, don't use X in C++" then I'll just say "don't use X in C."
C++, the steampunk language Posted Sep 15, 2009 14:33 UTC (Tue) by nix (subscriber, #2304) [Link]
Yes, but in C++ code you don't use that 'infinite variety': you wrap whateveritis up in an object and call the appropriate C allocation/freeing functions *once*, from the constructor and destructor of that object. Then you can consistently use the new/delete family of functions *everywhere* else. So the chaos of allocation and freeing functions that can easily be mixed up transforms into a single allocation/freeing function for all objects and a single one for all arrays of objects (which are sort of deprecated now 'cos the STL types are just as good). And it becomes impossible to use the wrong allocation and freeing functions anywhere, and memory leaks become harder to accidentally introduce as well (as the majority of object allocations are on the stack, so construction and destruction are automatic).
(The same applies to malloc()/free(): they shouldn't be used in well-written C++ programs, at all. They're not typesafe.)
|
|
||||||||||||