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