www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Dynamic Arrays & Class Properties

reply Mason Green <mason.green gmail.com> writes:
Hi,

Anyone know how to expose dynamic array elements via class properties?  I would
like to do something this this:

class Foo {

    private int[] m_dummy;

    this() {
        m_dummy ~= 19;
        m_dummy ~= 77;
    }

    int dummy( ??????? ) {
        return m_dummy[x];
    }
}

void main() {
    auto foo = new Foo();
    Cout(foo.dummty[0]);     // Print 19
}

Any help would be much appreciated!  The question marks are where I'm stuck....

Thanks,
Mason
Aug 27 2008
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 27 Aug 2008 17:59:09 +0400, Mason Green <mason.green gmail.com>  
wrote:

 Hi,

 Anyone know how to expose dynamic array elements via class properties?   
 I would like to do something this this:

 class Foo {

     private int[] m_dummy;

     this() {
         m_dummy ~= 19;
         m_dummy ~= 77;
     }

     int dummy( ??????? ) {
         return m_dummy[x];
     }
 }

 void main() {
     auto foo = new Foo();
     Cout(foo.dummty[0]);     // Print 19
 }

 Any help would be much appreciated!  The question marks are where I'm  
 stuck....

 Thanks,
 Mason

maybe something like this: struct ConstArrayReference(T) { T opIndex(int index) { return array[index]; } private T[] array; } class Foo { private int[] m_dummy; this() { m_dummy ~= 19; m_dummy ~= 77; } ConstArrayReference!(int) dummy() { ConstArrayReference!(int) r = { m_dummy }; return r; } } void main() { auto foo = new Foo(); Cout(foo.dummy[0]).newline; // Prints 19 } Too bad we don't have references (yet?) :(
Aug 27 2008
parent reply Mason Green <mason.green gmail.com> writes:
Denis Koroskin Wrote:

 maybe something like this:
 
 struct ConstArrayReference(T)
 {
          T opIndex(int index) {
                  return array[index];
          }
 
          private T[] array;
 }
 
 class Foo
 {
      private int[] m_dummy;
 
      this() {
          m_dummy ~= 19;
          m_dummy ~= 77;
      }
 
      ConstArrayReference!(int) dummy() {
          ConstArrayReference!(int) r = { m_dummy };
          return r;
      }
 }
 
 void main() {
      auto foo = new Foo();
      Cout(foo.dummy[0]).newline;     // Prints 19
 }
 
 
 Too bad we don't have references (yet?) :(

Thanks for the smart solution! Unfortunately this seems like a lot of extra overhead... I may just end up keeping the dynamic arrays public! In this particular case it would be nice to have the option of declaring friend classes, like in C++!!! Regards, Mason
Aug 27 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Mason Green" <mason.green gmail.com> wrote in message 
news:g93sue$k3v$1 digitalmars.com...
 Denis Koroskin Wrote:

 maybe something like this:

 struct ConstArrayReference(T)
 {
          T opIndex(int index) {
                  return array[index];
          }

          private T[] array;
 }

 class Foo
 {
      private int[] m_dummy;

      this() {
          m_dummy ~= 19;
          m_dummy ~= 77;
      }

      ConstArrayReference!(int) dummy() {
          ConstArrayReference!(int) r = { m_dummy };
          return r;
      }
 }

 void main() {
      auto foo = new Foo();
      Cout(foo.dummy[0]).newline;     // Prints 19
 }


 Too bad we don't have references (yet?) :(

Thanks for the smart solution! Unfortunately this seems like a lot of extra overhead... I may just end up keeping the dynamic arrays public!

There's no memory/register overhead; ConstArrayReference!(T).sizeof == (T[]).sizeof. And if you use -inline, there's no function call overhead either. :)
Aug 27 2008
parent reply Mason Green <mason.green gmail.com> writes:
Jarrett Billingsley Wrote:

 
 There's no memory/register overhead; ConstArrayReference!(T).sizeof == 
 (T[]).sizeof.
 
 And if you use -inline, there's no function call overhead either.  :) 
 
 

Ah, thanks for the tip! BTW, how much does using the -inline compiler flag have an effect on improving performance? Anyone have a good explanation as to how it works? Thanks, Mason
Aug 28 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Mason Green" <mason.green gmail.com> wrote in message 
news:g96346$94o$1 digitalmars.com...
 Jarrett Billingsley Wrote:

 There's no memory/register overhead; ConstArrayReference!(T).sizeof ==
 (T[]).sizeof.

 And if you use -inline, there's no function call overhead either.  :)

Ah, thanks for the tip! BTW, how much does using the -inline compiler flag have an effect on improving performance? Anyone have a good explanation as to how it works? Thanks, Mason

It uh, inlines function calls. So if you have a small function like: int getSomething(ref SomeStruct s) { return s.x * SomeConstant; } and you call it: auto foo = getSomething(s); It can inline the call to that function, making it effectively: auto foo = s.x * SomeConstant; but with the advantage that you don't have to break the rules of the language to do it (i.e. even if s.x is private, this will still work. Removing function calls, especially in tight loops and with very-often-called functions, *can* really improve performance. The compiler has a cost/benefit heuristic that it uses to decide what functions should be inlined and what functions should just be called at runtime. I'm not entirely sure the rules it uses but I know that any loops used in the function automatically disqualifies it for inlining. More or less if your function is a one-liner that just evaluates an expression you can almost be guaranteed that it'll be inlined. Notice before I said that inlining *can* improve performance. It also *can* make it worse. If it inlines too much, tight loops can become too large to fit into the processor's instruction cache and the code can actually run slower than if it were a separate function. But in many cases, inlining improves perfomance. How much is certainly a function of your coding style, what mood the compiler is in, and the phase of the moon. Be warned though: the DMD backend sometimes generates buggy or incorrect code when using -inline, so be sure to test thoroughly both with and without the flag.
Aug 28 2008
next sibling parent Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Jarrett Billingsley wrote:
 
 Be warned though: the DMD backend sometimes generates buggy or incorrect 
 code when using -inline, so be sure to test thoroughly both with and without 
 the flag. 
 
 

This is very much nitpicking, but the DMD *backend* is most likely not at fault here. All inlining is done in the frontend at the AST level, which is what is broken. In LLVMDC I've had to disable the DMDFE inlining as it completely breaks our codegen. Luckily LLVM does a pretty good job at inlining on the bitcode IR... Tomas
Aug 28 2008
prev sibling parent reply Brad Roberts <braddr bellevue.puremagic.com> writes:
On Thu, 28 Aug 2008, Jarrett Billingsley wrote:

 Be warned though: the DMD backend sometimes generates buggy or incorrect 
 code when using -inline, so be sure to test thoroughly both with and without 
 the flag. 

Can you substantiate that with reproducable bug reports? I'm sure Walter would appreciate it and place high prioirty on fixing such problems. Thanks, Brad
Aug 28 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Brad Roberts" <braddr bellevue.puremagic.com> wrote in message 
news:alpine.DEB.1.10.0808281424310.21051 bellevue.puremagic.com...
 On Thu, 28 Aug 2008, Jarrett Billingsley wrote:

 Be warned though: the DMD backend sometimes generates buggy or incorrect
 code when using -inline, so be sure to test thoroughly both with and 
 without
 the flag.

Can you substantiate that with reproducable bug reports? I'm sure Walter would appreciate it and place high prioirty on fixing such problems. Thanks, Brad

You know, I'd love to be able to track down every heisenbug that spuriously shows up and then disappears with the smallest change in my 25000-line library when I use -inline, but I unfortunately don't have the time.
Aug 28 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Brad Roberts" <braddr bellevue.puremagic.com> wrote in message 
news:alpine.DEB.1.10.0808281527010.21051 bellevue.puremagic.com...

 How about starting with _one_?

 Without substantiation that it's actually a bug with inlining and not just
 a bug in your code or some other problem, these types of reports have to
 be considered FUD.

 Sigh,
 Brad 

Aug 28 2008
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:g97aa7$u97$1 digitalmars.com...
 "Brad Roberts" <braddr bellevue.puremagic.com> wrote in message 
 news:alpine.DEB.1.10.0808281527010.21051 bellevue.puremagic.com...

 How about starting with _one_?

 Without substantiation that it's actually a bug with inlining and not 
 just
 a bug in your code or some other problem, these types of reports have to
 be considered FUD.

 Sigh,
 Brad


Stupid stupid OE and its Ctrl+Enter "shortcut". Call it what you want, but I for one am tired of copying my source tree, running the example code in a debugging environment that doesn't entirely support D, hoping that the locations and call stack that it's giving me are correct, systematically chopping out bits of code and patching things up so that the damn thing will recompile, finding that removing a function or class that is never used causes the bug to fix itself, putting it back in, slowly whittling the code down over a period of two hours, only to end up with a 3000-line chunk of nonsensical mess that doesn't seem to be any further simplifiable without causing the bug to disappear or another one to crop up in its place. I've followed this procedure several times and only once or twice was I able to chop it down to a piece of code that obviously reproduces the bug in which cases I did create tickets. But most of the time it's not possible or reasonable to try to do so. Even if -inline or -O or whatever seems to work when compiling just my library, invariably when someone else starts using it in a different environment, importing other libraries, and putting inputs into it that I never did, weird bugs show up. These are not even just simple "access violation" bugs. We're talking "GC/runtime corrupting data that it really shouldn't during the 50,000th run" or "the program behaving exactly as expected except that sometimes floating-point operations end up as nan for no obvious reason and seemingly randomly dependent upon the inputs." Stuff that I don't have the patience or knowledge to track down. I'd also say that when code runs perfectly without -inline and weird bugs show up when turning it on, with no other changes to the build environment, that says to me that it's a problem with inlining. You say it's FUD. I say it's what I've experienced, and sorry if I have neither the time nor the patience to deal with it every time its come up, and what I _can_ do about it is warn others.
Aug 28 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Brad Roberts" wrote
 On Thu, 28 Aug 2008, Jarrett Billingsley wrote:

 "Brad Roberts" <braddr bellevue.puremagic.com> wrote in message
 news:alpine.DEB.1.10.0808281424310.21051 bellevue.puremagic.com...
 On Thu, 28 Aug 2008, Jarrett Billingsley wrote:

 Be warned though: the DMD backend sometimes generates buggy or 
 incorrect
 code when using -inline, so be sure to test thoroughly both with and
 without
 the flag.

Can you substantiate that with reproducable bug reports? I'm sure Walter would appreciate it and place high prioirty on fixing such problems. Thanks, Brad

You know, I'd love to be able to track down every heisenbug that spuriously shows up and then disappears with the smallest change in my 25000-line library when I use -inline, but I unfortunately don't have the time.

How about starting with _one_? Without substantiation that it's actually a bug with inlining and not just a bug in your code or some other problem, these types of reports have to be considered FUD. Sigh, Brad

Jarrett is right. And it is REALLY difficult to narrow these things down. The problem is with these types of bugs, one seemingly unrelated change makes the whole thing start working, so I bet a lot of these types of things go unreported (as he said, who wants to paste a 25k line program to bugzilla? It'll just get ignored). Here is one I stumbled across while helping someone debug Tango's filesystem abstraction. This is the smallest I could get it to (took me about 2 hours to narrow it down). I'd really appreciate if Walter or whoever would fix this one: http://d.puremagic.com/issues/show_bug.cgi?id=2232 -Steve
Aug 28 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Brad Roberts wrote:
 Ok Walter, don't make a liar outta me.. go look at Steve's report. :)

Yes, it's a real bug, and I have it fixed now (will go out in next update). Thanks, Steven!
Aug 29 2008
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Walter Bright" wrote
 Brad Roberts wrote:
 Ok Walter, don't make a liar outta me.. go look at Steve's report. :)

Yes, it's a real bug, and I have it fixed now (will go out in next update). Thanks, Steven!

No, thank you! :D -Steve
Aug 29 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Brad Roberts wrote:
 Out of curiosity, what part of the compiler contained the bug?

The back end that dealt with comma operators.
Aug 29 2008
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:
 (took me about 2 hours to narrow it down).

Take a look at the Python program in the Zeller directory here: http://examples.oreilly.com/9780596510046/examples.zip It may do what you have done in matter of minutes, by itself. A similar but more refined tool in Python may be added to Phobos/Tango (and no, translating it into D isn't an improvement). Bye, bearophile
Sep 01 2008
prev sibling next sibling parent Brad Roberts <braddr bellevue.puremagic.com> writes:
On Thu, 28 Aug 2008, Jarrett Billingsley wrote:

 "Brad Roberts" <braddr bellevue.puremagic.com> wrote in message 
 news:alpine.DEB.1.10.0808281424310.21051 bellevue.puremagic.com...
 On Thu, 28 Aug 2008, Jarrett Billingsley wrote:

 Be warned though: the DMD backend sometimes generates buggy or incorrect
 code when using -inline, so be sure to test thoroughly both with and 
 without
 the flag.

Can you substantiate that with reproducable bug reports? I'm sure Walter would appreciate it and place high prioirty on fixing such problems. Thanks, Brad

You know, I'd love to be able to track down every heisenbug that spuriously shows up and then disappears with the smallest change in my 25000-line library when I use -inline, but I unfortunately don't have the time.

How about starting with _one_? Without substantiation that it's actually a bug with inlining and not just a bug in your code or some other problem, these types of reports have to be considered FUD. Sigh, Brad
Aug 28 2008
prev sibling parent Brad Roberts <braddr bellevue.puremagic.com> writes:
On Fri, 29 Aug 2008, Steven Schveighoffer wrote:

 "Brad Roberts" wrote
 
 On Thu, 28 Aug 2008, Jarrett Billingsley wrote:
 
 "Brad Roberts" <braddr bellevue.puremagic.com> wrote in message
 news:alpine.DEB.1.10.0808281424310.21051 bellevue.puremagic.com...
 On Thu, 28 Aug 2008, Jarrett Billingsley wrote:

 Be warned though: the DMD backend sometimes generates buggy or >>


 code when using -inline, so be sure to test thoroughly both with and
 without
 the flag.

Can you substantiate that with reproducable bug reports? I'm sure >

 would appreciate it and place high prioirty on fixing such problems.

 Thanks,
 Brad

You know, I'd love to be able to track down every heisenbug that spuriously shows up and then disappears with the smallest change in my 25000-line library when I use -inline, but I unfortunately don't have the time.

How about starting with _one_? Without substantiation that it's actually a bug with inlining and not just a bug in your code or some other problem, these types of reports have to be considered FUD. Sigh, Brad

Jarrett is right. And it is REALLY difficult to narrow these things down. The problem is with these types of bugs, one seemingly unrelated change makes the whole thing start working, so I bet a lot of these types of things go unreported (as he said, who wants to paste a 25k line program to bugzilla? It'll just get ignored). Here is one I stumbled across while helping someone debug Tango's filesystem abstraction. This is the smallest I could get it to (took me about 2 hours to narrow it down). I'd really appreciate if Walter or whoever would fix this one: http://d.puremagic.com/issues/show_bug.cgi?id=2232 -Steve

Trust me, I'm _well_ aware of the difficulty. I'm also just as aware that saying it's buggy will never result in a bug being fixed. Reports, such as yours, will. Thanks for going through the effort of trimming it down to something relatively small. I've tracked down bugs in quite a few different compilers over the years, in code bases much much larger than talked about in this thread. It's a pain, but it's important. I've also tracked down bugs that I coulda sworn were compiler bugs but turned out to be my own bugs. Until you do the work, you can't ever be sure. Ok Walter, don't make a liar outta me.. go look at Steve's report. :) Thanks, Brad
Aug 29 2008
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
Walter Bright wrote:
 Brad Roberts wrote:
 Ok Walter, don't make a liar outta me.. go look at Steve's report. :)

Yes, it's a real bug, and I have it fixed now (will go out in next update). Thanks, Steven!

Out of curiosity, what part of the compiler contained the bug? Thanks, Brad
Aug 29 2008
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 27 Aug 2008 19:47:26 +0400, Mason Green <mason.green gmail.com>  
wrote:

 Denis Koroskin Wrote:

 maybe something like this:

 struct ConstArrayReference(T)
 {
          T opIndex(int index) {
                  return array[index];
          }

          private T[] array;
 }

 class Foo
 {
      private int[] m_dummy;

      this() {
          m_dummy ~= 19;
          m_dummy ~= 77;
      }

      ConstArrayReference!(int) dummy() {
          ConstArrayReference!(int) r = { m_dummy };
          return r;
      }
 }

 void main() {
      auto foo = new Foo();
      Cout(foo.dummy[0]).newline;     // Prints 19
 }


 Too bad we don't have references (yet?) :(

Thanks for the smart solution! Unfortunately this seems like a lot of extra overhead...

No, there shouldn't be any. But the code doesn't look good.
 I may just end up keeping the dynamic arrays public!

 In this particular case it would be nice to have the option of declaring  
 friend classes, like in C++!!!

 Regards,
 Mason

Aug 27 2008
prev sibling next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Mason Green <mason.green gmail.com> wrote:
 Hi,
 
 Anyone know how to expose dynamic array elements via class properties?  I
would like to do something this this:
 
 class Foo {
 
     private int[] m_dummy;
 
     this() {
         m_dummy ~= 19;
         m_dummy ~= 77;
     }
 
     int dummy( ??????? ) {
         return m_dummy[x];
     }
 }
 
 void main() {
     auto foo = new Foo();
     Cout(foo.dummty[0]);     // Print 19
 }
 
 Any help would be much appreciated!  The question marks are where I'm stuck....

class Foo { private int[] m_dummy; const int dummy() { return m_dummy; } } I think this is better than tons of templates. -- SnakE
Aug 28 2008
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Denis Koroskin" <2korden gmail.com> wrote in message 
news:op.ugl05wn1o7cclz proton.creatstudio.intranet...
 On Thu, 28 Aug 2008 22:22:44 +0400, Sergey Gromov <snake.scaly gmail.com> 
 wrote:

 Mason Green <mason.green gmail.com> wrote:
 Hi,

 Anyone know how to expose dynamic array elements via class properties? 
 I would like to do something this this:

 class Foo {

     private int[] m_dummy;

     this() {
         m_dummy ~= 19;
         m_dummy ~= 77;
     }

     int dummy( ??????? ) {
         return m_dummy[x];
     }
 }

 void main() {
     auto foo = new Foo();
     Cout(foo.dummty[0]);     // Print 19
 }

 Any help would be much appreciated!  The question marks are where I'm 
 stuck....

class Foo { private int[] m_dummy; const int dummy() { return m_dummy; } } I think this is better than tons of templates.

First, it should be like this: class Foo { this() { m_dummy = new int[1]; m_dummy[0] = 19; } const(int)[] dummy() { return m_dummy; } private int[] m_dummy; } Second, that's D2 :) That's kinda strange, but unfortunately most of the discussion here is about D1, not D2 :( There is no const in D1: const int[] test = [0, 1, 2, 3]; test[0] = 2; writefln(test[0]); // prints 2

On Windows. I'd bet that'd give you a segfault on Linux. Though it doesn't change the fact that it's actually incorrect and that the compiler really *should* give an error for it.
Aug 28 2008
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 28 Aug 2008 22:22:44 +0400, Sergey Gromov <snake.scaly gmail.com>  
wrote:

 Mason Green <mason.green gmail.com> wrote:
 Hi,

 Anyone know how to expose dynamic array elements via class properties?   
 I would like to do something this this:

 class Foo {

     private int[] m_dummy;

     this() {
         m_dummy ~= 19;
         m_dummy ~= 77;
     }

     int dummy( ??????? ) {
         return m_dummy[x];
     }
 }

 void main() {
     auto foo = new Foo();
     Cout(foo.dummty[0]);     // Print 19
 }

 Any help would be much appreciated!  The question marks are where I'm  
 stuck....

class Foo { private int[] m_dummy; const int dummy() { return m_dummy; } } I think this is better than tons of templates.

First, it should be like this: class Foo { this() { m_dummy = new int[1]; m_dummy[0] = 19; } const(int)[] dummy() { return m_dummy; } private int[] m_dummy; } Second, that's D2 :) That's kinda strange, but unfortunately most of the discussion here is about D1, not D2 :( There is no const in D1: const int[] test = [0, 1, 2, 3]; test[0] = 2; writefln(test[0]); // prints 2
Aug 28 2008
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 29 Aug 2008 01:19:34 +0400, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:

 "Denis Koroskin" <2korden gmail.com> wrote in message
 news:op.ugl05wn1o7cclz proton.creatstudio.intranet...
 On Thu, 28 Aug 2008 22:22:44 +0400, Sergey Gromov  
 <snake.scaly gmail.com>
 wrote:

 Mason Green <mason.green gmail.com> wrote:
 Hi,

 Anyone know how to expose dynamic array elements via class properties?
 I would like to do something this this:

 class Foo {

     private int[] m_dummy;

     this() {
         m_dummy ~= 19;
         m_dummy ~= 77;
     }

     int dummy( ??????? ) {
         return m_dummy[x];
     }
 }

 void main() {
     auto foo = new Foo();
     Cout(foo.dummty[0]);     // Print 19
 }

 Any help would be much appreciated!  The question marks are where I'm
 stuck....

class Foo { private int[] m_dummy; const int dummy() { return m_dummy; } } I think this is better than tons of templates.

First, it should be like this: class Foo { this() { m_dummy = new int[1]; m_dummy[0] = 19; } const(int)[] dummy() { return m_dummy; } private int[] m_dummy; } Second, that's D2 :) That's kinda strange, but unfortunately most of the discussion here is about D1, not D2 :( There is no const in D1: const int[] test = [0, 1, 2, 3]; test[0] = 2; writefln(test[0]); // prints 2

On Windows. I'd bet that'd give you a segfault on Linux. Though it doesn't change the fact that it's actually incorrect and that the compiler really *should* give an error for it.

There is also a final in D1: final char[] test = "hello"; test.length = 4; // Error: cannot modify final variable 'test' test = "world"; // Error: cannot modify final variable 'test' but it doesn't work very well, too: test[0] = '!'; // success and everything compiles "fine" with -v1 switch (what does it do?): final char[] test = "hello"; test.length = 4; // no error
Aug 28 2008
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bill Baxter" <wbaxter gmail.com> wrote in message 
news:mailman.26.1219971010.19733.digitalmars-d-learn puremagic.com...
 On Thu, Aug 28, 2008 at 3:39 PM, Denis Koroskin <2korden gmail.com> wrote:
 There is also a final in D1:

 final char[] test = "hello";
 test.length = 4; // Error: cannot modify final variable 'test'
 test = "world";  // Error: cannot modify final variable 'test'

 but it doesn't work very well, too:
 test[0] = '!'; // success

I think that's correct behavior. 'final' is supposed to be a kind of head-const, no? So all the bits of 'test' on the stack are immutable, but the bits on the heap are mutable.
 and everything compiles "fine" with -v1 switch (what does it do?):
 final char[] test = "hello";
 test.length = 4; // no error

If I'm not mistaken, -v1 means act like some antiquated version of the D compiler that no one cares about any more.

Or rather "follow the strict D1 spec" since there were breaking changes that came out after 1.000 that are not _technically_ part of D1. ref, change in .init, string mixins, import expressions.. I call it "D 1.x" but I don't know what Walter's view on it is -- if the current D compiler actually _is_ D1 or if DMD 1.000 is.
Aug 28 2008
prev sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Aug 28, 2008 at 3:39 PM, Denis Koroskin <2korden gmail.com> wrote:
 There is also a final in D1:

 final char[] test = "hello";
 test.length = 4; // Error: cannot modify final variable 'test'
 test = "world";  // Error: cannot modify final variable 'test'

 but it doesn't work very well, too:
 test[0] = '!'; // success

I think that's correct behavior. 'final' is supposed to be a kind of head-const, no? So all the bits of 'test' on the stack are immutable, but the bits on the heap are mutable.
 and everything compiles "fine" with -v1 switch (what does it do?):
 final char[] test = "hello";
 test.length = 4; // no error

If I'm not mistaken, -v1 means act like some antiquated version of the D compiler that no one cares about any more. --bb
Aug 28 2008