"Anders F Björklund" <afb@algonet.se> wrote in message news:db57bf$27s3$1@digitaldaemon.com...
> Andrew Fedoniouk wrote:
>
>> char[#]  is a bit better than readonly char[], huh? :)))
>
> Actually I thought you said "char #[]", maybe you changed it...
>
> Alternative:
> The argument "char[inout]" (contents) would be pretty similar to
> "inout char[]" (reference), but still a bit hard to decipher ?
>
> (that is: the first would be like "const char*", and the second would be like "char* const"
>
> BTW;
> The "readonly" attribute was only a less-loaded const alternative.
> But it seems like it still burdened by all the Const Correctness...
>
> --anders

I've already published this proposal, I'll repeat it then:
----------------------------------------------------------
Possible syntax for immutable arrays and pointers.

declarations:

// arrays

char a[]; // RW array/slice
char b[#]; // RO array/slice

char a[ 100 ] ; // static RW array/slice.
char b[# 100 ]; // static RO array/slice.

// pointers

char * pa;  // RW pointer
char *# pb;  // RO pointer

// associative arrays/maps

int[ char[] ] a; // RW map
int[# char[] ] b; // RO map

----------------------------
Rationale: readonly attribute syntacticaly should be as close as
possible to array/pointer designator ( [ ] ), ideally it should be part of
it.

Andrew.
http://terrainformatica.com

"Brad Beveridge" <brad@somewhere.net> wrote in message news:db600b$2to6$1@digitaldaemon.com...
> Andrew Fedoniouk wrote:
>
>>
>> Thanks, Brad. Extremely cool.
>> Concept car looked nice but was not moving :)
>>
>> BTW: on Windows you would use VirtualAlloc for that.
>> With the same result, though.
>>
>> And try to imagine that you are passing something
>> like root node of some XML DOM into function
>> designed to return second child node....
>>
>>
> :) That's pretty much what I thought.  But it was worth a shot to see if something could be done - we do after all have an MMU so we should try to use it :)
>

Yep.

But *we* do not have MMU. It is OS who has it.

Andrew.

Andrew Fedoniouk wrote:

>>:) That's pretty much what I thought.  But it was worth a shot to see if something could be done - we do after all have an MMU so we should try to use it :)
>>
> 
> 
> Yep.
> 
> But *we* do not have MMU. It is OS who has it.
> 
> Andrew.

True.  I program device drivers & OS level stuff for a day job, so I tend to think about things as they are close to the hardware.  It is a shame that user applications don't have better control of the MMU in modern OSes - but such is life :)

Brad

"Brad Beveridge" <brad@somewhere.net> wrote in message news:db6o65$hug$1@digitaldaemon.com...
> Andrew Fedoniouk wrote:
>
>>>:) That's pretty much what I thought.  But it was worth a shot to see if something could be done - we do after all have an MMU so we should try to use it :)
>>>
>>
>>
>> Yep.
>>
>> But *we* do not have MMU. It is OS who has it.
>>
>> Andrew.
>
> True.  I program device drivers & OS level stuff for a day job, so I tend to think about things as they are close to the hardware.  It is a shame that user applications don't have better control of the MMU in modern OSes - but such is life :)
>

I see you are a bit pessimistic about life...

Well, it has good sides too. Just need to take a gaze and you'll see...
For example here is a shot named "Furniture for eXtreme Programming. Chair."
http://www.terrainformatica.com/screenshots/xpchair.jpg

I've made it in my office week ago.
Disclaimer: For those who practicing XP - nothing personal.

Andrew.

In article <db63at$31dn$3@digitaldaemon.com>, Walter says...
>
>"Mike Capp" <mike.capp@gmail.com> wrote
>> GC is massive overkill for local-scoped class variables
>> and (to a lesser extent) simple value-like class members. C++'s default
>> stack allocation is a far better story than D on this front.
>
>"simple value-like class" object instances in D are called structs and are allocated on the stack.

D structs correspond to C structs or C++ POD types, not to lightweight C++ value types in general. D seems to fall into the same trap as Java in thinking that OO only applies to Big Heavyweight Types, and that lightweight types can't possibly need encapsulation or any of that guff.

Take something trivial like a UnitVector3: a vector of three floats with a magnitude of 1. It's smaller than builtins like cdouble, and it's normally going to appear as a temporary, local-scoped variable or member of a larger aggregate type. It's situations like this where GC looks like massive overkill; if you're doing a lot of calculation with these things you're going to get a lot of unnecessary gen0 churn.

D structs are no help at all for use cases like this. The interesting part of UnitVector3 is the invariant, and while you can specify an invariant for a D struct, it feels a bit like mocking the poor thing because the struct has no way to establish or preserve that invariant. No constructors, no protection attributes, so what's the point? (Protection atts in structs are accepted by the compiler, and even appear in some doc examples e.g. "Properties", but aren't enforced as of 0.128.)

Implementing (and guaranteeing) stack allocation for 'auto' class instances would help a bit, but only a bit, because autos can't be returned or passed around like values.

cheers
Mike

"Mike Capp" <mike.capp@gmail.com> wrote in message news:db6tl0$m1d$1@digitaldaemon.com...
> In article <db63at$31dn$3@digitaldaemon.com>, Walter says...
>>
>>"Mike Capp" <mike.capp@gmail.com> wrote
>>> GC is massive overkill for local-scoped class variables
>>> and (to a lesser extent) simple value-like class members. C++'s default
>>> stack allocation is a far better story than D on this front.
>>
>>"simple value-like class" object instances in D are called structs and are allocated on the stack.
>
> D structs correspond to C structs or C++ POD types, not to lightweight C++
> value
> types in general. D seems to fall into the same trap as Java in thinking
> that OO
> only applies to Big Heavyweight Types, and that lightweight types can't
> possibly
> need encapsulation or any of that guff.
>
> Take something trivial like a UnitVector3: a vector of three floats with a
> magnitude of 1. It's smaller than builtins like cdouble, and it's normally
> going
> to appear as a temporary, local-scoped variable or member of a larger
> aggregate
> type. It's situations like this where GC looks like massive overkill; if
> you're
> doing a lot of calculation with these things you're going to get a lot of
> unnecessary gen0 churn.
>
> D structs are no help at all for use cases like this. The interesting part
> of
> UnitVector3 is the invariant, and while you can specify an invariant for a
> D
> struct, it feels a bit like mocking the poor thing because the struct has
> no way
> to establish or preserve that invariant.

Why not? Make the fields private with no setter.

> No constructors,

easily worked around for your example by specifying a init value where one of the fields is 1 (e.g. x) or using either a top-level function or the "static opCall" hack.

> no protection
> attributes, so what's the point? (Protection atts in structs are accepted
> by the
> compiler, and even appear in some doc examples e.g. "Properties", but
> aren't
> enforced as of 0.128.)

A bug in dmd.128 shouldn't make one conclude that structs in D (the language) have "no protection".

> Implementing (and guaranteeing) stack allocation for 'auto' class
> instances
> would help a bit, but only a bit, because autos can't be returned or
> passed
> around like values.

I would stick with structs.

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:db649h$ob$1@digitaldaemon.com...
> Walter, it was all about memory safety and DbC.

I understand that.

> The only one test available for DbC (runtime DbC test, sic!) now is to
test
> on NULL pointer.

No, you can test for anything you can express in code. You can, for example, run a consistency check on a free list.

Hi there,

>> D structs are no help at all for use cases like this. The interesting part
>> of
>> UnitVector3 is the invariant, and while you can specify an invariant for a
>> D
>> struct, it feels a bit like mocking the poor thing because the struct has
>> no way
>> to establish or preserve that invariant.
>
>Why not? Make the fields private with no setter.

Correct me if I'm wrong, but I believe that the private modifier has no effect on struct variable members. I'm on DMD/Linux 0.127 and I can do this:

Foo.d
=====

# struct Foo { private int Bar = 42; }

Bar.d
=====

# import std.string;
# import std.stdio;
# import Foo;
#
# void main() {
#     Foo foo;
#     writefln(toString(foo.Bar));
#     foo.Bar = 1337;
#     writefln(toString(foo.Bar));
# }
#
# // Prints 42, then 1337.

They're even on separate files to avoid the annoying default "friend" modifier. I don't know if this is a bug or "feature," but for consistency (at the least), I think private should be enforced.

Cheers,
--AJG.

> They're even on separate files to avoid the annoying default "friend" modifier.
> I don't know if this is a bug or "feature," but for consistency (at the least),
> I think private should be enforced.

Huh? I didn't know that. I really want to add a strong "Yes!" to that statement. The Indigo containers, for example, are heavily struct-based (nice example to see how much *is* possible with structs, by the way), and they don't like messing up their guts :)

Ciao
uwe

In article <db74df$qk1$1@digitaldaemon.com>, Ben Hinkle says...
>
>> No constructors,
>
>easily worked around for your example by [...] the "static opCall" hack.

Hmm, that hadn't occurred to me. Thanks. Still some unnecessary copies going on, but the compiler backend can probably optimize those away.

>A bug in dmd.128 shouldn't make one conclude that structs in D (the language) have "no protection".

It's not just a bug in 0.128; the grammar in the doc page for structs (unlike the one for classes) makes no mention at all of protection. I'd be happy to raise it again as a bug, though, if you think it stands any chance of being "fixed".

cheers
Mike