In article <opsssrzs0623k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>On Thu, 23 Jun 2005 08:35:52 +1000, Derek Parnell <derek@psych.ward> wrote:
>> On Thu, 23 Jun 2005 10:15:40 +1200, Regan Heath wrote:
>>
>> [snip]
>>> I'm not talking about experience, I'm talking about argument, no-one has given an argument 'for' a string class that makes sense.
>>
>> One thing that is still a bit of a problem is having a 'string' type that is encoding agnostic. It would be very handy to be able to this sort of thing...
>>
>>   string a;
>>   char[] b;
>>   wchar[] c;
>>   dchar[] d;
>>
>>   a = b ~ c ~ d;
>>
>> Currently we need to explicitly invoke the UTF conversion functions to do this sort of thing.
>
>True, it is a pain.
>
>I once suggested that transcoding (converting from one UTF type to another) could be done implicity. It met with some like and some dislike. The dislike stemmed from the fact that it can be very inefficient where you have several types involved in one statement. Especially as it then happens implicitly and is not obvious.

Personally, I'd be happy with explicit transcoding using the cast operator:

dchar[] a;
char[] b = cast(char[]) a;

Does this already work, or is it just with foreach?  I keep forgetting to test it.

Sean

On Thu, 23 Jun 2005 01:44:04 +0000 (UTC), Sean Kelly wrote:

> In article <opsssrzs0623k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>
>>On Thu, 23 Jun 2005 08:35:52 +1000, Derek Parnell <derek@psych.ward> wrote:
>>> On Thu, 23 Jun 2005 10:15:40 +1200, Regan Heath wrote:
>>>
>>> [snip]
>>>> I'm not talking about experience, I'm talking about argument, no-one has given an argument 'for' a string class that makes sense.
>>>
>>> One thing that is still a bit of a problem is having a 'string' type that is encoding agnostic. It would be very handy to be able to this sort of thing...
>>>
>>>   string a;
>>>   char[] b;
>>>   wchar[] c;
>>>   dchar[] d;
>>>
>>>   a = b ~ c ~ d;
>>>
>>> Currently we need to explicitly invoke the UTF conversion functions to do this sort of thing.
>>
>>True, it is a pain.
>>
>>I once suggested that transcoding (converting from one UTF type to another) could be done implicity. It met with some like and some dislike. The dislike stemmed from the fact that it can be very inefficient where you have several types involved in one statement. Especially as it then happens implicitly and is not obvious.
> 
> Personally, I'd be happy with explicit transcoding using the cast operator:
> 
> dchar[] a;
> char[] b = cast(char[]) a;
> 
> Does this already work, or is it just with foreach?  I keep forgetting to test it.

The "cast(char[])" never does run-time UTF conversion. It does do compile-time UTF conversion for string literals.

The 'foreach' does allow character-by-character UTF conversion but it does need a cast to do that.

  char[] a;
  foreach(dchar x; a)


-- 
Derek
Melbourne, Australia
23/06/2005 12:40:08 PM

On Thu, 23 Jun 2005 01:44:04 +0000 (UTC), Sean Kelly <sean@f4.ca> wrote:
> Personally, I'd be happy with explicit transcoding using the cast operator:
>
> dchar[] a;
> char[] b = cast(char[]) a;

Good point. I forgot about that idea.

> Does this already work, or is it just with foreach?  I keep forgetting to test
> it.

Just with foreach, as Derek posted.

Regan

In article <opsssligap23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>> + Much tighter control over memory usage than GC. (Smaller working set,
>> much
>> less risk of unacceptable pauses.) A bit tedious when you don't need it,
>> but
>> irreplaceable when you do, and manageable given RAII. This point alone
>> creates a
>> sizeable niche in which D will _never_ supplant C/C++.
>
>D can do this too, just diasble the GC and memory manage to your hearts content.

Except that, to return to an earlier gripe, the rules for 'auto' don't allow automatic refcounted smart pointers along the lines of boost::shared_ptr. Such pointers are pretty much required for robust non-GC memory management. Also, I gather that Phobos assumes GC and will leak like a sieve without it.

It's not so much "D can do this" as "you can do this if you're prepared to fight the language every step of the way". You can do (real) GC in C++ by plugging in something like the Boehm collector. Not many people do. You certainly don't see ticks for C++ in the "GC" column in language comparison charts.

cheers
Mike

On Thu, 23 Jun 2005 08:07:06 +0000 (UTC), Mike Capp <mike.capp@gmail.com> wrote:
> In article <opsssligap23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>
>>> + Much tighter control over memory usage than GC. (Smaller working set,
>>> much
>>> less risk of unacceptable pauses.) A bit tedious when you don't need it,
>>> but
>>> irreplaceable when you do, and manageable given RAII. This point alone
>>> creates a
>>> sizeable niche in which D will _never_ supplant C/C++.
>>
>> D can do this too, just diasble the GC and memory manage to your hearts
>> content.
>
> Except that, to return to an earlier gripe, the rules for 'auto' don't allow
> automatic refcounted smart pointers along the lines of boost::shared_ptr.

I'll take your word for it. I've never used them.

> Such
> pointers are pretty much required for robust non-GC memory management.

Being a C programmer for a living I can honestly say I haven't had a memory management issue for.. well ages. I think memory management is a skill, one I have learnt thru years of being bitten by it. In addition C is probably much simpler than C++ when it comes to memory management.

> Also, I
> gather that Phobos assumes GC and will leak like a sieve without it.

True, you would be programming without a standard library. I think that is to be expected, it's a "standard" library after all, for doing handling standard situations.

> It's not so much "D can do this" as "you can do this if you're prepared to fight the language every step of the way".

> You can do (real) GC in C++ by plugging in
> something like the Boehm collector. Not many people do.

Are you saying the GC in D is less real than this? If so, how?

> You certainly don't see
> ticks for C++ in the "GC" column in language comparison charts.

In fairness that would be because it's a 'language' comparison, not a language + libraries comparison, right?

Regan

In article <opsstiikkp23k2f5@nrage.netwin.co.nz>, Regan Heath says...

>Being a C programmer for a living I can honestly say I haven't had a memory management issue for.. well ages. I think memory management is a skill, one I have learnt thru years of being bitten by it.

It depends very much on the kind of data structures needed for your app domain. In some domains you can write useful C/C++ apps without ever touching malloc/new. In others you really need refcounting, and manual refcounting is just nasty. In still others you have to cope with potential cycles, and GC is pretty much the only way to go.

>True, you would be programming without a standard library. I think that is to be expected, it's a "standard" library after all, for doing handling standard situations.

Fair enough, but it's then a bit of a stretch to claim that the language supports GC-less programming.

"Ugh, header files in C are a pain."

"But you can do header-less programming in C! As long as you don't mind putting all your code in one file and doing without any libraries, or copying all your prototypes etc into each source file."

>> You can do (real) GC in C++ by plugging in
>> something like the Boehm collector. Not many people do.
>
>Are you saying the GC in D is less real than this? If so, how?

No, I just meant "real" GC as opposed to refcounting.

cheers
Mike

On Thu, 23 Jun 2005 12:59:47 +0000 (UTC), Mike Capp <mike.capp@gmail.com> wrote:
> In article <opsstiikkp23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>> Being a C programmer for a living I can honestly say I haven't had a
>> memory management issue for.. well ages. I think memory management is a
>> skill, one I have learnt thru years of being bitten by it.
>
> It depends very much on the kind of data structures needed for your app domain. In some domains you can write useful C/C++ apps without ever touching
> malloc/new.

I use malloc/strdup all the time.

> In others you really need refcounting, and manual refcounting is just nasty.

I think it depends on the coding style you use. I've never 'needed' refcounting. At one stage I thought it was cool and tried using it, that stage didn't last.

> In still others you have to cope with potential cycles, and GC is pretty much the only way to go.

Cycles? example pls.

>> True, you would be programming without a standard library. I think that is
>> to be expected, it's a "standard" library after all, for doing handling
>> standard situations.
>
> Fair enough, but it's then a bit of a stretch to claim that the language
> supports GC-less programming.

I disagree. The 'language' supports it just fine. The 'library' doesn't. Compare that with Java, as I understand it (and that might be not at all) you cannot avoid the GC at all.

Regan

In article <opsstiikkp23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>On Thu, 23 Jun 2005 08:07:06 +0000 (UTC), Mike Capp <mike.capp@gmail.com> wrote:
>> In article <opsssligap23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>>
>>>> + Much tighter control over memory usage than GC. (Smaller working set,
>>>> much
>>>> less risk of unacceptable pauses.) A bit tedious when you don't need
>>>> it,
>>>> but
>>>> irreplaceable when you do, and manageable given RAII. This point alone
>>>> creates a
>>>> sizeable niche in which D will _never_ supplant C/C++.
>>>
>>> D can do this too, just diasble the GC and memory manage to your hearts content.
>>
>> Except that, to return to an earlier gripe, the rules for 'auto' don't
>> allow
>> automatic refcounted smart pointers along the lines of boost::shared_ptr.
>
>I'll take your word for it. I've never used them.

The basic problem is that D doesn't support copy semantics for user-defined types.  So it's impossible to implement anything that does refcounting.

>> Such
>> pointers are pretty much required for robust non-GC memory management.
>
>Being a C programmer for a living I can honestly say I haven't had a memory management issue for.. well ages. I think memory management is a skill, one I have learnt thru years of being bitten by it. In addition C is probably much simpler than C++ when it comes to memory management.
>
>> Also, I
>> gather that Phobos assumes GC and will leak like a sieve without it.
>
>True, you would be programming without a standard library. I think that is to be expected, it's a "standard" library after all, for doing handling standard situations.

Not only Phobos but the *core language*.  Remember, dynamic arrays (and associative arrays) are built on the GC.  To avoid GC you'd have to pretend D were C and use pointers for all your storage needs.


Sean

Sean Kelly wrote:

> 
> Not only Phobos but the *core language*.  Remember, dynamic arrays (and
> associative arrays) are built on the GC.  To avoid GC you'd have to pretend D
> were C and use pointers for all your storage needs.
> 
> 
Which, if I were to try and use D without a GC is exactly how I would do it.  If you want to avoid the GC in D I am assuming that you want to avoid it for performance reasons (lets not talk about avoiding the GC for pure masochistic reasons :)).  In which case you must have profiled your code, found that there is a certain area that is slow/non-deterministic _because_ of the garbage collector and now you are trying to fix it.  Fixing it could involve
1) Preallocate before the critical areas
2) Use freelists in the critical areas
3) Use memory that is outside the garbage collected areas and don't use new or dynamic arrays inside the critical areas
4) Don't allocate at all inside the critical areas

If the garbage collector is slowing your whole program & you can't use any of the above, then I suggest that you have chosen the wrong language for what you're trying to do.

I guess to sum up, my opinion is: D has a GC, thinking that the GC will cause performance problems before you have written any code is just premature optimisation.

Brad

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsstqq2vz23k2f5@nrage.netwin.co.nz...
> Cycles? example pls.

You know, objects that point to each other.  Even if nothing else is pointing to them, and they are for all purposes "dead," they won't be automatically collected because they still point to each other and thus still have one reference each.  You'd have to establish some kind of manual cleanup for these objects, such as a "parent-child" relationship, where deleting the parent would cause the child to .Release() the reference to the parent.