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 "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 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
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
parent reply 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
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 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 >>




 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 


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
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 reply 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
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 "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 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 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 reply "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
parent reply "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
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 reply "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
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