"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.

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

"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.

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

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

"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

"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.

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

"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.

"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