View mode: basic / threaded / horizontal-split · Log in · Help
November 04, 2008
Re: C++, D: Dinosaurs?
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
November 04, 2008
Re: C++, D: Dinosaurs?
"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 ;)
November 04, 2008
Re: C++, D: Dinosaurs?
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.
November 04, 2008
Re: C++, D: Dinosaurs?
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
November 04, 2008
Re: C++, D: Dinosaurs?
"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!
November 05, 2008
Re: C++, D: Dinosaurs?
"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
November 05, 2008
Re: C++, D: Dinosaurs?
"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.
November 06, 2008
Re: C++, D: Dinosaurs?
"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
November 06, 2008
Re: C++, D: Dinosaurs?
"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.
November 06, 2008
Re: C++, D: Dinosaurs?
"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
>
>
1 2 3 4 5 6
Top | Discussion index | About this forum | D home