Hello, I'd like to introduce the "Unmanaged" framework.
It's a OOP library, strongly inspired by the Delphi/Pascal RTL.

Its main concept is to bypass the GC. From this statement, the library feaures:
- main unmanaged object and memory routines
- a parameterized list
- an ownership system (used to automate the destroying of object)
- a parentship system
- a serialization system...
- etc work in progress.

This library is developped in the same time I learn D, but comming from Delphi, it's inspired by its class system  (but it's not a copy at all).
Unmanaged is tested under win32 an linux64. Basic build scripts are provided for both systems and code review are welcome.

you can track the project on github:

https://github.com/BBasile/Unmanaged

Hey.

On Wednesday, 13 March 2013 at 16:20:08 UTC, D-ratiseur wrote:
> Hello, I'd like to introduce the "Unmanaged" framework.
> It's a OOP library, strongly inspired by the Delphi/Pascal RTL.
>
> Its main concept is to bypass the GC. From this statement, the library feaures:
> - main unmanaged object and memory routines
> - a parameterized list
> - an ownership system (used to automate the destroying of object)
> - a parentship system
> - a serialization system...
> - etc work in progress.
>
> This library is developped in the same time I learn D, but comming from Delphi, it's inspired by its class system  (but it's not a copy at all).
> Unmanaged is tested under win32 an linux64. Basic build scripts are provided for both systems and code review are welcome.
>
> you can track the project on github:
>
> https://github.com/BBasile/Unmanaged
>
> Hey.

Pascal case identifiers <3 - Looks great!

On Wednesday, 13 March 2013 at 16:20:08 UTC, D-ratiseur wrote:
> Hello, I'd like to introduce the "Unmanaged" framework.
> It's a OOP library, strongly inspired by the Delphi/Pascal RTL.
>
> Its main concept is to bypass the GC. From this statement, the library feaures:
> - main unmanaged object and memory routines
> - a parameterized list
> - an ownership system (used to automate the destroying of object)
> - a parentship system
> - a serialization system...
> - etc work in progress.
>
> This library is developped in the same time I learn D, but comming from Delphi, it's inspired by its class system  (but it's not a copy at all).
> Unmanaged is tested under win32 an linux64. Basic build scripts are provided for both systems and code review are welcome.
>
> you can track the project on github:
>
> https://github.com/BBasile/Unmanaged
>
> Hey.

This looks nice. Like really, really nice. Much more appealing to
me than the std library to be honest.

On Wednesday, 13 March 2013 at 16:20:08 UTC, D-ratiseur wrote:
> Hello, I'd like to introduce the "Unmanaged" framework.
> It's a OOP library, strongly inspired by the Delphi/Pascal RTL.
>
> Its main concept is to bypass the GC. From this statement, the library feaures:
> - main unmanaged object and memory routines
> - a parameterized list
> - an ownership system (used to automate the destroying of object)
> - a parentship system
> - a serialization system...
> - etc work in progress.
>
> This library is developped in the same time I learn D, but comming from Delphi, it's inspired by its class system  (but it's not a copy at all).
> Unmanaged is tested under win32 an linux64. Basic build scripts are provided for both systems and code review are welcome.
>
> you can track the project on github:
>
> https://github.com/BBasile/Unmanaged
>
> Hey.

Can you give some code sample so we can have an idea of what it
is ?

On Wednesday, 13 March 2013 at 18:01:20 UTC, deadalnix wrote:
> On Wednesday, 13 March 2013 at 16:20:08 UTC, D-ratiseur wrote:
>> Hello, I'd like to introduce the "Unmanaged" framework.
>> It's a OOP library, strongly inspired by the Delphi/Pascal RTL.
>>
>> Its main concept is to bypass the GC. From this statement, the library feaures:
>> - main unmanaged object and memory routines
>> - a parameterized list
>> - an ownership system (used to automate the destroying of object)
>> - a parentship system
>> - a serialization system...
>> - etc work in progress.
>>
>> This library is developped in the same time I learn D, but comming from Delphi, it's inspired by its class system  (but it's not a copy at all).
>> Unmanaged is tested under win32 an linux64. Basic build scripts are provided for both systems and code review are welcome.
>>
>> you can track the project on github:
>>
>> https://github.com/BBasile/Unmanaged
>>
>> Hey.
>
> Can you give some code sample so we can have an idea of what it
> is ?

Not really, a sample woulds look like one of the unittest. But looking at the previous answer, it's not like the D runtime, it's more a "framework" based on the minimal dmd distribution (so some std functions are used, some strings stuff,some error suff,...).It's not a RTL (run time library, such as phobos), it's a framework which provides a way to make trees, to serialize and uppon everything to bypass the garbage collector. It's more focused on the structure and it's definitively not a replacement to something.

On 03/13/2013 11:30 AM, D-ratiseur wrote:

> uppon everything to bypass the garbage
> collector.

In that case, I call foul.

FAddr.length = FAddr.length + 1;

types.d#L281

Wait, what? You're using classes everywhere and.. ohhhhhhh. you're overriding new. Nifty. Don't know if that's been deprecated or not, but I'm pretty sure Andrei hates it and wants it to die.

The delete statement is deprecated in favor of object.destroy or something.

For struct ULongRec, shouldn't some of your twiddly stuff be wrapped in version(LittleEndian) ?

Am 14.03.2013 03:03, schrieb Ellery Newcomer:
> On 03/13/2013 11:30 AM, D-ratiseur wrote:
> 
>> uppon everything to bypass the garbage
>> collector.
> 
> In that case, I call foul.
> 
> FAddr.length = FAddr.length + 1;
> 
> types.d#L281
> 
> Wait, what? You're using classes everywhere and.. ohhhhhhh. you're overriding new. Nifty. Don't know if that's been deprecated or not, but I'm pretty sure Andrei hates it and wants it to die.

Afaik it is deprecated which really sucks imo.

> The delete statement is deprecated in favor of object.destroy or something.

object.destroy()(UFCS) and clib.free(object) (If it was allocated with
malloc/calloc and friends)

On Friday, 15 March 2013 at 10:23:05 UTC, David wrote:
> Afaik it is deprecated which really sucks imo.

I don't know why the new operator is so important to some people. If templates had been in C++ before classes, this operator would probably never have existed.

> object.destroy()(UFCS) and clib.free(object) (If it was allocated with
> malloc/calloc and friends)

A pair of templated functions dealing with C++ style new/delete can be trivially composed using malloc-emplace and destroy-free.

On Fri, 15 Mar 2013 13:11:13 +0100
"Jakob Ovrum" <jakobovrum@gmail.com> wrote:

> On Friday, 15 March 2013 at 10:23:05 UTC, David wrote:
> > Afaik it is deprecated which really sucks imo.
> 
> I don't know why the new operator is so important to some people. If templates had been in C++ before classes, this operator would probably never have existed.
> 

I'm not so sure that it's "new is important" so much as:

1. The custom allocator stuff isn't ready yet.

2. "Meh, 'new' never hurt me, what's with all the hate?"

On Thursday, 14 March 2013 at 02:03:56 UTC, Ellery Newcomer wrote:
> On 03/13/2013 11:30 AM, D-ratiseur wrote:
>
>> uppon everything to bypass the garbage
>> collector.
>
> In that case, I call foul.
>
> FAddr.length = FAddr.length + 1;
>
> types.d#L281
>
> Wait, what? You're using classes everywhere and.. ohhhhhhh. you're overriding new. Nifty. Don't know if that's been deprecated or not, but I'm pretty sure Andrei hates it and wants it to die.
>
> The delete statement is deprecated in favor of object.destroy or something.
>
> For struct ULongRec, shouldn't some of your twiddly stuff be wrapped in version(LittleEndian) ?

new is overriden in TUObject because the purpose of the library is to bypass the garbage collector and  to bypass the GC you have to override new and delete.(at least according to the manual: articles,mem managment).

And yes, classes are used everywhere. I've read in the D guidlines that interdependent classes should be avoid (IIRC the reason for this is to make the maintenance easyer)...but it's just like that, by design. The classes hold some data and some methods usefull for their descendants...don't they ?

About the ULongRec, yes maybe...

But I recognize that I've been a bit "overenthusiastic" in this announce, I should have waited a few weeks...Anyway I'll finish this lib, everything is here, the class structure is clear.