Structs are second class citizens of... or maybe refugees of D, they are victims
of discrimination.
Following are the reasons:

1. most D programmers don't use struct, unless they happen to be the poor guy writing the C interface.

2. to use structs you have to use pointers, but the spec says pointers are only provided for C compatibility, structs are to be avoided as long as the world spins.

3. pointers + overloaded operators make a mess.... this is a less offensive
example: (*o) = (*t)[(*i) * (*j)] ... the pointers and operators are abusing
each other.

4. structs cannot have constructor, "static opCall" is best you can do.

5. structs are more efficient? Not when structs are passed around by value. To change a struct member: 1. make a copy 2. change the copy 3. Copy the copy back into the original location. Two damned copies for.... efficiency.

6. yes, you can use pointers to change a struct member without copying, if you can be bothered to define 2 accessor methods, one returns a copy another one returns a pointer.

7. Most standard containers (DTL) do not allow a pointer to a contained struct to be retrieved, all changes, or just about anything has to be done via copies.

8. structs have different behaviours between array and Vector, array [] returns a reference, Vector [] returns a copy, nice rookie trap.


Imho, following are little suggestions for structs to make first class citizens of D:

1. have some sort of reference semantic to replace pointers. Pointers are not necessary unless structs are used with "new"

2. add constructor for struct, destructors are not necessary.

I use structs because I need efficiency and stack allocated data structures, however, it is painful to see a C++ program turns into a C like program when ported to D.

Hong wrote:
> Structs are second class citizens of... or maybe refugees of D, they are victims
> of discrimination.
> Following are the reasons:
> 
> 1. most D programmers don't use struct, unless they happen to be the poor guy
> writing the C interface.
> 
> 2. to use structs you have to use pointers, but the spec says pointers are only
> provided for C compatibility, structs are to be avoided as long as the world
> spins.
> 
> 3. pointers + overloaded operators make a mess.... this is a less offensive
> example: (*o) = (*t)[(*i) * (*j)] ... the pointers and operators are abusing
> each other.
> 
> 4. structs cannot have constructor, "static opCall" is best you can do.
> 
> 5. structs are more efficient? Not when structs are passed around by value. To
> change a struct member: 1. make a copy 2. change the copy 3. Copy the copy back
> into the original location. Two damned copies for.... efficiency.
> 
> 6. yes, you can use pointers to change a struct member without copying, if you
> can be bothered to define 2 accessor methods, one returns a copy another one
> returns a pointer.
> 
> 7. Most standard containers (DTL) do not allow a pointer to a contained struct
> to be retrieved, all changes, or just about anything has to be done via copies.
> 
> 8. structs have different behaviours between array and Vector, array [] returns
> a reference, Vector [] returns a copy, nice rookie trap.
> 
> 
> Imho, following are little suggestions for structs to make first class citizens
> of D:
> 
> 1. have some sort of reference semantic to replace pointers. Pointers are not
> necessary unless structs are used with "new"
> 
> 2. add constructor for struct, destructors are not necessary.
> 
> I use structs because I need efficiency and stack allocated data structures,
> however, it is painful to see a C++ program turns into a C like program when
> ported to D.
> 
> 

structs are a light wieght alternative to classes.
Seriously, if structs don't suffice for your needs, use classes! You won't lose /that/ much performance.

Hong wrote:

> Imho, following are little suggestions for structs to make first class citizens
> of D:
> 
> 1. have some sort of reference semantic to replace pointers. Pointers are not
> necessary unless structs are used with "new"
> 
> 2. add constructor for struct, destructors are not necessary.
> 
> I use structs because I need efficiency and stack allocated data structures,
> however, it is painful to see a C++ program turns into a C like program when
> ported to D.
> 
> 

I agree with both these points, especially #1.  I wish D had some sort of reference attribute for other types similar to that designed into classes.  It's confusing moving back and forth between the practically deprecated pointers and the reference types native to classes.  Nor do pointers and references always intermix adequately in ADT's.

-JJR

Thanks, that is one work arounds, the avoidance approach. There are 2 approaches to structs,

1. Minimalist approach, use structs only for C interfaces, and tiny data types such as Point for GUI programming. Most Java programmer would prefer this.

2. Use structs for all data structures that do not require heap allocation, such as containers. MinTL is a good example. However, current support for struct makes this approach difficult. People used to C++ might prefer this approach, when performance is critical. If D is to gain a foot hold on the high performance computing world, such as scientific computing, more support for struct will be needed.

In article <e044ro$ifn$1@digitaldaemon.com>, Hasan Aljudy says...
>
>structs are a light wieght alternative to classes.
>Seriously, if structs don't suffice for your needs, use classes! You
>won't lose /that/ much performance.

Hong wrote:
> Structs are second class citizens of... or maybe refugees of D, they are victims
> of discrimination.
> Following are the reasons:
> 
> 1. most D programmers don't use struct, unless they happen to be the poor guy
> writing the C interface.
> 
I don't know, but are you aware of what a struct is used for? It encapsules data and provides an easy access to chunks of data related to one bunch of information / object.

> 2. to use structs you have to use pointers, but the spec says pointers are only
> provided for C compatibility, structs are to be avoided as long as the world
> spins.
> 
Who in the world told you not to use pointers? I haven't seen that in the documentation, sorry.

> 3. pointers + overloaded operators make a mess.... this is a less offensive
> example: (*o) = (*t)[(*i) * (*j)] ... the pointers and operators are abusing
> each other.
> 
> 4. structs cannot have constructor, "static opCall" is best you can do.
> 
Take a look at std.boxer, there you have a constructor like function/template.

> 5. structs are more efficient? Not when structs are passed around by value. To
> change a struct member: 1. make a copy 2. change the copy 3. Copy the copy back
> into the original location. Two damned copies for.... efficiency.
> 
As said, I can't find anything in the documentation that says you should not use pointers.

"Structs and unions are meant as simple aggregations of data, or as a way to paint a data structure over hardware or an external type. External types can be defined by the operating system API, or by a file format. Object oriented features are provided with the class data type."
-- http://www.digitalmars.com//d/struct.html

> 6. yes, you can use pointers to change a struct member without copying, if you
> can be bothered to define 2 accessor methods, one returns a copy another one
> returns a pointer.
> 
What's the problem here? Same goes with classes.

> 7. Most standard containers (DTL) do not allow a pointer to a contained struct
> to be retrieved, all changes, or just about anything has to be done via copies.
> 
> 8. structs have different behaviours between array and Vector, array [] returns
> a reference, Vector [] returns a copy, nice rookie trap.
> 
A Vector is no array, keep that in mind. There're still pointers, you know? ;)

> 
> Imho, following are little suggestions for structs to make first class citizens
> of D:
> 
> 1. have some sort of reference semantic to replace pointers. Pointers are not
> necessary unless structs are used with "new"
> 
Pointers *are* necessary. D is a high level language, of course, but also provides the ability to write low level code. And structs, as they *are*, are a very important part of this ability.

> 2. add constructor for struct, destructors are not necessary.
> 
As said before.

> I use structs because I need efficiency and stack allocated data structures,
> however, it is painful to see a C++ program turns into a C like program when
> ported to D.
> 
You can also provide effient code with classes, if you feel your code is 'ugly' with structs. Also, structs should not be abused. Structs are structs and classes are classes - they both have their specific purposes, one should not forget that.

Regards,
Alex

PS: No offense intended.

I hope you really know what you are talking about.

In article <e06353$7o9$1@digitaldaemon.com>, Alexander Panek says...
>
>Hong wrote:
>> Structs are second class citizens of... or maybe refugees of D, they are victims
>> of discrimination.
>> Following are the reasons:
>> 
>> 1. most D programmers don't use struct, unless they happen to be the poor guy writing the C interface.
>> 
>I don't know, but are you aware of what a struct is used for? It encapsules data and provides an easy access to chunks of data related to one bunch of information / object.
>
>> 2. to use structs you have to use pointers, but the spec says pointers are only provided for C compatibility, structs are to be avoided as long as the world spins.
>> 
>Who in the world told you not to use pointers? I haven't seen that in the documentation, sorry.
>
>> 3. pointers + overloaded operators make a mess.... this is a less offensive
>> example: (*o) = (*t)[(*i) * (*j)] ... the pointers and operators are abusing
>> each other.
>> 
>> 4. structs cannot have constructor, "static opCall" is best you can do.
>> 
>Take a look at std.boxer, there you have a constructor like function/template.
>
>> 5. structs are more efficient? Not when structs are passed around by value. To change a struct member: 1. make a copy 2. change the copy 3. Copy the copy back into the original location. Two damned copies for.... efficiency.
>> 
>As said, I can't find anything in the documentation that says you should not use pointers.
>
>"Structs and unions are meant as simple aggregations of data, or as a way to paint a data structure over hardware or an external type. External types can be defined by the operating system API, or by a file format. Object oriented features are provided with the class data type." -- http://www.digitalmars.com//d/struct.html
>
>> 6. yes, you can use pointers to change a struct member without copying, if you can be bothered to define 2 accessor methods, one returns a copy another one returns a pointer.
>> 
>What's the problem here? Same goes with classes.
>
>> 7. Most standard containers (DTL) do not allow a pointer to a contained struct to be retrieved, all changes, or just about anything has to be done via copies.
>> 
>> 8. structs have different behaviours between array and Vector, array [] returns a reference, Vector [] returns a copy, nice rookie trap.
>> 
>A Vector is no array, keep that in mind. There're still pointers, you know? ;)
>
>> 
>> Imho, following are little suggestions for structs to make first class citizens of D:
>> 
>> 1. have some sort of reference semantic to replace pointers. Pointers are not necessary unless structs are used with "new"
>> 
>Pointers *are* necessary. D is a high level language, of course, but also provides the ability to write low level code. And structs, as they *are*, are a very important part of this ability.
>
>> 2. add constructor for struct, destructors are not necessary.
>> 
>As said before.
>
>> I use structs because I need efficiency and stack allocated data structures, however, it is painful to see a C++ program turns into a C like program when ported to D.
>> 
>You can also provide effient code with classes, if you feel your code is 'ugly' with structs. Also, structs should not be abused. Structs are structs and classes are classes - they both have their specific purposes, one should not forget that.
>
>Regards,
>Alex
>
>PS: No offense intended.

Hong wrote:
> I hope you really know what you are talking about.
> 

Prove me wrong.

What's wrong with classes?!

Classes won't make your code slow.

Hong wrote:
> Thanks, that is one work arounds, the avoidance approach.
> There are 2 approaches to structs,
> 
> 1. Minimalist approach, use structs only for C interfaces, and tiny data types
> such as Point for GUI programming. Most Java programmer would prefer this.
> 
> 2. Use structs for all data structures that do not require heap allocation, such
> as containers. MinTL is a good example. However, current support for struct
> makes this approach difficult. People used to C++ might prefer this approach,
> when performance is critical. If D is to gain a foot hold on the high
> performance computing world, such as scientific computing, more support for
> struct will be needed.
> 
> In article <e044ro$ifn$1@digitaldaemon.com>, Hasan Aljudy says...
> 
>>structs are a light wieght alternative to classes.
>>Seriously, if structs don't suffice for your needs, use classes! You won't lose /that/ much performance.
> 
> 
> 

In article <e07506$1ss2$1@digitaldaemon.com>, Hasan Aljudy says...
>
>What's wrong with classes?!
>
>Classes won't make your code slow.
>

HA!! I know someone who has done research on exactly that and says that they make code VARY slow (as in several times slower) I'll talk to him tomorrow and see if I can get some links to post.

One example of things that make classes slow is that all methods are called by
reference (from object* get vtbl (1), add index (2), load (3) call from ptr(4)
as opposed to call function from incline address)

The other thing is that structs don't have a vtbl in each instance and therefor can be used to map data to files and hardwear.

Ok, even people are telling me that class is not slower, I have decided to make a benchmark to test them out. Here they are,

Version using struct http://members.iinet.net.au/~honglee/benchmark/benchmarkstruct.d

Version using class http://members.iinet.net.au/~honglee/benchmark/benchmarkclass.d

On my computer, the struct version runs 300 times faster than the class version. Interestingly, deleting the object explicitly in the class version actually slowed the program even further.

The difference seems real.

In article <e07506$1ss2$1@digitaldaemon.com>, Hasan Aljudy says...
>
>What's wrong with classes?!
>
>Classes won't make your code slow.
>