On 2013-04-08 13:14, Manu wrote:

> D doesn't have a delete keyword, which is fairly important if you want
> to manually manage memory...

It's only deprecated (or possibly not even that yet). It's going to be replaced with a "destroy" function or similar. Then there's always "free".

-- 
/Jacob Carlborg

On Monday, 8 April 2013 at 12:22:04 UTC, Jacob Carlborg wrote:
> On 2013-04-08 12:57, Regan Heath wrote:
>
>> D should have a set of global allocator hooks.  If it did, you could
>> easily catch unexpected allocations in tight loops and realtime code.
>> If it did, GC-free D would be trivial - just replace the default GC
>> based allocator with a malloc/free one, or any other scheme you like.
>
> You can already do that:
>
> https://github.com/D-Programming-Language/druntime/tree/master/src/gcstub

Not the same. Using stub gc can help finding unneeded gc allocations, but it is not designed to be generic allocator - API kind of assumes it actually is a GC. It is a starting place, but not a solution.

On 2013-04-08 13:42, Dicebot wrote:

> You have got it wrong. I am comparing D executable with no runtime and
> standard library and C executable (-betterC -defaultlib=). And they are
> roughly the same, what is good, because indicates that there is nothing
> wrong with plain binary code gen.

Aha, I see, my bad.

-- 
/Jacob Carlborg

On Mon, 08 Apr 2013 13:28:20 +0100, Dicebot <m.strashun@gmail.com> wrote:

> On Monday, 8 April 2013 at 12:22:04 UTC, Jacob Carlborg wrote:
>> On 2013-04-08 12:57, Regan Heath wrote:
>>
>>> D should have a set of global allocator hooks.  If it did, you could
>>> easily catch unexpected allocations in tight loops and realtime code.
>>> If it did, GC-free D would be trivial - just replace the default GC
>>> based allocator with a malloc/free one, or any other scheme you like.
>>
>> You can already do that:
>>
>> https://github.com/D-Programming-Language/druntime/tree/master/src/gcstub
>
> Not the same. Using stub gc can help finding unneeded gc allocations, but it is not designed to be generic allocator - API kind of assumes it actually is a GC. It is a starting place, but not a solution.

True, but it does help Manu with his problem of detecting unexpected GC allocations in realtime loops though.

I've always hated the fact that C++ has 2 memory models new/delete and malloc/free and I've never liked new/delete because it doesn't allow anything like realloc - why can't I reallocate an array of char or wchar_t??

So, in my ideal world - if I needed manual memory management - I would want to be able to supply one set of allocator routines malloc, realloc, free (minimum) and have the runtime use those for all memory (heap only I guess) allocation.

So, new would obtain the object memory from my routine, then do it's own (placement) construction in that memory block - for example.

It would also be nice to be able to override new, for object tracking or similar purposes.

As has been said, we no longer have delete.  But, we might want to track GC collection or finalisation, again for object tracking or similar.  If we get destroy we might want to hook that also.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Monday, 8 April 2013 at 13:01:18 UTC, Regan Heath wrote:

> I've always hated the fact that C++ has 2 memory models new/delete and malloc/free and I've never liked new/delete because it doesn't allow anything like realloc - why can't I reallocate an array of char or wchar_t??
>

Try using malloc on something that contains a type with a constructor inside and you'll see. The constructor will not be called :)

malloc and friends are bad heritage due to C compatibility. I stay away from them.

On Mon, 08 Apr 2013 15:24:06 +0100, Minas Mina <minas_mina1990@hotmail.co.uk> wrote:

> On Monday, 8 April 2013 at 13:01:18 UTC, Regan Heath wrote:
>
>> I've always hated the fact that C++ has 2 memory models new/delete and malloc/free and I've never liked new/delete because it doesn't allow anything like realloc - why can't I reallocate an array of char or wchar_t??
>>
>
> Try using malloc on something that contains a type with a constructor inside and you'll see. The constructor will not be called :)

Are you talking about C++ or D here?

Memory allocation and object construction are separate concepts, malloc is for the former, not the latter.  "new" on the other hand ties them both together .. except that "placement" new can be used to separate them again :)

As in..

#include <stdlib.h>
#include <new.h>

class AA
{
public:
  AA()  { printf("AA\n"); }
  ~AA() { printf("~AA\n"); }
};

class BB
{
  AA a;
public:
  BB()  { printf("BB\n"); }
  ~BB() { printf("~BB\n"); }
};

void main()
{
  void *mem = malloc(sizeof(BB));
  BB *b = new (mem) BB();
  delete b;
}

The above outputs:
AA
BB
~BB
~AA

as expected.  malloc is used for memory allocation and placement new for construction.

> malloc and friends are bad heritage due to C compatibility. I stay away from them.

Mixing the 2 in the same piece of code is just asking for bugs - like trying to free something allocated with "new[]" for example.. *shudder*.  There is nothing "bad heritage" about malloc, or more especially realloc, you try doing the equivalent of realloc with new .. it's not possible.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Sorry, if it wasn't clear. I was talking about C++.

Even if you are not mixing the two, you can still get f*** up.

struct S
{
	S()
	{
		cout << "S()\n";
	}
};

int main()
{
	S *s = new S(); // constructor is called
	
	S *s2 = (S*)malloc(sizeof(S)); // constructor is NOT called
}

So you see an innocent struct type and you decide to use malloc instead of new... If it has a constructor/destructor/... those will not be called. It's just asking for trouble.

On 4/8/13 3:35 AM, Jacob Carlborg wrote:
> Scott Meyers had a talk about what he called red code/green code. It was
> supposed to statically enforce that green code cannot call red code.
> Then what is green code is completely up to you, if it's memory safe,
> thread safe, GC free or similar.
>
> I don't remember the conclusion and what could be implemented like this,
> but here's the talk:
>
> http://www.google.com/url?sa=t&rct=j&q=scott%20meyers%20red%20green%20code&source=web&cd=1&cad=rja&ved=0CCsQtwIwAA&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DJfu9Kc1D-gQ&ei=fXJiUfC3FuSB4gS41IHADQ&usg=AFQjCNGtKwLcr2jNjsC4RJ0_5k8WmAFzTw&bvm=bv.44770516,d.bGE

Article: http://www.artima.com/cppsource/codefeaturesP.html

It's one of Scott's better works but it went underappreciated. I think it would be worthwhile looking into how to implement such with D's features (notably attributes).


Andrei

On 4/8/13 4:31 AM, Manu wrote:
> That said, I'd still KILL for __forceinline! ;) ;)

Probably it's time to plop an enhancement request for an attribute that's recognized by the compiler.

Andrei

On 4/8/13 5:26 AM, Jacob Carlborg wrote:
> On 2013-04-08 10:31, Manu wrote:
>
>> D for embedded, like PROPER embedded (microcontrollers, or even
>> raspberry pi maybe?) is one area where most users would be happy to use
>> a custom druntime like the ones presented earlier in this thread where
>> it's strategically limited in scope and designed not to allocate.
>> 'Really embedded' software tends not to care so much about portability.
>> A bigger problem is D's executable size, which are rather 'plump' to be
>> frank :P
>> Last time I tried to understand this, one main issue was objectfactory,
>> and the inability to strip out unused classinfo structures (and other
>> junk). Any unused data should be stripped, but D somehow finds reason to
>> keep it all. Also, template usage needs to be relaxed. Over-use of
>> templates really bloats the exe. But it's not insurmountable, D could be
>> used in 'proper embedded'.
>
> I agree with the templates, Phobos is full of them. Heck, I created a
> D-Objective-C bridge that resulted in a 60MB GUI Hello World exeuctable.
> Full of template and virtual methods bloat.

Would be interesting to analyze where the bloat comes from.

Andrei