Comments on: Ready, Set, Allocate! (Part 1) [...] shown as crucial while testing. Basic allocator took from here is not thread-safe at all. After making thread split in application I decided to add synchronization [...] [...] shown as crucial while testing. Basic allocator took from here is not thread-safe at all. After making thread split in application I decided to add synchronization [...]

]]>
By: Paul Laska/2011/04/11/ready-set-allocate-part-1/#comment-4097 Paul Laska Sun, 15 May 2011 10:58:51 +0000 Hi Paul, I'm Italian and I can translate that for you, he's talking about your malloc redefinition, explaining why it is more dangerous than it looks. Normally, as you said in reply to him, the redefinition would just lead to a compilation error, but in the case you have a static lib like the "Foo" example he uses, you will have that class using the real malloc for allocation, because it's in the .cpp file that was copiled with the lib, and your malloc macro ( #define malloc( uSize ) my_malloc( uSize, 4 ) ) for deallocation, that's instead in the .h file, and that can lead to some nasty to find bugs. It think he's half right but clearly this thing is outside the scope of your article (wich is very interesting, I'm following you on twitter and I'm reading every bit of it, I'm new to this kind of stuff). His point is "never redefine STL stuff" Hi Paul, I’m Italian and I can translate that for you, he’s talking about your malloc redefinition, explaining why it is more dangerous than it looks. Normally, as you said in reply to him, the redefinition would just lead to a compilation error, but in the case you have a static lib like the “Foo” example he uses, you will have that class using the real malloc for allocation, because it’s in the .cpp file that was copiled with the lib, and your malloc macro ( #define malloc( uSize ) my_malloc( uSize, 4 ) ) for deallocation, that’s instead in the .h file, and that can lead to some nasty to find bugs.

It think he’s half right but clearly this thing is outside the scope of your article (wich is very interesting, I’m following you on twitter and I’m reading every bit of it, I’m new to this kind of stuff).

His point is “never redefine STL stuff”

]]>
By: Paul Laska/2011/04/11/ready-set-allocate-part-1/#comment-3455 Paul Laska Mon, 02 May 2011 18:52:50 +0000 [...] scorsa ho letto la seconda parte di un simpatico articolo sull’allocazioni su AltDevBlogADay (parte1, parte2). Ad un certo punto però ho visto uno riga di codice che mi ha fatto balzare sulla sedia. [...] [...] scorsa ho letto la seconda parte di un simpatico articolo sull’allocazioni su AltDevBlogADay (parte1, parte2). Ad un certo punto però ho visto uno riga di codice che mi ha fatto balzare sulla sedia. [...]

]]>
By: Paul Laska/2011/04/11/ready-set-allocate-part-1/#comment-2815 Paul Laska Fri, 15 Apr 2011 16:01:02 +0000 ).

Cheers,
-Paul

]]>
By: Bart Siwek/2011/04/11/ready-set-allocate-part-1/#comment-2813 Bart Siwek Fri, 15 Apr 2011 15:09:53 +0000 Hi Paul, That explains it perfectly. I look forward to reading the rest of the posts! Hi Paul,

That explains it perfectly. I look forward to reading the rest of the posts!

]]>
By: Paul Laska/2011/04/11/ready-set-allocate-part-1/#comment-2589 Paul Laska Mon, 11 Apr 2011 17:30:33 +0000 I'm a total newby when it comes to any kind of low-level memory allocation (which is something I'm trying to address, hence reading your article!), so I have a (large-ish) question: How did you choose 4 bytes per tracking unit? I understand the rest of the calculations but you seemed to pull 4 bytes per tracking unit from nowhere and I was wondering if this is from experience or is just an arbitrary number. If I were to choose 8 bytes for a tracking unit, this would reduce the number of tracking units to 128 (although, obviously not the amount of memory they take up) - would there be any benefit to increasing the size of tracking units? I’m a total newby when it comes to any kind of low-level memory allocation (which is something I’m trying to address, hence reading your article!), so I have a (large-ish) question:

How did you choose 4 bytes per tracking unit? I understand the rest of the calculations but you seemed to pull 4 bytes per tracking unit from nowhere and I was wondering if this is from experience or is just an arbitrary number. If I were to choose 8 bytes for a tracking unit, this would reduce the number of tracking units to 128 (although, obviously not the amount of memory they take up) – would there be any benefit to increasing the size of tracking units?

]]>
By: Peter Mackay/2011/04/11/ready-set-allocate-part-1/#comment-2572 Peter Mackay Mon, 11 Apr 2011 09:15:47 +0000