| |||||||||||||
|
| |||||||||||||
Writing kernel modules in HaskellWriting kernel modules in HaskellPosted Sep 14, 2009 0:17 UTC (Mon) by Ed_L. (guest, #24287)In reply to: Writing kernel modules in Haskell by bjacob Parent article: Writing kernel modules in Haskell
When you replace ptr = (T*)malloc(sizeof(T)); by ptr = new T;, you haven't hidden the memory allocation!evaluates "true" only when ptr = new T; is in fact replaceable by ptr = (T*)malloc(sizeof(T)); Are you certain you want to debate this one? ;)
(Log in to post comments)
C++, the steampunk language Posted Sep 14, 2009 7:24 UTC (Mon) by felixfix (subscriber, #242) [Link]
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.)
That is no way to design anything. I remember being disgusted with quite a few other things which I have gratefully mostly forgotten, Virtual should have been the default, I think, some pretense at giving you another knob to fine tune efficiency, You can define methods with a ridiculous number of keywords, more pretentious knobs. There are a zillion things you can do to hide the complexity of your class, to the point that there is no way to tell which operations are expensive, and debugging is a nightmare of chasing from one source file to another to see the secret details of classes to find out what little pitfalls were thrown in simply because they could be. People like to call Perl line noise, but C++ makes Perl look like a nice kindergarten language in the ways you can write write-only code, and every fool CS major thinks he is cool for doing so.
It reminds me of steampunk after it got past the initial fun stage: full of pointless knobs stuck on in an attempt to look like there's a reason behind them, when all they do is ... nothing except add clutter to make a fashion statement.
C++, the steampunk language Posted Sep 14, 2009 8:11 UTC (Mon) by alankila (subscriber, #47141) [Link]
C++ is, sadly, an expert's language. For good or bad, all that crap is there to squeeze out every last performance bit available -- if you know how to use them and judge them worth the effort. C++ had to beat C on its own turf, and thus every feature of C++ was compromised (or made completely optional) to ensure that C++ could compile at least as well as C.
From design point of view, C++ seems to be quite unpleasant to program with, so I agree with you on that one. I think I feel some kind of a personal laundry list banging the backside of my skull wanting to come out, but there's no point to it -- C++ is a lost cause, and as long as backwards compatibility is required there is not much improvement on the horizon.
C++, the steampunk language Posted Sep 14, 2009 16:17 UTC (Mon) by tjc (guest, #137) [Link] 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.Since you bring it up, do you happen to know why C++ requires a separate form (new[] v. new) for allocating and deallocating arrays? I'm aware that arrays are converted to pointers in parameter declarations and (most) expressions, but I don't think that's an issue here. There should be enough information in the symbol table to identify an object as an array and [de]allocate memory for it without resorting to a special form.
C++, the steampunk language Posted Sep 14, 2009 16:21 UTC (Mon) by avik (subscriber, #704) [Link]
delete[] needs to call the destructors of every element of the array, so it needs to know it is destroying an array.
C++, the steampunk language Posted Sep 14, 2009 16:30 UTC (Mon) by nye (guest, #51576) [Link]
Note that there is a bit more to it than that, otherwise it would be okay to use delete on an array of POD types, which it isn't (see my other post). That's undoubtedly the root reason though.
C++, the steampunk language Posted Sep 14, 2009 16:26 UTC (Mon) by nye (guest, #51576) [Link]
The first response to http://stackoverflow.com/questions/659270/why-is-there-a-... gives a reasonable answer.
C++, the steampunk language Posted Sep 14, 2009 17:43 UTC (Mon) by tjc (guest, #137) [Link] Thanks for the link. There is some other useful information on that page; see the post by Andrew Grant.IIUC the size of an object could be stored in the symbol table, but that would only work with objects within lexical scope-- a dynamically allocated object returned from a library function would still be a problem, since there is no portable way to attach size information to an object in C.
C++, the steampunk language Posted Sep 14, 2009 17:37 UTC (Mon) by jgg (guest, #55211) [Link]
> 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.
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.)
Writing kernel modules in Haskell Posted Sep 17, 2009 6:17 UTC (Thu) by pynm0001 (guest, #18379) [Link]
> > When you replace ptr = (T*)malloc(sizeof(T)); by ptr = new T;, you
> > haven't hidden the memory allocation!
> evaluates "true" only when ptr = new T; is in fact replaceable by ptr =
You mean as opposed to the more generic C:
ptr = (T*)malloc(sizeof(T));
that a C++ "ptr = new T;" is capable of expressing? You weren't going to
|
|
||||||||||||