Re: Implement the "unum" representation in D ?
On Friday, 18 September 2015 at 09:25:00 UTC, Ola Fosheim Grøstad wrote: D is created by hackers who enjoy hacking. They don't have the focus on correctness that verifiable-anything requires. So if you enjoy hacking you'll have fun. If are into reliability, stability and correctness you'll get frustrated. I'm not even sure you can have it both ways (both have a hacker mindset and a correctness mindset in the same design process). You forgot to mention that D is quite attractive for people who just want to complain on forums.
Re: Reasons to use D
On Friday, 11 September 2015 at 19:54:55 UTC, Adam D. Ruppe wrote: On Friday, 11 September 2015 at 15:30:05 UTC, Sebastiaan Koppe wrote: Does it have to do with char encodings? Not the issue I hit. Ah, forget about my suggestion, I misread something on the link you send. So when it said "This method uses the browser's innerHTML property", I wasn't expecting it to behave significantly differently! That is not the only way it behaves differently. jQuery's html() will actually execute inline script, whereas innerHTML won't. Coming back to the thread's title, jQuery is a perfectly valid reason to use D. Sad that there is no proper way to do modern web development in D.
Re: Interesting user mistake
On Thursday, 3 September 2015 at 16:46:30 UTC, Andrei Alexandrescu wrote: http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang The gist of it is the user wrote =+ instead of +=. I wonder if we should disallow during tokenization the sequence "=", "+", whitespace. Surely it's not a formatting anyone would aim for, but instead a misspelling of +=. Andrei Seems like a really, really small fish to catch. I wouldn't want to litter my codebase with those kind of rules. Besides, isn't stackoverflow about the answers and opinions, rather than about the questions?
Re: GC-proof resource classes
On Sunday, 30 August 2015 at 09:54:31 UTC, ponce wrote: On Saturday, 29 August 2015 at 16:12:52 UTC, skoppe wrote: I don't think it is a good idea to call create_handle() in the constructor. Why not just pass a handle into the Resource? This isn't related to the topic. By putting create_handle in the constructor, you inevitably end up putting free_handle in some (destructor) function. The problems you are having might be different/easier when you make something else do the (de)construction. Like, say, a ResourceManager.
Re: GC-proof resource classes
On Saturday, 29 August 2015 at 13:14:26 UTC, ponce wrote:
class MyResource
{
void* handle;
this()
{
handle = create_handle();
}
~this()
{
if (handle != null) // must support repeated calls for
the case (called by .destroy + called by GC later)
{
ensureNotInGC(MyResource);
free_handle(handle);
}
}
}
I don't think it is a good idea to call create_handle() in the
constructor. Why not just pass a handle into the Resource?
