www.digitalmars.com         C & C++   DMDScript  

D - D syntax queries

reply "Ben Cohen" <bc skygate.co.uk> writes:
Hi,

I've got a couple of queries about D's syntax:


Pointer indirection, which in C is written "->" will be written as "." in
D. I assume that D will work out what the dot means using the types of the
variables involved and possibly any casts by the programmer.

For example:

struct S { int *x; }
S my_s;
int *a;
int b;

my_s.x = a;
my_s.x = b;

The first assignment is with "int*", which is the same as that of my_s.x,
so the programmer means "my_s.x = a" in C's notation.

The second assignment is with "int" which is the type of *(my_s.x), so the
programmer means "my_s -> x = b" in C's notation.

My question is, suppose that the struct is defined as:

struct T { void *x; }
T my_t;
void *y;

What happens if I do this?

my_t.x = y;

How can I carry out this assignment?

my_t -> x = y;

[Do I have to force it by tricking the type system, thus: my_t.x =
(void)y;]

Does D allow the void* type?  Perhaps this suggests that it shouldn't?
(Could we do without it and use byte* instead?)


My second question concerns pointers and arrays.  In C you can have a
pointer to an array of ints:

int (*array)[3];

and an array of pointers to ints:

int *(array[3]);
int *array[3];

In D, you move the braces for the array next to the type.  The D
specification says that you declare a pointer to an array of ints like
this:

int[3] *array;

How do you declare an array of pointers to ints?  Since the * and the []
are now separated, it's harder to distinguish between them.
Oct 08 2001
parent reply "Walter" <walter digitalmars.com> writes:
"Ben Cohen" <bc skygate.co.uk> wrote in message
news:9ps3qb$hkt$1 digitaldaemon.com...

 My question is, suppose that the struct is defined as:
 struct T { void *x; }
 T my_t;
 void *y;
 What happens if I do this?
 my_t.x = y;
 How can I carry out this assignment?


I don't understand the problem. The types of y and x are the same, so the
value of y is put into my_t.x.


 Does D allow the void* type?  Perhaps this suggests that it shouldn't?
 (Could we do without it and use byte* instead?)


Yes. I don't see how. I've been considering that!



 The D
 specification says that you declare a pointer to an array of ints like
 this:

 int[3] *array;

 How do you declare an array of pointers to ints?


int*[3] array;
Oct 08 2001
next sibling parent reply "Ben Cohen" <bc skygate.co.uk> writes:
In article <9psqq1$1dk6$1 digitaldaemon.com>, "Walter"
<walter digitalmars.com> wrote:


 "Ben Cohen" <bc skygate.co.uk> wrote in message
 news:9ps3qb$hkt$1 digitaldaemon.com...

 My question is, suppose that the struct is defined as: struct T { void
 *x; }
 T my_t;
 void *y;
 What happens if I do this?
 my_t.x = y;
 How can I carry out this assignment?


 
 I don't understand the problem. The types of y and x are the same, so
 the value of y is put into my_t.x.


I wondered how the compiler would handle it if the types of my_t.x and
*(my_t.x) were the same.  This doesn't normally happen in C/D, so it
shouldn't be much of a problem.

However, if my_t.x is void*, then the type of *(my_t.x) isn't really
defined, so the programmer can make it anything; so we can make it void*
(e.g., we might want to make a linked list in a strange way).

But now the two types are the same.  So if I want to put the address y
into my_t.x then I can do the assignment above.  But if I want to put the
address y into *my_t.x, is there a similar assignment?

[If not, then presumably one of these will work:

my_t.x = (void) y;
*(my_t.x) = y;
my_t -> x = y;
]


 Does D allow the void* type?  Perhaps this suggests that it shouldn't?
 (Could we do without it and use byte* instead?)


 
 Yes. I don't see how. I've been considering that!


Could you add a generic "pointer" type? I.e., pointer would be void*, and
void* wouldn't be allowed anymore.



 The D
 specification says that you declare a pointer to an array of ints like
 this:

 int[3] *array;

 How do you declare an array of pointers to ints?


 
 int*[3] array;


Would it be possible to move the * in the first declaration to the left of
int, thus:

*int[3] array;

I kind of like the idea of associating the pointer symbol with the type
rather than the variable name.

Comparing the above two declarations with the C equivalents shows how C's
syntax is inside-out!
Oct 09 2001
parent "Walter" <walter digitalmars.com> writes:
"Ben Cohen" <bc skygate.co.uk> wrote in message
news:9puc22$9d3$1 digitaldaemon.com...

 In article <9psqq1$1dk6$1 digitaldaemon.com>, "Walter"
 <walter digitalmars.com> wrote:


 "Ben Cohen" <bc skygate.co.uk> wrote in message
 news:9ps3qb$hkt$1 digitaldaemon.com...

 My question is, suppose that the struct is defined as: struct T { void
 *x; }
 T my_t;
 void *y;
 What happens if I do this?
 my_t.x = y;
 How can I carry out this assignment?


 I don't understand the problem. The types of y and x are the same, so
 the value of y is put into my_t.x.


 I wondered how the compiler would handle it if the types of my_t.x and
 *(my_t.x) were the same.  This doesn't normally happen in C/D, so it
 shouldn't be much of a problem.
 However, if my_t.x is void*, then the type of *(my_t.x) isn't really
 defined, so the programmer can make it anything; so we can make it void*
 (e.g., we might want to make a linked list in a strange way).


The combining of the reference and value semantics into one operator, .,
instead of . and -> does not imply that void and void* are the same, or that
the two things are not distinguishable in contexts other than a . operator.


 Could you add a generic "pointer" type? I.e., pointer would be void*, and
 void* wouldn't be allowed anymore.


void* is the generic pointer.


 The D
 specification says that you declare a pointer to an array of ints like
 this:

 int[3] *array;

 How do you declare an array of pointers to ints?


 int*[3] array;


 Would it be possible to move the * in the first declaration to the left of
 int, thus:

 *int[3] array;

 I kind of like the idea of associating the pointer symbol with the type
 rather than the variable name.


The D way reads right to left: Array of 3 pointers to int.
Oct 09 2001
prev sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
I've got a specific request.

In C, incrementing a void * is not defined because void has no size.

For purposes of manipulating pointers, I'd like math on void* to work the
same as math on byte*.

struct S { byte[4] b; int a; }
S s;
void* p = s.b;
byte* pb = s.b;
p += 4;  // this wouldn't work in C, as it'd be adding 4*sizeof(void) == 4 *
0
pb += 4;
assert(p == pb);  // this should hold if the same operations are performed
on p and pb
(int*)p = 2; // stores 2 into s.a, of course this is highly platform
dependent.

I can't count the number of times in C/C++ I've had to cast my void* to
byte* to do math, then cast back to something else to actually access the
pointed-to values.  If we could manipulate the void* directly, it'd save
half the casts and alot of programmer tedium.

Sean


 Does D allow the void* type?  Perhaps this suggests that it shouldn't?
 (Could we do without it and use byte* instead?)
Oct 22 2001
parent reply Axel Kittenberger <axel dtone.org> writes:
Sean L. Palmer wrote:


 I've got a specific request.
 
 In C, incrementing a void * is not defined because void has no size.


Gcc manual, section 5 - Extensions to the C language familily.

http://gcc.gnu.org/onlinedocs/gcc-3.0.1/gcc_5.html#SEC86

----
* 5.19 Arithmetic on void- and Function-Pointers 

 In GNU C, addition and subtraction operations are supported on pointers to 
void and on pointers to functions. This is done by treating the size of a 
void or of a function as 1. 

 A consequence of this is that sizeof is also allowed on void and on 
function types, and returns 1. 

 The option `-Wpointer-arith' requests a warning if these extensions are 
used. 

----

I think one can take the whole section 5 of the gcc manual as good ideas 
beyond standard C. For every point there were fundamental requests, and 
thousends of people are "testing" them each day. Some extensions were not 
so wit and are deprecated, like multiline string constants or the structure 
'[elemnent] : value' is now repleaced by the ANSI standard '.element = 
value' syntax. However I guess also ANSI cannot 100% reject that the idea 
in structure initializiationby name was inspired first by gcc's properitary 
"pioneer" implementation.
 
- Axel
-- 
|D) http://www.dtone.org
Oct 22 2001
parent reply Russell Borogove <kaleja estarcion.com> writes:
Axel Kittenberger wrote:

 I think one can take the whole section 5 of the gcc manual as good ideas
 beyond standard C. For every point there were fundamental requests, and
 thousends of people are "testing" them each day. Some extensions were not
 so wit and are deprecated, like multiline string constants or the structure
 '[elemnent] : value' is now repleaced by the ANSI standard '.element =
 value' syntax. However I guess also ANSI cannot 100% reject that the idea
 in structure initializiationby name was inspired first by gcc's properitary
 "pioneer" implementation.


<flamebait>

It's true that gcc offers some tasty, powerful features like this, 
as well as some wilder ones (like being able to take the address of 
an arbitrary code label, for example). However, it's worth keeping 
in mind that there are downsides to this. The gcc development team
hasn't been known for cooperating well with the C++ standardization
process (for example, they unilaterally reject the #pragma mechanism
for standardizing access to nonstandard compiler features, simply 
because they don't think it's The Right Thing). If you take advantage of
gcc's extensions, your code will not be compatible with other compilers
out there, so you'll be locked into gcc. On the one hand, this isn't 
so very bad, because gcc exists on many more platforms than any other
compiler I know of -- but that means you're locked into any bugs in 
or drawbacks of gcc, of which there are more than a few.

It's rather depressing that when Microsoft takes an industry 
standard and adds incompatible features, the open-source and free
software communities rail loudly against them ("Embrace, Extend, 
and Eradicate"); meanwhile they remain utterly dependent on gcc 
and rarely discuss its political implications, or consider alternatives 
to it. 

</flamebait>

Cheers --

-RB
Oct 22 2001
next sibling parent Jan Knepper <jan smartsoft.cc> writes:
Russell Borogove wrote:


 <flamebait>

 It's rather depressing that when Microsoft takes an industry
 standard and adds incompatible features, the open-source and free
 software communities rail loudly against them ("Embrace, Extend,
 and Eradicate"); meanwhile they remain utterly dependent on gcc
 and rarely discuss its political implications, or consider alternatives
 to it.

 </flamebait>


<g>

Jan
Oct 22 2001
prev sibling parent reply Axel Kittenberger <axel dtone.org> writes:
Russell Borogove wrote:


 Axel Kittenberger wrote:

 I think one can take the whole section 5 of the gcc manual as good ideas
 beyond standard C. For every point there were fundamental requests, and
 thousends of people are "testing" them each day. Some extensions were not
 so wit and are deprecated, like multiline string constants or the
 structure '[elemnent] : value' is now repleaced by the ANSI standard
 '.element = value' syntax. However I guess also ANSI cannot 100% reject
 that the idea in structure initializiationby name was inspired first by
 gcc's properitary "pioneer" implementation.


 
 <flamebait>
 
 It's true that gcc offers some tasty, powerful features like this,
 as well as some wilder ones (like being able to take the address of
 an arbitrary code label, for example). However, it's worth keeping
 in mind that there are downsides to this. The gcc development team
 hasn't been known for cooperating well with the C++ standardization
 process (for example, they unilaterally reject the #pragma mechanism
 for standardizing access to nonstandard compiler features, simply
 because they don't think it's The Right Thing). If you take advantage of
 gcc's extensions, your code will not be compatible with other compilers
 out there, so you'll be locked into gcc. On the one hand, this isn't
 so very bad, because gcc exists on many more platforms than any other
 compiler I know of -- but that means you're locked into any bugs in
 or drawbacks of gcc, of which there are more than a few.
 
 It's rather depressing that when Microsoft takes an industry
 standard and adds incompatible features, the open-source and free
 software communities rail loudly against them ("Embrace, Extend,
 and Eradicate"); meanwhile they remain utterly dependent on gcc
 and rarely discuss its political implications, or consider alternatives
 to it.


The main point you're missing is that gcc is incontrast: Open Source, so if 
you really want it to behave different you can change it and redistribute 
it etc. Thats what OS is all about.

And note that gcc as simple a single command line parameter -ansi, where it 
surprisingly just behaves like the standard says to. (well at least as good 
any other compiler does :o) It just that a few people want strict ansi C 
after all.

To Rely or not to rely on gcc extensions is a politlal decision in 
development. If you target the linux platform there is nothing speaking 
against it. And honestly I find some of the extensions simplify my code, 
make it easier to write and to maintain. You're flaming is completly 
out of topic here, not that I did not suggest anybody to use gcc 
extensions, I suggested to look at them to get idea's for other language 
development. And if you're so against properitary extensions and beein 
locked to a single compiler, then what are you doing in this newsgroup 
after all? Do you think there will be more than one "D" compiler?


 but that means you're locked into any bugs in or drawbacks of gcc, of 


which there are more than a few.

That is typical empty accusations worth nothing themselfs, what bugs? what 
drawbacks?
Oct 23 2001
parent Russell Borogove <kaleja estarcion.com> writes:
I apologize for my careless statements, and for getting a bit too
far from the point in my earlier post.

I'd also like to point out that, from time to time, I will 
describe rhetorical positions which I do not necessarily 
support.

Axel Kittenberger wrote:

 The main point you're missing is that gcc is incontrast: Open Source, so if
 you really want it to behave different you can change it and redistribute
 it etc. Thats what OS is all about. 


This is a fair point, though it would be silly to delete the 
wacky extensions from the compiler and redistribute it as "gcc-sane"
or something; far easier to just decide not to use the wacky 
extensions.


 To Rely or not to rely on gcc extensions is a politlal decision in
 development. If you target the linux platform there is nothing speaking
 against it. And honestly I find some of the extensions simplify my code,
 make it easier to write and to maintain.


Likewise -- I've been in a situation where using the address-of-
label features in conjunction with a macro system greatly 
simplified implementation of a real-time state machine system. 
All that was necessary was to stop and consider whether we 
were likely to re-use the code on other platforms. 


 You're flaming is completly
 out of topic here, not that I did not suggest anybody to use gcc
 extensions, I suggested to look at them to get idea's for other language
 development.


True, I probably shouldn't have sounded off. 


 but that means you're locked into any bugs in or drawbacks of gcc, of


 which there are more than a few.
 
 That is typical empty accusations worth nothing themselfs, what bugs? what
 drawbacks?


Sorry, the "more than a few" was really a cheap shot that I should 
have resisted. 

My first-hand experience with back-end optimization bugs for the 
Hitachi SH target is several years out of date (and due to those 
intervening years, I can't recall now the exact problems I had). 
I'll freely admit that I don't know how good gcc is in its recent, 
heavily-exercised i386/Linux versions. As for drawbacks, I refer 
you to the past year or so of Al Stevens' column in Dr. Dobb's 
journal, wherein he describes his experiences with poor compile 
times, large binaries, and poor runtime performance associated with 
template code in the Standard C++ Library under gcc. 

I assert that there are bugs and drawbacks to any compiler I could 
name; using Microsoft proprietary compiler extensions, likewise, 
locks you into the bugs and drawbacks of Microsoft compilers --
of which there are more than a few.

-RB
Oct 23 2001