www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - What's the secret to static class members

reply Guido <guido mailinator.org> writes:
I'm using a static class member in a parent class, but can't get 
the compiler to see it.

Class Grid{
   public:
   uint xdim;
}

Class Holder : Grid {
   uint var;
}

Any of the following should work, but none of them do:
Grid.xdim = 0;

grid = new Grid;
grid.xdim = 0;

holder = new Holder;
holder.xdim = 0;

This is the way static class vars were intended to work. What 
magics have I forgotten?

Platform
DMD latest, Windows 7
Visual D
Jun 29 2016
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 29 June 2016 at 15:18:53 UTC, Guido wrote:

 I'm using a static class member in a parent class, but can't 
 get the compiler to see it.

 Class Grid{
   public:
   uint xdim;
 }


That's not static.... do `static uint xdim;` if you want it 
static (in this context, static means it is shared across all 
objects of the class)


 grid = new Grid;
 grid.xdim = 0;

 holder = new Holder;
 holder.xdim = 0;


those DO work if you declare the variable

auto grid = new Grid;
grid.xdim = 0;

auto holder = new Holder;
holder.xdim = 0;
Jun 29 2016
prev sibling parent reply Guido <guido mailinator.org> writes:
On Wednesday, 29 June 2016 at 15:18:53 UTC, Guido wrote:

 I'm using a static class member in a parent class, but can't 
 get the compiler to see it.

 Class Grid{
   public:
   uint xdim;
 }

 Class Holder : Grid {
   uint var;
 }

 Any of the following should work, but none of them do:
 Grid.xdim = 0;

 grid = new Grid;
 grid.xdim = 0;

 holder = new Holder;
 holder.xdim = 0;

 This is the way static class vars were intended to work. What 
 magics have I forgotten?

 Platform
 DMD latest, Windows 7
 Visual D


The problem is actually much more profound. The classes need to 
be declared outside the main() scope. WTF?!?!?!

I put them in main() so they would be in scope. This seems like a 
*MAJOR* design flaw with the language, not to mention the 
compiler not giving useful feedback. This decision, if it is a 
decision, makes no sense given all the attention to scoping rules.

I'm not interested in trading one set of bad language decisions 
for another. Can someone fix this?
Jun 29 2016
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 29 June 2016 at 15:33:58 UTC, Guido wrote:

 The problem is actually much more profound. The classes need to 
 be declared outside the main() scope. WTF?!?!?!


Not true.

What are you actually trying to compile?
Jun 29 2016
prev sibling next sibling parent reply Andrea Fontana <nospam example.com> writes:
On Wednesday, 29 June 2016 at 15:33:58 UTC, Guido wrote:

 The problem is actually much more profound. The classes need to 
 be declared outside the main() scope. WTF?!?!?!

 I put them in main() so they would be in scope. This seems like 
 a *MAJOR* design flaw with the language, not to mention the 
 compiler not giving useful feedback. This decision, if it is a 
 decision, makes no sense given all the attention to scoping 
 rules.

 I'm not interested in trading one set of bad language decisions 
 for another. Can someone fix this?


I wonder which language you usually use in your programming 
experience.
Jun 29 2016
parent reply Guido <guido mailinator.org> writes:
On Wednesday, 29 June 2016 at 15:40:57 UTC, Andrea Fontana wrote:

 On Wednesday, 29 June 2016 at 15:33:58 UTC, Guido wrote:

 The problem is actually much more profound. The classes need 
 to be declared outside the main() scope. WTF?!?!?!

 I put them in main() so they would be in scope. This seems 
 like a *MAJOR* design flaw with the language, not to mention 
 the compiler not giving useful feedback. This decision, if it 
 is a decision, makes no sense given all the attention to 
 scoping rules.

 I'm not interested in trading one set of bad language 
 decisions for another. Can someone fix this?


 I wonder which language you usually use in your programming 
 experience.


C++

I have all this business generally working in C++. I just wanted 
to try D for a production level quick project. So, the language 
is not ready. I'm really sad about this. I had hoped that I could 
get some useful work done. C++ is painfully slow to write & 
debug, but what can you do.

As I said, why exchange one set of bad design decisions for 
another?

On another topic, tuples seem to have a major problem as well.

Tuple!(float, float, float) test;
Tuple!(float, float, float) [] array_data;

test[0] = 1.0;  // works
array_data[i][0] = 1.0; // doesn't work. Compile-time error, 
probably because the language itself doesn't have a dedicated 
extension for tuple elements that is distinguished from array 
dereferencing. This is the logical extension of how to access 
tuples. I normally use structs in C++, but since pointer 
arithmetic is really frowned upon in D, I decided to use Tuples. 
A mistake, I supposed.

So, I've spent a huge amount of time getting ready to write in D. 
That's all wasted. I'll check back in another 10 years to see if 
your hobby language is still around. In the mean time, try to 
think about improving the compiler error messages. I can write 
code any way the language demands, but it has to make sense and I 
can't be doing a research project on the language every 10 
minutes to figure out the right incantation. I already have that 
with C++.

Bye
Jun 29 2016
next sibling parent ag0aep6g <anonymous example.com> writes:
On 06/29/2016 07:00 PM, Guido wrote:

 On another topic, tuples seem to have a major problem as well.

 Tuple!(float, float, float) test;
 Tuple!(float, float, float) [] array_data;

 test[0] = 1.0;  // works
 array_data[i][0] = 1.0; // doesn't work.


Works just fine for me, if I add the missing pieces (imports, main, set 
i, put something in array_data).

Please post complete code, the compile command, the compiler version 
you're using, and the error message you get. This applies to the 
original post as well.
Jun 29 2016
prev sibling next sibling parent Lodovico Giaretta <lodovico giaretart.net> writes:
On Wednesday, 29 June 2016 at 17:00:49 UTC, Guido wrote:

 I have all this business generally working in C++. I just 
 wanted to try D for a production level quick project. So, the 
 language is not ready. I'm really sad about this. I had hoped 
 that I could get some useful work done. C++ is painfully slow 
 to write & debug, but what can you do.

 As I said, why exchange one set of bad design decisions for 
 another?

 On another topic, tuples seem to have a major problem as well.

 Tuple!(float, float, float) test;
 Tuple!(float, float, float) [] array_data;

 test[0] = 1.0;  // works
 array_data[i][0] = 1.0; // doesn't work. Compile-time error, 
 probably because the language itself doesn't have a dedicated 
 extension for tuple elements that is distinguished from array 
 dereferencing. This is the logical extension of how to access 
 tuples. I normally use structs in C++, but since pointer 
 arithmetic is really frowned upon in D, I decided to use 
 Tuples. A mistake, I supposed.

 So, I've spent a huge amount of time getting ready to write in 
 D. That's all wasted. I'll check back in another 10 years to 
 see if your hobby language is still around. In the mean time, 
 try to think about improving the compiler error messages. I can 
 write code any way the language demands, but it has to make 
 sense and I can't be doing a research project on the language 
 every 10 minutes to figure out the right incantation. I already 
 have that with C++.

 Bye


Fun fact: the following does work as expected.

Tuple!(float, float, float) test;
Tuple!(float, float, float) [] array_data = new Tuple!(float, 
float, float) [3];

test[0] = 1.0;
array_data[2][0] = 1.0;

So... if something does not work, please, have at least the 
maturity to post the actual code that does not work. Posting code 
that works and then complaining with your tone doesn't make you 
look very professional.

But I guess I'm just loosing my time.

Bye.
Jun 29 2016
prev sibling next sibling parent FreeSlave <freeslave93 gmail.com> writes:
On Wednesday, 29 June 2016 at 17:00:49 UTC, Guido wrote:

 Tuple!(float, float, float) test;
 Tuple!(float, float, float) [] array_data;

 test[0] = 1.0;  // works
 array_data[i][0] = 1.0; // doesn't work. Compile-time error, 
 probably because the language itself doesn't have a dedicated


It works. Could you post the minimal example and error message it 
produces?
Jun 29 2016
prev sibling next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 06/29/2016 10:00 AM, Guido wrote:


 doesn't work.


As others said, everything that you've mentioned do indeed work:

void main() {
     class Grid {
         public:
         static uint xdim;
     }

     class Holder : Grid {
         uint var;
     }

     Grid.xdim = 0;

     auto grid = new Grid;
     grid.xdim = 0;

     auto holder = new Holder;
     holder.xdim = 0;

     import std.typecons;
     Tuple!(float, float, float) test;
     Tuple!(float, float, float) [] array_data;
     array_data ~= tuple(1.0f, 2.0f, 3.0f);

     test[0] = 1.0;
     int i = 0;
     array_data[i][0] = 1.0;
}

Ali
Jun 29 2016
prev sibling parent reply chmike <christophe meessen.net> writes:
On Wednesday, 29 June 2016 at 17:00:49 UTC, Guido wrote:

 On Wednesday, 29 June 2016 at 15:40:57 UTC, Andrea Fontana 
 wrote:

 On Wednesday, 29 June 2016 at 15:33:58 UTC, Guido wrote:

 The problem is actually much more profound. The classes need 
 to be declared outside the main() scope. WTF?!?!?!

 I put them in main() so they would be in scope. This seems 
 like a *MAJOR* design flaw with the language, not to mention 
 the compiler not giving useful feedback. This decision, if it 
 is a decision, makes no sense given all the attention to 
 scoping rules.

 I'm not interested in trading one set of bad language 
 decisions for another. Can someone fix this?


 I wonder which language you usually use in your programming 
 experience.


 C++

 I have all this business generally working in C++. I just 
 wanted to try D for a production level quick project. So, the 
 language is not ready. I'm really sad about this. I had hoped 
 that I could get some useful work done. C++ is painfully slow 
 to write & debug, but what can you do.

 As I said, why exchange one set of bad design decisions for 
 another?

 On another topic, tuples seem to have a major problem as well.

 Tuple!(float, float, float) test;
 Tuple!(float, float, float) [] array_data;

 test[0] = 1.0;  // works
 array_data[i][0] = 1.0; // doesn't work. Compile-time error,


Why don't you give at least the compiler error and the full code ?
If you don't want to publish your actual code, create a very 
small program reproducing the problem and show that to us.

I understand your frustration, but understand that there are many 
people here that volunteer to help you. You have to provide them 
sufficient info for this to work.


    Tuple!(float, float, float) [] array_data;

This declares a dynamic array that is initially empty 
(array_data.length == 0).
Accessing the i'th item can't work.

I'm a bit surprised the compiler would detect this problem 
because it is usually a run time error. So I suspect there are 
other problems with your code.


You could also have written

array_data ~= test;

which appends the value test to the dynamic array that will then 
contain one element. You could then have written

array_data[0][0] = 2.0;


Or you could also have written

Tuple!(float, float, float) [10] array_data;

which would have declared array_data as a fixed sized array of 10 
tuples.
In this case writing

array_data[1][0] = 1.0;

would have worked.


D is an excellent and mature language. Every language has its 
rules that needs to be learn.

Claiming the problems you encountered are due to bad design of 
the language is unfair if you don't expose clearly the problem 
and verify the problem is not your side. There is a deeply 
thought rationale for every rule of the D language.
If you don't understand the rationale or want to contest the 
choice of rules, then expose your point and arguments. People 
will helpfully answer you.

I did it myself and was always impressed by the quality of the 
responses and positive and helpful attitude of people in this 
forum.
Jun 29 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 29 June 2016 at 19:10:18 UTC, chmike wrote:


 Claiming the problems you encountered are due to bad design of 
 the language is unfair if you don't expose clearly the problem 
 and verify the problem is not your side. There is a deeply 
 thought rationale for every rule of the D language.
 If you don't understand the rationale or want to contest the 
 choice of rules, then expose your point and arguments. People 
 will helpfully answer you.

 I did it myself and was always impressed by the quality of the 
 responses and positive and helpful attitude of people in this 
 forum.


I think it's safe to say this guy is just trolling and we can 
ignore him.
Jun 29 2016
parent Dejan Lekic <dejan.lekic gmail.com> writes:
On Thursday, 30 June 2016 at 01:11:09 UTC, Mike Parker wrote:

 I think it's safe to say this guy is just trolling and we can 
 ignore him.


I was about to say the same, Mike. He is either trolling, or 
genuinely did not even bother to learn some language basics...
Jun 30 2016
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Wednesday, 29 June 2016 at 15:33:58 UTC, Guido wrote:


 The problem is actually much more profound. The classes need to 
 be declared outside the main() scope. WTF?!?!?!


It's not going to work anywhere if you type 'Class' as opposed to 
'class'. Types can be declared in any scope:

```
void main() {
     class Foo {
         static int x = 10;
     }

     assert(Foo.x == 10);
}
```
Jun 29 2016