Community

Nick Sabalausky wrote:
> I've found that, unfortunately, to not be quite enough. Not because of any
> limitations of D/Tango/Mango, but because:
>
> #1: In the commercial world there are a lot of times when you, as the
> programmer, have little to no say on how the server is set up and what
> languages are available (for instance, I've done plenty of PHP and VBScript,
> but never by choice).
>
True. And that's why I search opportunity to get around such limitations.
> #2: You have basically no control over the client-side environment, so for
> that you're still stuck with de-facto standards like ECMAScript, and a lack
> of the upcoming/proposed improvements to (X)HTML (things I've thought should
> have been in HTML all along...*grumble*).
>
Also true. JavaScript is necessary to make dhtml and ajax and I see no
way to get rid of it for now (only I can do is use it when truly needed).
> [...] Pasting together SQL snippets is just plain ugly, and why dynamically
> generate code just for the DBMS to go and parse it? I mean, geez, just cut
> the middleman and pass the request directly. LINQ is better, but I'm still
> not convinced it's the right approach. TSQL stored procedures are something
> I'd rather, well, just write in a more "normal" language. And then, of
> course, there's the bizarre "insert" vs. "update" syntax inconsistencies and
> general incompatibilities across vendors (ex: insert a row and retreive the
> auto-gen id <- which is really a rather common thing to need to do,
> particularly if you've got any foreign keys in the DB design, which again is
> rather common).
>
The LINQ project looks ok. However I don't use the Microsoft software at
all.
> To be fair though, I have to say that without some of the advanced features
> we've been starting to see in languages like D, C#, Python and Ruby, using
> an API for any non-trivial queries could potentially get ugly.
I find non-trivial SQL queries as ugly as hell. I'd rather see it in OO way.
Cheers

"Danny Wilson" <bluezenix@gmail.com> wrote in message
news:op.uj26ncatbmuhq1@danny-wilsons-ep45-ds4.local...
> Op Tue, 04 Nov 2008 02:55:41 +0100 schreef Nick Sabalausky <a@a.a>:
>
>> This is why I've recently been getting interested in high-level language
>> translation, and have been playing around with writing such a tool. I'd
>> like
>> to be able to write code in a sensible language like D and just translate
>> that into whatever horrible scripting language the
>> sysadmin/netadmin/browser-vendor decided would be suitable.
>
>
> That sensible language already exists! Be sure to check out: haxe.org
That looks pretty good (I've come across it once before), but what I had in
mind was a little more universal (and perhaps, more experimental or even
naive ;) ). What I'm planing to experiment with is having a basic
compiler/translator program which accepts language plugins that describe
both how to parse the language and how to output it. Then the tool would go
something like "Input HLL -> Input AST -> Intermediate AST -> Output AST ->
Output HLL". Toss in a whole bunch of language plugins and, assuming it
could actually be pulled off, what you'd have is something like HaXe except:
- ASP would be supported (important for me, a lot of clients are MS houses).
- The programmer (or tech lead, if applicable) could chose what they
consider a sensible language (For instance, HaXe does look pretty good from
what I've seen, but I prefer C-style variable declarations over HaXe's
ECMAScript3/4-style declarations (though I could certainly live with them)).
- HLLs and platforms, in general, would be much more divorced than they are
today. Much less chance of the choice in platform forcing/limiting your hand
in the choice of language. HaXe just simply gives you one extra choice, and
even then, only when you're targeting ECMAScript, Flash, PHP or some rare
system that actually has Neko.
- It would have a name that isn't mixed case and isn't inconsistent between
spelling and pronunciation ;)

Nick Sabalausky wrote:
> IIRC, you just go into "extern (C) int main(size_t argc, char **argv)" in
> the internal portion of phobos/tango/druntime or wherever it lives now and
> comment-out the calls to "gc_init()" and "gc_term()". You might also need to
> call "gc.disable()" or something (don't really remember). And then if you
> still want to use "new" and/or "delete" with your own memory manager, you
> can use D's class allocator and deallocator feature
> (http://www.digitalmars.com/d/1.0/class.html#allocators). I assume you could
> probably plug those class allocators/deallocators directly into the internal
> object class if you wanted.
That would work in all cases and be the only way if using D1+Phobos, but
for Tango or D2/druntime, the better way would be
http://www.dsource.org/projects/tango/browser/trunk/lib/gc/stub . The
way you described would still link in the old GC and possibly generate
erroneous calls to it.

Op Tue, 04 Nov 2008 21:36:23 +0100 schreef Nick Sabalausky <a@a.a>:
> That looks pretty good (I've come across it once before), but what I had
> in
> mind was a little more universal (and perhaps, more experimental or even
> naive ;) ). What I'm planing to experiment with is having a basic
> compiler/translator program which accepts language plugins that describe
> both how to parse the language and how to output it. Then the tool would
> go
> something like "Input HLL -> Input AST -> Intermediate AST -> Output AST
> ->
> Output HLL". Toss in a whole bunch of language plugins and, assuming it
> could actually be pulled off, what you'd have is something like HaXe
> except:
Except it isn't a language anymore, but more like a complete compiler
framework ;-)
> - ASP would be supported (important for me, a lot of clients are MS
> houses).
>
> - The programmer (or tech lead, if applicable) could chose what they
> consider a sensible language (For instance, HaXe does look pretty good
> from
> what I've seen, but I prefer C-style variable declarations over HaXe's
> ECMAScript3/4-style declarations (though I could certainly live with
> them)).
>
> - HLLs and platforms, in general, would be much more divorced than they
> are
> today. Much less chance of the choice in platform forcing/limiting your
> hand
> in the choice of language. HaXe just simply gives you one extra choice,
> and
> even then, only when you're targeting ECMAScript, Flash, PHP or some rare
> system that actually has Neko.
>
Well PHP is a pretty recent addition. Someone has been working on MSIL
output to target .NET (and thus Silverlight aswell). Someone else has
announced he's working on C++ output aswell.
The compiler is written in OCaml and very fast. Due to haXe's nature of
targetting different platforms, it is already setup pretty pluggable.
But yea I'd like some additions to haXe myself, like a stronger template
system (yay D!) for starters. :-)
> - It would have a name that isn't mixed case and isn't inconsistent
> between
> spelling and pronunciation ;)
>
But at least its fairly unique. Unlike some single letter which also
happens to be the first letter of my name .. hehe.
- Danny Wilson

"Danny Wilson" <bluezenix@gmail.com> wrote in message
news:op.uj36sqczbmuhq1@danny-wilsons-ep45-ds4.local...
> Op Tue, 04 Nov 2008 21:36:23 +0100 schreef Nick Sabalausky <a@a.a>:
>
>> That looks pretty good (I've come across it once before), but what I had
>> in
>> mind was a little more universal (and perhaps, more experimental or even
>> naive ;) ). What I'm planing to experiment with is having a basic
>> compiler/translator program which accepts language plugins that describe
>> both how to parse the language and how to output it. Then the tool would
>> go
>> something like "Input HLL -> Input AST -> Intermediate AST -> Output
>> ST ->
>> Output HLL". Toss in a whole bunch of language plugins and, assuming it
>> could actually be pulled off, what you'd have is something like HaXe
>> except:
>
> Except it isn't a language anymore, but more like a complete compiler
> framework ;-)
>
Yes, but I consider that a good thing because I view the goals of
"create/choose a good language" and "allow an alternate language for a
particular platform" to be separate problems that, ideally, should have
separate (but compatible) solutions. HaXe mixes the two: it lets you choose
an alternate language for browser-scripting, Flash, and web
server-scripting, but only if the language you choose is the one language
that the HaXe project provides for you.
Granted, I'm not saying HaXe is a bad thing. I'm quite tempted to use it in
the meantime before my project actually bears any fruit (*if* it ever does),
particularly if ASP/VBScript, ASP.NET/VB.NET, and ASP.NET/C# backends are
ever created for it.
>
>> - ASP would be supported (important for me, a lot of clients are MS
>> houses).
>>
>> - The programmer (or tech lead, if applicable) could chose what they
>> consider a sensible language (For instance, HaXe does look pretty good
>> from
>> what I've seen, but I prefer C-style variable declarations over HaXe's
>> ECMAScript3/4-style declarations (though I could certainly live with
>> them)).
>>
>> - HLLs and platforms, in general, would be much more divorced than they
>> are
>> today. Much less chance of the choice in platform forcing/limiting your
>> hand
>> in the choice of language. HaXe just simply gives you one extra choice,
>> and
>> even then, only when you're targeting ECMAScript, Flash, PHP or some rare
>> system that actually has Neko.
>>
>
> Well PHP is a pretty recent addition. Someone has been working on MSIL
> output to target .NET (and thus Silverlight aswell). Someone else has
> announced he's working on C++ output aswell.
> The compiler is written in OCaml and very fast. Due to haXe's nature of
> targetting different platforms, it is already setup pretty pluggable.
Good to know :)
>
> But yea I'd like some additions to haXe myself, like a stronger template
> system (yay D!) for starters. :-)
>
>
>> - It would have a name that isn't mixed case and isn't inconsistent
>> between
>> spelling and pronunciation ;)
>>
>
> But at least its fairly unique. Unlike some single letter which also
> happens to be the first letter of my name .. hehe.
>
Very true!

"Nick Sabalausky" <a@a.a> wrote in message
news:gep0ej$232$1@digitalmars.com...
> "Tony" <tonytech08@gmail.com> wrote in message
> news:geogvj$1p5r$2@digitalmars.com...
>>
>> "Robert Fraser" <fraserofthenight@gmail.com> wrote in message
>> news:geo5p6$12gk$1@digitalmars.com...
>>> Tony wrote:
>>>> (one HAS to use GC with D, right?)
>>>
>>> No. Well, the compiler generates calls to allocate & free memory, but
>>> you can replace those calls with whatever you want. See Tango's
>>> (druntime's) "stub" GC, which just reroutes compiler-generated calls to
>>> GC methods to malloc() and free(). You can implement your own "GC" or
>>> whatever management scheme you want (in fact, if you're writing, say, a
>>> device driver in D, you would want to use a custom allocator like this
>>> and not the built-in GC).
>>
>> Please clarify for me the mem mgmt of D: is the garbage collector
>> optional or not?
>
> Yes, it can be ripped out, replaced, whatever. It's slightly hacky, but
> it's perfectly doable. I did it a few years ago when I was playing around
> with using GDC with DevKitARM for GBA.
>
> IIRC, you just go into "extern (C) int main(size_t argc, char **argv)" in
> the internal portion of phobos/tango/druntime or wherever it lives now and
> comment-out the calls to "gc_init()" and "gc_term()". You might also need
> to call "gc.disable()" or something (don't really remember). And then if
> you still want to use "new" and/or "delete" with your own memory manager,
> you can use D's class allocator and deallocator feature
> (http://www.digitalmars.com/d/1.0/class.html#allocators). I assume you
> could probably plug those class allocators/deallocators directly into the
> internal object class if you wanted.
It sounds like a lot of work and new stuff to learn about the
implementation. Let's face it, I'm not going to use D since it doesn't offer
me anything over C++ that I want. The main thing I may like about D is that
it makes the effort to make implementation of the language easier, and that,
I think, is very key. I am here to look for features I would put in a new
language, though that may be too large of an endeavor for someone my age.
Tony

"Tony" <tonytech08@gmail.com> wrote in message
news:gerdem$rc4$1@digitalmars.com...
>
> "Nick Sabalausky" <a@a.a> wrote in message
> news:gep0ej$232$1@digitalmars.com...
>> "Tony" <tonytech08@gmail.com> wrote in message
>> news:geogvj$1p5r$2@digitalmars.com...
>>>
>>> "Robert Fraser" <fraserofthenight@gmail.com> wrote in message
>>> news:geo5p6$12gk$1@digitalmars.com...
>>>> Tony wrote:
>>>>> (one HAS to use GC with D, right?)
>>>>
>>>> No. Well, the compiler generates calls to allocate & free memory, but
>>>> you can replace those calls with whatever you want. See Tango's
>>>> (druntime's) "stub" GC, which just reroutes compiler-generated calls to
>>>> GC methods to malloc() and free(). You can implement your own "GC" or
>>>> whatever management scheme you want (in fact, if you're writing, say, a
>>>> device driver in D, you would want to use a custom allocator like this
>>>> and not the built-in GC).
>>>
>>> Please clarify for me the mem mgmt of D: is the garbage collector
>>> optional or not?
>>
>> Yes, it can be ripped out, replaced, whatever. It's slightly hacky, but
>> it's perfectly doable. I did it a few years ago when I was playing around
>> with using GDC with DevKitARM for GBA.
>>
>> IIRC, you just go into "extern (C) int main(size_t argc, char **argv)" in
>> the internal portion of phobos/tango/druntime or wherever it lives now
>> and comment-out the calls to "gc_init()" and "gc_term()". You might also
>> need to call "gc.disable()" or something (don't really remember). And
>> then if you still want to use "new" and/or "delete" with your own memory
>> manager, you can use D's class allocator and deallocator feature
>> (http://www.digitalmars.com/d/1.0/class.html#allocators). I assume you
>> could probably plug those class allocators/deallocators directly into the
>> internal object class if you wanted.
>
> It sounds like a lot of work and new stuff to learn about the
> implementation. Let's face it, I'm not going to use D since it doesn't
> offer me anything over C++ that I want. The main thing I may like about D
> is that it makes the effort to make implementation of the language easier,
> and that, I think, is very key. I am here to look for features I would put
> in a new language, though that may be too large of an endeavor for someone
> my age.
>
> Tony
>
If you've already got your own full-fleged, reliable, memory management
system, plugging it into D via the methods Robert and I pointed out is
nothing by comparison.

"Nick Sabalausky" <a@a.a> wrote in message
news:gergn9$109b$1@digitalmars.com...
> "Tony" <tonytech08@gmail.com> wrote in message
> news:gerdem$rc4$1@digitalmars.com...
>>
>> "Nick Sabalausky" <a@a.a> wrote in message
>> news:gep0ej$232$1@digitalmars.com...
>>> "Tony" <tonytech08@gmail.com> wrote in message
>>> news:geogvj$1p5r$2@digitalmars.com...
>>>>
>>>> "Robert Fraser" <fraserofthenight@gmail.com> wrote in message
>>>> news:geo5p6$12gk$1@digitalmars.com...
>>>>> Tony wrote:
>>>>>> (one HAS to use GC with D, right?)
>>>>>
>>>>> No. Well, the compiler generates calls to allocate & free memory, but
>>>>> you can replace those calls with whatever you want. See Tango's
>>>>> (druntime's) "stub" GC, which just reroutes compiler-generated calls
>>>>> to GC methods to malloc() and free(). You can implement your own "GC"
>>>>> or whatever management scheme you want (in fact, if you're writing,
>>>>> say, a device driver in D, you would want to use a custom allocator
>>>>> like this and not the built-in GC).
>>>>
>>>> Please clarify for me the mem mgmt of D: is the garbage collector
>>>> optional or not?
>>>
>>> Yes, it can be ripped out, replaced, whatever. It's slightly hacky, but
>>> it's perfectly doable. I did it a few years ago when I was playing
>>> around with using GDC with DevKitARM for GBA.
>>>
>>> IIRC, you just go into "extern (C) int main(size_t argc, char **argv)"
>>> in the internal portion of phobos/tango/druntime or wherever it lives
>>> now and comment-out the calls to "gc_init()" and "gc_term()". You might
>>> also need to call "gc.disable()" or something (don't really remember).
>>> And then if you still want to use "new" and/or "delete" with your own
>>> memory manager, you can use D's class allocator and deallocator feature
>>> (http://www.digitalmars.com/d/1.0/class.html#allocators). I assume you
>>> could probably plug those class allocators/deallocators directly into
>>> the internal object class if you wanted.
>>
>> It sounds like a lot of work and new stuff to learn about the
>> implementation. Let's face it, I'm not going to use D since it doesn't
>> offer me anything over C++ that I want. The main thing I may like about D
>> is that it makes the effort to make implementation of the language
>> easier, and that, I think, is very key. I am here to look for features I
>> would put in a new language, though that may be too large of an endeavor
>> for someone my age.
>>
>> Tony
>>
>
> If you've already got your own full-fleged, reliable, memory management
> system, plugging it into D via the methods Robert and I pointed out is
> nothing by comparison.
If I could do something with the object model, and or if the compiler is
open source, I would maybe look at the implementation as a potential
starting point or learning tool. Every time I've considered using existing
code though, I have ended up just starting with a clean slate for a number
of reasons. For now, I'm going to evolve my framework a bit more and produce
some programs. I'm keeping away from "advanced features" of existing
languages as much as possible so as not to be tied to them. So far I've not
found problem doing that. Error handling is the worst beast that I don't
have completely slain yet. Generics and mem mgmt I have under control. I
feel a bit limited by existing languages object models, that's probably the
key reason why I'd like to invent a new language, be it for my own use or
for more widespread use. Having full control of a language and it's
implementation is nothing to sneeze at either, but taking advantage of that
probably takes quite a bit of labor (more than one developer).
Tony

"Tony" <tonytech08@gmail.com> wrote in message
news:gevmuc$11hb$1@digitalmars.com...
>
> "Nick Sabalausky" <a@a.a> wrote in message
> news:gergn9$109b$1@digitalmars.com...
>> "Tony" <tonytech08@gmail.com> wrote in message
>> news:gerdem$rc4$1@digitalmars.com...
>>>
>>> "Nick Sabalausky" <a@a.a> wrote in message
>>> news:gep0ej$232$1@digitalmars.com...
>>>> "Tony" <tonytech08@gmail.com> wrote in message
>>>> news:geogvj$1p5r$2@digitalmars.com...
>>>>>
>>>>> "Robert Fraser" <fraserofthenight@gmail.com> wrote in message
>>>>> news:geo5p6$12gk$1@digitalmars.com...
>>>>>> Tony wrote:
>>>>>>> (one HAS to use GC with D, right?)
>>>>>>
>>>>>> No. Well, the compiler generates calls to allocate & free memory, but
>>>>>> you can replace those calls with whatever you want. See Tango's
>>>>>> (druntime's) "stub" GC, which just reroutes compiler-generated calls
>>>>>> to GC methods to malloc() and free(). You can implement your own "GC"
>>>>>> or whatever management scheme you want (in fact, if you're writing,
>>>>>> say, a device driver in D, you would want to use a custom allocator
>>>>>> like this and not the built-in GC).
>>>>>
>>>>> Please clarify for me the mem mgmt of D: is the garbage collector
>>>>> optional or not?
>>>>
>>>> Yes, it can be ripped out, replaced, whatever. It's slightly hacky, but
>>>> it's perfectly doable. I did it a few years ago when I was playing
>>>> around with using GDC with DevKitARM for GBA.
>>>>
>>>> IIRC, you just go into "extern (C) int main(size_t argc, char **argv)"
>>>> in the internal portion of phobos/tango/druntime or wherever it lives
>>>> now and comment-out the calls to "gc_init()" and "gc_term()". You might
>>>> also need to call "gc.disable()" or something (don't really remember).
>>>> And then if you still want to use "new" and/or "delete" with your own
>>>> memory manager, you can use D's class allocator and deallocator feature
>>>> (http://www.digitalmars.com/d/1.0/class.html#allocators). I assume you
>>>> could probably plug those class allocators/deallocators directly into
>>>> the internal object class if you wanted.
>>>
>>> It sounds like a lot of work and new stuff to learn about the
>>> implementation. Let's face it, I'm not going to use D since it doesn't
>>> offer me anything over C++ that I want. The main thing I may like about
>>> D is that it makes the effort to make implementation of the language
>>> easier, and that, I think, is very key. I am here to look for features I
>>> would put in a new language, though that may be too large of an endeavor
>>> for someone my age.
>>>
>>> Tony
>>>
>>
>> If you've already got your own full-fleged, reliable, memory management
>> system, plugging it into D via the methods Robert and I pointed out is
>> nothing by comparison.
>
> If I could do something with the object model, and or if the compiler is
> open source, I would maybe look at the implementation as a potential
> starting point or learning tool. Every time I've considered using existing
> code though, I have ended up just starting with a clean slate for a number
> of reasons. For now, I'm going to evolve my framework a bit more and
> produce some programs. I'm keeping away from "advanced features" of
> existing languages as much as possible so as not to be tied to them. So
> far I've not found problem doing that. Error handling is the worst beast
> that I don't have completely slain yet. Generics and mem mgmt I have under
> control. I feel a bit limited by existing languages object models, that's
> probably the key reason why I'd like to invent a new language, be it for
> my own use or for more widespread use. Having full control of a language
> and it's implementation is nothing to sneeze at either, but taking
> advantage of that probably takes quite a bit of labor (more than one
> developer).
>
> Tony
Out of curiosity, what benefits are you going for by using your own memory
management system instead of just a built-in GC? From some of your comments
in this thread, I'm guessing it has to do with either game development or
limited-memory/speed embedded devices (or both in the case of handheld or
retro gaming). I can see how those could provide reasons for a custom memory
manager.

"Nick Sabalausky" <a@a.a> wrote in message
news:gevou0$15j4$1@digitalmars.com...
> "Tony" <tonytech08@gmail.com> wrote in message
> news:gevmuc$11hb$1@digitalmars.com...
>>
>> "Nick Sabalausky" <a@a.a> wrote in message
>> news:gergn9$109b$1@digitalmars.com...
>>> "Tony" <tonytech08@gmail.com> wrote in message
>>> news:gerdem$rc4$1@digitalmars.com...
>>>>
>>>> "Nick Sabalausky" <a@a.a> wrote in message
>>>> news:gep0ej$232$1@digitalmars.com...
>>>>> "Tony" <tonytech08@gmail.com> wrote in message
>>>>> news:geogvj$1p5r$2@digitalmars.com...
>>>>>>
>>>>>> "Robert Fraser" <fraserofthenight@gmail.com> wrote in message
>>>>>> news:geo5p6$12gk$1@digitalmars.com...
>>>>>>> Tony wrote:
>>>>>>>> (one HAS to use GC with D, right?)
>>>>>>>
>>>>>>> No. Well, the compiler generates calls to allocate & free memory,
>>>>>>> but you can replace those calls with whatever you want. See Tango's
>>>>>>> (druntime's) "stub" GC, which just reroutes compiler-generated calls
>>>>>>> to GC methods to malloc() and free(). You can implement your own
>>>>>>> "GC" or whatever management scheme you want (in fact, if you're
>>>>>>> writing, say, a device driver in D, you would want to use a custom
>>>>>>> allocator like this and not the built-in GC).
>>>>>>
>>>>>> Please clarify for me the mem mgmt of D: is the garbage collector
>>>>>> optional or not?
>>>>>
>>>>> Yes, it can be ripped out, replaced, whatever. It's slightly hacky,
>>>>> but it's perfectly doable. I did it a few years ago when I was playing
>>>>> around with using GDC with DevKitARM for GBA.
>>>>>
>>>>> IIRC, you just go into "extern (C) int main(size_t argc, char **argv)"
>>>>> in the internal portion of phobos/tango/druntime or wherever it lives
>>>>> now and comment-out the calls to "gc_init()" and "gc_term()". You
>>>>> might also need to call "gc.disable()" or something (don't really
>>>>> remember). And then if you still want to use "new" and/or "delete"
>>>>> with your own memory manager, you can use D's class allocator and
>>>>> deallocator feature
>>>>> (http://www.digitalmars.com/d/1.0/class.html#allocators). I assume you
>>>>> could probably plug those class allocators/deallocators directly into
>>>>> the internal object class if you wanted.
>>>>
>>>> It sounds like a lot of work and new stuff to learn about the
>>>> implementation. Let's face it, I'm not going to use D since it doesn't
>>>> offer me anything over C++ that I want. The main thing I may like about
>>>> D is that it makes the effort to make implementation of the language
>>>> easier, and that, I think, is very key. I am here to look for features
>>>> I would put in a new language, though that may be too large of an
>>>> endeavor for someone my age.
>>>>
>>>> Tony
>>>>
>>>
>>> If you've already got your own full-fleged, reliable, memory management
>>> system, plugging it into D via the methods Robert and I pointed out is
>>> nothing by comparison.
>>
>> If I could do something with the object model, and or if the compiler is
>> open source, I would maybe look at the implementation as a potential
>> starting point or learning tool. Every time I've considered using
>> existing code though, I have ended up just starting with a clean slate
>> for a number of reasons. For now, I'm going to evolve my framework a bit
>> more and produce some programs. I'm keeping away from "advanced features"
>> of existing languages as much as possible so as not to be tied to them.
>> So far I've not found problem doing that. Error handling is the worst
>> beast that I don't have completely slain yet. Generics and mem mgmt I
>> have under control. I feel a bit limited by existing languages object
>> models, that's probably the key reason why I'd like to invent a new
>> language, be it for my own use or for more widespread use. Having full
>> control of a language and it's implementation is nothing to sneeze at
>> either, but taking advantage of that probably takes quite a bit of labor
>> (more than one developer).
>>
>> Tony
>
> Out of curiosity, what benefits are you going for by using your own memory
> management system instead of just a built-in GC?
Avoiding yet another black box for one thing. I can't really disclose here
other reasons.
>From some of your comments in this thread, I'm guessing it has to do with
>either game development or limited-memory/speed embedded devices (or both
>in the case of handheld or retro gaming). I can see how those could provide
>reasons for a custom memory manager.
See, you think in terms of "What reason would there be not to use GC?"
whereas I think "For what reason would I want to use GC?". Either is OK,
just personal preference (well in moreso in C++ than in D).
Tony
>
>