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?

the value of y is put into my_t.x.

*(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 

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

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