View mode: basic / threaded / horizontal-split · Log in · Help
January 09, 2012
Re: Discussion about D at a C++ forum
On Sunday, 8 January 2012 at 23:28:57 UTC, Mehrdad wrote:
> On 1/7/2012 10:57 PM, Jonathan M Davis wrote:
>> Not exactly the most informed discussion.
>
> Well, some of their comments _ARE_ spot-on correct...

computerquip did a very good job highlighting the bad points. 
rapidcoder failed miserably to provide accurate claims. Most of 
the discussion is these two going back and forth (where 
computerquip states rapidcoder's inability to argue).

The conclusion that not a systems language is the only thing I 
partially disagree with from computerquip. I don't think it can 
be used for such at this time, or at least not it a way that is 
any better than C (and may even be worse in some situations). But 
systems programming is a goal, we just don't have a big enough 
section in the community spending time to improve this area.

Sadly there isn't anything new that we can take away from this 
discussion.
January 09, 2012
Re: Discussion about D at a C++ forum
On Sun, 08 Jan 2012 19:26:15 -0500
dsimcha <dsimcha@yahoo.com> wrote:

> As someone who does performance-critical scientific work in D, this 
> comment is absolutely **wrong** because you only need to avoid the GC
> in the most performance-critical/realtime parts of your code, i.e.
> where you should be avoiding any dynamic allocation, GC or not.

Considering we'd need to do some work for our project involving number
crunching in the form of producing several libs to be (later) used by
GUI part of the app, I'm curious to know do you use ncurses or just
plain console output for your UI?

I'm askin considering to start work on non-GUI part of the project and
just have simple UI to test results and along with that work try to
improve GUI situation in the D's ecosystem.

> Bottom line:  D doesn't give you a free lunch but it does give you a 
> cheaper lunch than C, C++ or even a combination of C/C++ and Python.

That's vey nice to hear from someone like yourself. We did small
research about possible alternatives for D by looking at Scala &
Clojure, but understood we don't get much in terms of GUIs, but only
lose otherwise.

Last consideration was C#/Mono, but, again, not much to gain and more to
lose, so we'll stay with D, try to write non-GUI parts and later
(hopefully) sell D as overall language of the projet.


Sincerely,
Gour

-- 
Never was there a time when I did not exist, 
nor you, nor all these kings; nor in the future 
shall any of us cease to be.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
January 09, 2012
Re: Discussion about D at a C++ forum
On 1/8/2012 7:09 PM, Vladimir Panteleev wrote:
> On Sunday, 8 January 2012 at 23:28:57 UTC, Mehrdad wrote:
>> 7. Unstable language. They're currently considering doing things like 
>> removing "delete" as it's apparently deprecated (which will 
>> officially make it not usable as an SP language).
>>   Looks 100% correct. Removing 'delete' /does/ make D unusable as an 
>> SP language... unless you ignore the GC completely, which isn't even 
>> possible, practically speaking.
>
> I don't understand how you came to that conclusion? "delete" will 
> become a standard library (or easily-implemented user) function.
Would it still have the same functionality (i.e. disposing of GC'd 
objects and reclaiming their memory, as though the GC had done it)?
If so, what's the point of removing it in the first place?
If not, then I guess my point is obvious.
January 09, 2012
Re: Discussion about D at a C++ forum
On Monday, January 09, 2012 00:51:57 Mehrdad wrote:
> On 1/8/2012 7:09 PM, Vladimir Panteleev wrote:
> > On Sunday, 8 January 2012 at 23:28:57 UTC, Mehrdad wrote:
> >> 7. Unstable language. They're currently considering doing things like
> >> removing "delete" as it's apparently deprecated (which will
> >> officially make it not usable as an SP language).
> >> 
> >>   Looks 100% correct. Removing 'delete' /does/ make D unusable as an
> >> 
> >> SP language... unless you ignore the GC completely, which isn't even
> >> possible, practically speaking.
> > 
> > I don't understand how you came to that conclusion? "delete" will
> > become a standard library (or easily-implemented user) function.
> 
> Would it still have the same functionality (i.e. disposing of GC'd
> objects and reclaiming their memory, as though the GC had done it)?
> If so, what's the point of removing it in the first place?
> If not, then I guess my point is obvious.

I believe that the general idea is that if you want to manually manage memory, 
then you don't use the GC heap, though core.memory.GC will still allow some 
level of manual control for the GC. I'm not aware of any plan to add a 
"delete" function to anything, but if something like that is added, it'll 
probably be to core.memory with the idea that it's there if you really need it 
but that you really shouldn't be using it normally. Explicitly freeing memory 
goes with manually memory management, not garbage collection.

- Jonathan M Davis
January 09, 2012
Re: Discussion about D at a C++ forum
Jonathan M Davis wrote:

> On Monday, January 09, 2012 00:51:57 Mehrdad wrote:
>> On 1/8/2012 7:09 PM, Vladimir Panteleev wrote:
>> > On Sunday, 8 January 2012 at 23:28:57 UTC, Mehrdad wrote:
>> >> 7. Unstable language. They're currently considering doing things like
>> >> removing "delete" as it's apparently deprecated (which will
>> >> officially make it not usable as an SP language).
>> >> 
>> >>   Looks 100% correct. Removing 'delete' /does/ make D unusable as an
>> >> 
>> >> SP language... unless you ignore the GC completely, which isn't even
>> >> possible, practically speaking.
>> > 
>> > I don't understand how you came to that conclusion? "delete" will
>> > become a standard library (or easily-implemented user) function.
>> 
>> Would it still have the same functionality (i.e. disposing of GC'd
>> objects and reclaiming their memory, as though the GC had done it)?
>> If so, what's the point of removing it in the first place?
>> If not, then I guess my point is obvious.
> 
> I believe that the general idea is that if you want to manually manage memory,
> then you don't use the GC heap, though core.memory.GC will still allow some
> level of manual control for the GC. I'm not aware of any plan to add a
> "delete" function to anything, but if something like that is added, it'll
> probably be to core.memory with the idea that it's there if you really need it
> but that you really shouldn't be using it normally. Explicitly freeing memory
> goes with manually memory management, not garbage collection.
> 
> - Jonathan M Davis

AFAIK, core.memory.GC.free() can be used to manually deallocate GC allocated 
data (you'll have to clear the classes to destroy them, though).

But, correct, if you want manual allocation, you should use manual allocation.
My game project uses GC all over the code - yet most memory is manually 
allocated as the largest allocations are in specific parts of code (mostly 
video related, e.g. textures). This way you get the benefits of both a GC and 
manual allocation.
January 09, 2012
Re: Discussion about D at a C++ forum
On Sun, 08 Jan 2012 18:28:54 -0500, Mehrdad <wfunction@hotmail.com> wrote:

> 7. Unstable language. They're currently considering doing things like  
> removing "delete" as it's apparently deprecated (which will officially  
> make it not usable as an SP language).
>     Looks 100% correct. Removing 'delete' /does/ make D unusable as an  
> SP language... unless you ignore the GC completely, which isn't even  
> possible, practically speaking.

C doesn't have delete.

But removing delete isn't the problem anyways.  Here is the problem (which  
exists with delete present in the language):

class C
{
   private int[] buf;
   this() { buf = new int[5]; }
   ~this() {/* can't destroy buf here */}
}

void main()
{
   auto c = new C;
   delete c; // doesn't destroy c.buf
}

What we need is a way to hook deterministic destruction vs. GC  
destruction.  Only then, a SP language will you be.

-Steve
January 09, 2012
Re: Discussion about D at a C++ forum
On 1/9/2012 2:56 AM, Gour wrote:
> On Sun, 08 Jan 2012 19:26:15 -0500
> dsimcha<dsimcha@yahoo.com>  wrote:
>
>> As someone who does performance-critical scientific work in D, this
>> comment is absolutely **wrong** because you only need to avoid the GC
>> in the most performance-critical/realtime parts of your code, i.e.
>> where you should be avoiding any dynamic allocation, GC or not.
>
> Considering we'd need to do some work for our project involving number
> crunching in the form of producing several libs to be (later) used by
> GUI part of the app, I'm curious to know do you use ncurses or just
> plain console output for your UI?

Pure command line/console.
January 09, 2012
Re: Discussion about D at a C++ forum
On Mon, 09 Jan 2012 09:28:11 -0500
dsimcha <dsimcha@yahoo.com> wrote:

> Pure command line/console.

Thank you.


Sincerely,
Gour

-- 
As a strong wind sweeps away a boat on the water, 
even one of the roaming senses on which the mind 
focuses can carry away a man's intelligence.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
January 09, 2012
Re: Discussion about D at a C++ forum
On Sunday, 8 January 2012 at 04:19:52 UTC, Andrei Alexandrescu 
wrote:
> Here's an interesting discussion that may reflect the 
> perceptions and misperceptions about D within the larger 
> community.

They did not touch any new topic we did not talk about here on 
this NG, and on irc://irc.freenode.org/d . :)
January 09, 2012
Re: Discussion about D at a C++ forum
On 01/09/2012 07:58 AM, Steven Schveighoffer wrote:
> On Sun, 08 Jan 2012 18:28:54 -0500, Mehrdad <wfunction@hotmail.com> wrote:
>
>> 7. Unstable language. They're currently considering doing things like
>> removing "delete" as it's apparently deprecated (which will officially
>> make it not usable as an SP language).
>> Looks 100% correct. Removing 'delete' /does/ make D unusable as an SP
>> language... unless you ignore the GC completely, which isn't even
>> possible, practically speaking.
>
> C doesn't have delete.
>
> But removing delete isn't the problem anyways. Here is the problem
> (which exists with delete present in the language):
>
> class C
> {
> private int[] buf;
> this() { buf = new int[5]; }
> ~this() {/* can't destroy buf here */}
> }
>
> void main()
> {
> auto c = new C;
> delete c; // doesn't destroy c.buf
> }
>
> What we need is a way to hook deterministic destruction vs. GC
> destruction. Only then, a SP language will you be.
>
> -Steve

I was under the impression you could overload new and delete per 
class/union/struct which gave you the ability to control how things were 
allocated.

I was also under the impression that this would be longer possible with 
some of the comments made on IRC. I'm probably wrong (or I hope I'm 
wrong...).
1 2 3 4 5
Top | Discussion index | About this forum | D home