Dynamic Arrays & Class Properties

Jarrett Billingsley kb3ctd2 at yahoo.com
Thu Aug 28 16:05:27 PDT 2008


"Jarrett Billingsley" <kb3ctd2 at yahoo.com> wrote in message 
news:g97aa7$u97$1 at digitalmars.com...
> "Brad Roberts" <braddr at bellevue.puremagic.com> wrote in message 
> news:alpine.DEB.1.10.0808281527010.21051 at 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. 




More information about the Digitalmars-d-learn mailing list