http://www.digitalmars.com/d/memory.html

Defines as ways to get memory on the stack, which is uninitialized, the following:

byte[] buffer = (cast(byte*)std.c.stdlib.alloca(1024))[0 .. 1024];

Which is obviously a little unfriendly, but usable.  It defines no method to retrieve uninitialized variables (e.g. an int), and etc.  Of course, it may not be common to need this, really, but it's a useful thing to have if you know you will be setting the variable later anyway.

I would like to suggest the following syntax as an alternative:

uninitialized byte[1024] buffer;

While the keyword "uninitialized" is long, it is also not commonly used and still shorter than the alloca line above.  This would also allow:

uninitialized int i;
byte[] data = new uninitialized byte[1024];

In short, it could be used after new or proceeding the type - on the stack or off.  However, for the purposes of garbage collection and etc, some limits would obviously have to be imposed:

uninitialized int* p;
uninitialized Class c;
uninitialized byte[] array;
uninitialized st_something s;
uninitialized int i = 5;

test.d(1): pointers, structs, and classes cannot be uninitialized.
test.d(2): pointers, structs, and classes cannot be uninitialized.
test.d(3): dynamic arrays cannot be uninitialized; try = new uninitialized.
test.d(4): pointers, structs, and classes cannot be uninitialized.
test.d(5): uninitialized variable was initialized.

Or similar.  The restriction on structs only because they could have pointers or etc. in them, and I didn't want to ask for the compiler to deduce if the struct was able to be uninitialized.

Does such a syntax seem desirable, if verbose?  Or is it just "syntactical sugar"?

-[Unknown]

"Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:d82cnj$un8$1@digitaldaemon.com...
> http://www.digitalmars.com/d/memory.html
>
> Defines as ways to get memory on the stack, which is uninitialized, the following:
>
> byte[] buffer = (cast(byte*)std.c.stdlib.alloca(1024))[0 .. 1024];
>
> Which is obviously a little unfriendly, but usable.

Note the package name can be dropped to make it slightly more usable
 byte[] buffer = (cast(byte*)alloca(1024))[0 .. 1024];

> It defines no method to retrieve uninitialized variables (e.g. an int), and etc.  Of course, it may not be common to need this, really, but it's a useful thing to have if you know you will be setting the variable later anyway.
>
> I would like to suggest the following syntax as an alternative:
>
> uninitialized byte[1024] buffer;

At one point it was suggested to use a "void initializer":
 byte[1024] buffer = void;
which has the advantage of not requiring a new keyword.

> While the keyword "uninitialized" is long, it is also not commonly used and still shorter than the alloca line above.  This would also allow:
>
> uninitialized int i;
> byte[] data = new uninitialized byte[1024];

The above void initializer syntax wouldn't work in this case - at least not
obviously. Perhaps a variation would be that an array of void is left
uninitialized. For example
 byte[] data = cast(byte[])(new void[1024]);
I'm not sure what currently happens when you try to allocate an array of
voids.

> In short, it could be used after new or proceeding the type - on the stack or off.  However, for the purposes of garbage collection and etc, some limits would obviously have to be imposed:
>
> uninitialized int* p;
> uninitialized Class c;
> uninitialized byte[] array;
> uninitialized st_something s;
> uninitialized int i = 5;
>
> test.d(1): pointers, structs, and classes cannot be uninitialized.
> test.d(2): pointers, structs, and classes cannot be uninitialized.
> test.d(3): dynamic arrays cannot be uninitialized; try = new
> uninitialized.
> test.d(4): pointers, structs, and classes cannot be uninitialized.
> test.d(5): uninitialized variable was initialized.

It would be nice to invent a syntax that doesn't require any special cases or ambiguity rules.

> Or similar.  The restriction on structs only because they could have pointers or etc. in them, and I didn't want to ask for the compiler to deduce if the struct was able to be uninitialized.
>
> Does such a syntax seem desirable, if verbose?  Or is it just "syntactical sugar"?
>
> -[Unknown]

But even with the void syntax, you have:

int* p = void;

Which must be an error as well, to my understanding, so that a garbage collector won't get confused, no?  Or maybe I'm just making things up? If that's not true, uninitialized doesn't need the rules either.

Anyway, benefits of uninitialized are that it:
  - doesn't look like initialization, since it's not.
  - could be defined as optional (ignoreable) by implementation (void could too, I guess.)
  - doesn't abuse a type as a value.

-[Unknown]


> "Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:d82cnj$un8$1@digitaldaemon.com...
> 
>>http://www.digitalmars.com/d/memory.html
>>
>>Defines as ways to get memory on the stack, which is uninitialized, the following:
>>
>>byte[] buffer = (cast(byte*)std.c.stdlib.alloca(1024))[0 .. 1024];
>>
>>Which is obviously a little unfriendly, but usable.
> 
> 
> Note the package name can be dropped to make it slightly more usable
>  byte[] buffer = (cast(byte*)alloca(1024))[0 .. 1024];
> 
> 
>>It defines no method to retrieve uninitialized variables (e.g. an int), and etc.  Of course, it may not be common to need this, really, but it's a useful thing to have if you know you will be setting the variable later anyway.
>>
>>I would like to suggest the following syntax as an alternative:
>>
>>uninitialized byte[1024] buffer;
> 
> 
> At one point it was suggested to use a "void initializer":
>  byte[1024] buffer = void;
> which has the advantage of not requiring a new keyword.
> 
> 
>>While the keyword "uninitialized" is long, it is also not commonly used and still shorter than the alloca line above.  This would also allow:
>>
>>uninitialized int i;
>>byte[] data = new uninitialized byte[1024];
> 
> 
> The above void initializer syntax wouldn't work in this case - at least not obviously. Perhaps a variation would be that an array of void is left uninitialized. For example
>  byte[] data = cast(byte[])(new void[1024]);
> I'm not sure what currently happens when you try to allocate an array of voids.
> 
> 
>>In short, it could be used after new or proceeding the type - on the stack or off.  However, for the purposes of garbage collection and etc, some limits would obviously have to be imposed:
>>
>>uninitialized int* p;
>>uninitialized Class c;
>>uninitialized byte[] array;
>>uninitialized st_something s;
>>uninitialized int i = 5;
>>
>>test.d(1): pointers, structs, and classes cannot be uninitialized.
>>test.d(2): pointers, structs, and classes cannot be uninitialized.
>>test.d(3): dynamic arrays cannot be uninitialized; try = new uninitialized.
>>test.d(4): pointers, structs, and classes cannot be uninitialized.
>>test.d(5): uninitialized variable was initialized.
> 
> 
> It would be nice to invent a syntax that doesn't require any special cases or ambiguity rules.
> 
> 
>>Or similar.  The restriction on structs only because they could have pointers or etc. in them, and I didn't want to ask for the compiler to deduce if the struct was able to be uninitialized.
>>
>>Does such a syntax seem desirable, if verbose?  Or is it just "syntactical sugar"?
>>
>>-[Unknown] 
> 
> 
> 

On Mon, 06 Jun 2005 13:47:08 -0700, Unknown W. Brackets <unknown@simplemachines.org> wrote:
> In short, it could be used after new or proceeding the type - on the stack or off.  However, for the purposes of garbage collection and etc, some limits would obviously have to be imposed:
>
> uninitialized int* p;
> uninitialized Class c;
> uninitialized byte[] array;
> uninitialized st_something s;
> uninitialized int i = 5;
>
> test.d(1): pointers, structs, and classes cannot be uninitialized.
> test.d(2): pointers, structs, and classes cannot be uninitialized.
> test.d(3): dynamic arrays cannot be uninitialized; try = new uninitialized.
> test.d(4): pointers, structs, and classes cannot be uninitialized.
> test.d(5): uninitialized variable was initialized.
>
> Or similar.  The restriction on structs only because they could have pointers or etc. in them, and I didn't want to ask for the compiler to deduce if the struct was able to be uninitialized.

Quick question... I didn't think the GC treated a pointer any different to an int, in that if either block of memory (the one containing the pointer or int) contained a value which could be a memory address, it stopped that memory address from being considered unreferenced and thus free to be free'd. Am I wrong?

Regan

On Mon, 06 Jun 2005 13:47:08 -0700, Unknown W. Brackets <unknown@simplemachines.org> wrote:
> http://www.digitalmars.com/d/memory.html
>
> Defines as ways to get memory on the stack, which is uninitialized, the following:
>
> byte[] buffer = (cast(byte*)std.c.stdlib.alloca(1024))[0 .. 1024];
>
> Which is obviously a little unfriendly, but usable.  It defines no method to retrieve uninitialized variables (e.g. an int), and etc.  Of course, it may not be common to need this, really, but it's a useful thing to have if you know you will be setting the variable later anyway.
>
> I would like to suggest the following syntax as an alternative:
>
> uninitialized byte[1024] buffer;
>
> While the keyword "uninitialized" is long, it is also not commonly used and still shorter than the alloca line above.  This would also allow:
>
> uninitialized int i;
> byte[] data = new uninitialized byte[1024];
>
> In short, it could be used after new or proceeding the type - on the stack or off.  However, for the purposes of garbage collection and etc, some limits would obviously have to be imposed:
>
> uninitialized int* p;
> uninitialized Class c;
> uninitialized byte[] array;
> uninitialized st_something s;
> uninitialized int i = 5;
>
> test.d(1): pointers, structs, and classes cannot be uninitialized.
> test.d(2): pointers, structs, and classes cannot be uninitialized.
> test.d(3): dynamic arrays cannot be uninitialized; try = new uninitialized.
> test.d(4): pointers, structs, and classes cannot be uninitialized.
> test.d(5): uninitialized variable was initialized.
>
> Or similar.  The restriction on structs only because they could have pointers or etc. in them, and I didn't want to ask for the compiler to deduce if the struct was able to be uninitialized.
>
> Does such a syntax seem desirable, if verbose?  Or is it just "syntactical sugar"?

My take...

Types on which it makes little or no sense to use 'non-initialisation':
char[] dynamic; //all dynamic arrays, unless assigned with 'new'.
int i; //and other small stack based types.
Class ref; //class references

Types on which it is useful:
char[100] static; //all static arrays.
char[] dynamic_assign = new char[1000]; //all dynamic arrays, assigned with new.

Basically it seems when a large block of memory is allocated, you want to choose not to initialise it. I'd suggest the keyword 'raw', and I'd suggest it's usage be:

raw char[100] static; //as a type-modifier
char[] dynamic_assign = raw char[1000]; //as replacement for new?

or perhaps (if you dislike the 'abuse' of the type modifier 'raw' as a replacement for 'new')

char[] dynamic_assign = new raw char[1000]; //as type-modifier

So, raw would mean uncooked or 0xd34db33f if you will ;)

Regan

In article <d82e24$vs0$1@digitaldaemon.com>, Unknown W. Brackets says...
>
>But even with the void syntax, you have:
>
>int* p = void;
>
>Which must be an error as well, to my understanding, so that a garbage collector won't get confused, no?  Or maybe I'm just making things up? If that's not true, uninitialized doesn't need the rules either.

I was assuming that those cases wouldn't error. The two proposals (in the area
of initializers) are equivalent
uninitialized foo bar;     <->     foo bar = void;
with the one exception that foo bar = void avoids the ambiguous situation
uninitialized foo bar = 5;

>Anyway, benefits of uninitialized are that it:
>   - doesn't look like initialization, since it's not.
actually I would say that indicating uninitialized state is intimately involved
with initialization. To me it's obvious which of the following are uninitialized
and which aren't
int x = 10, y = void, z = 20;

>   - could be defined as optional (ignoreable) by implementation (void
>could too, I guess.)
agreed. the two are the same.

>   - doesn't abuse a type as a value.
one person's "natural extension" is another's "abuse"...

To me the plus/minus is
1) =void avoids the ambiguous case where both uninitialized and an initalizer
are specified
2) =void does not directly address how to allocate uninitialized dynamic GC
memory

The problem with raw is it would commonly be used in programs already as a variable name or similar - at least, I've seen it more than a couple times.  Find me a program that uses "uninitialized"... sure, there may very well be some, but probably not many.

If you want an uninitialized stack variable, what's wrong with that? Sure, it doesn't save much time - but if the function is being called 1000 times a second, it might be worth it.

I, probably wrongly, assumed that the gc or more likely other potential gc implementations might recognize all pointer types.  If this is incorrect, you still have classes and dynamic arrays.

-[Unknown]


> My take...
> 
> Types on which it makes little or no sense to use 'non-initialisation':
> char[] dynamic; //all dynamic arrays, unless assigned with 'new'.
> int i; //and other small stack based types.
> Class ref; //class references
> 
> Types on which it is useful:
> char[100] static; //all static arrays.
> char[] dynamic_assign = new char[1000]; //all dynamic arrays, assigned  with new.
> 
> Basically it seems when a large block of memory is allocated, you want to  choose not to initialise it. I'd suggest the keyword 'raw', and I'd  suggest it's usage be:
> 
> raw char[100] static; //as a type-modifier
> char[] dynamic_assign = raw char[1000]; //as replacement for new?
> 
> or perhaps (if you dislike the 'abuse' of the type modifier 'raw' as a  replacement for 'new')
> 
> char[] dynamic_assign = new raw char[1000]; //as type-modifier
> 
> So, raw would mean uncooked or 0xd34db33f if you will ;)
> 
> Regan

Fair enough.  I still think that it makes just as much sense as:

int* p = int;

Or in other words, none.  I just can't think of anywhere a type, even void, is used as a value.  It's contradictory to me.

-[Unknown]


> In article <d82e24$vs0$1@digitaldaemon.com>, Unknown W. Brackets says...
> 
>>But even with the void syntax, you have:
>>
>>int* p = void;
>>
>>Which must be an error as well, to my understanding, so that a garbage collector won't get confused, no?  Or maybe I'm just making things up? If that's not true, uninitialized doesn't need the rules either.
> 
> 
> I was assuming that those cases wouldn't error. The two proposals (in the area
> of initializers) are equivalent
> uninitialized foo bar;     <->     foo bar = void;
> with the one exception that foo bar = void avoids the ambiguous situation
> uninitialized foo bar = 5;
> 
> 
>>Anyway, benefits of uninitialized are that it:
>>  - doesn't look like initialization, since it's not.
> 
> actually I would say that indicating uninitialized state is intimately involved
> with initialization. To me it's obvious which of the following are uninitialized
> and which aren't
> int x = 10, y = void, z = 20;
> 
> 
>>  - could be defined as optional (ignoreable) by implementation (void 
>>could too, I guess.)
> 
> agreed. the two are the same.
> 
> 
>>  - doesn't abuse a type as a value.
> 
> one person's "natural extension" is another's "abuse"...
> 
> To me the plus/minus is
> 1) =void avoids the ambiguous case where both uninitialized and an initalizer
> are specified
> 2) =void does not directly address how to allocate uninitialized dynamic GC
> memory
> 
> 

On Mon, 06 Jun 2005 17:02:42 -0700, Unknown W. Brackets wrote:

> Fair enough.  I still think that it makes just as much sense as:
> 
> int* p = int;
> 
> Or in other words, none.  I just can't think of anywhere a type, even void, is used as a value.  It's contradictory to me.

Well that's a valid point of view too.

To me, "void" is just a word, like "static". It can have various meanings in the language depending on how its used. Just like in English, "void" has various meanings - "empty", "no longer usable", ...

Though my preference is for a new keyword that is self-documenting. So "uninitialized", "raw", and "unformatted" all seem acceptable.

-- 
Derek
Melbourne, Australia
7/06/2005 10:55:32 AM

On Tue, 7 Jun 2005 11:07:34 +1000, Derek Parnell <derek@psych.ward> wrote:
> On Mon, 06 Jun 2005 17:02:42 -0700, Unknown W. Brackets wrote:
>
>> Fair enough.  I still think that it makes just as much sense as:
>>
>> int* p = int;
>>
>> Or in other words, none.  I just can't think of anywhere a type, even
>> void, is used as a value.  It's contradictory to me.
>
> Well that's a valid point of view too.
>
> To me, "void" is just a word, like "static". It can have various meanings
> in the language depending on how its used. Just like in English, "void" has
> various meanings - "empty", "no longer usable", ...
>
> Though my preference is for a new keyword that is self-documenting.
> So "uninitialized", "raw", and "unformatted" all seem acceptable.

"noinit"

Regan