ToNyTeCh Wrote:
> Nick Sabalausky wrote:
> > "ToNyTeCh" wrote in message
> > news:imri5l$1ahi$1...@digitalmars.com...
> >> Seriously, I wanna know. How many lines of compiler code does it
> >> take for each (Walt should have the best handle on this, surely)?
> >> The LOC is one parameter, but I d
== Quote from ToNyTeCh (t...@nospam.net)'s article
> It doesn't matter to me. I was just posting when I wasn't drunk.
Good for you. It certainly explains a lot.
Walter Bright Wrote:
> On 4/2/2011 3:27 PM, ulrik.mikaels...@gmail.com wrote:
> > As I wrote, I think it's great that 010 != 8 anymore.
>
> 010, etc., will now be errors. They will not be 10 decimal.
>
> Also, the literals 00, 01, ..., 07 will still be accepted without complaint.
> 08,
> 09, e
== Quote from Daniel Gibson (metalcae...@gmail.com)'s article
> > I am concerned about the choice of relegating a kind of number literal to a
library template. Doesn't this needlessly impact performance?
> No, it's a template, so it's evaluated at compile-time and doesn't impact
> (runtime) perfor
Are there plans to deprecate the built-in complex types soon?
== Quote from Moritz Warning (moritzwarn...@web.de)'s article
> On Sun, 03 Apr 2011 00:48:29 +, Francisco Almeida wrote:
> > Are there plans to deprecate the built-in complex types soon?
> I assume they will be deprecated when a library replacement is feasible
> and imp
== Quote from Andrej Mitrovic (n...@none.none)'s article
> On 4/3/11, Matthias Pleh wrote:
> > * dgui -> windows only, also really .Net-like
> So what's the state of things for this new(?) Windows GUI library?
> I gave it a test run yesterday, examples seem to compile and apps seem to load
really
Andrei Alexandrescu Wrote:
> I wonder how accurate this language popularity index is.
>
> Andrei
Not only is popularity not well defined, some interesting oddities are present.
Delphi and Pascal? "Both" more popular than D or even Go? Seriously?
== Quote from Kagamin (s...@here.lot)'s article
> spir Wrote:
> > There is a point I don't understand: if I'm right, LGPL as well as all other
> > "open source", not strictly free-software, licenses allow using licensed
> > software even for "privative" (proprietary) work. But they wouldn't allow
== Quote from %u (lenochw...@gmail.com)'s article
> Is it necessary free memory allocated for member of structure, like in C? I
> suppose not (we have gc). Example:
> struct BITMAP {
> (...)
> ubyte[] pixels;
> }
> BITMAP* bitmap = new BITMAP;
> bitmap.pixels = new ubyte[100*100];
> (...)
> // dele
== Quote from bearophile (bearophileh...@lycos.com)'s article
> Andrei:
> > It might not a good use of our time to further engage in a diatribe on this.
> Just a note: you have not wasted your time discussing this, because I am not
expert on such matters, so I learn something from informed discussi
== Quote from Daniel Gibson (metalcae...@gmail.com)'s article
> Am 27.04.2011 02:03, schrieb Steven Schveighoffer:
> IMHO clear isn't needed for anything but structs and Objects.
> For any simple type or pointer you can just write x = x.init; instead of
> clear(x) or, as you already mentioned, x=nu
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> On Wed, 27 Apr 2011 11:08:23 -0400, Alexander wrote:
> [...]
> The name choice is no longer up for debate. It's already set in print,
> and in the language.
> -Steve
clear() is a library function which is itself having its beha
On 28-04-2011 12:57, Moritz Warning wrote:
I think this might be interesting; it's also using D.
http://attractivechaos.wordpress.com/2011/04/25/my-programming-language-
benchmarks-plb/
Oh dear, the regex results for D are dreadful. And the matmul benchmark
result isn't too encouraging either
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> True, but dynamic arrays offer no inherent protection against overlap, though
> you can add a runtime check for that.
Another reason why we should have memory pool support in Phobos.
On 29-04-2011 10:30, lenochware wrote:
This post is in fact mainly about removing delete, but I didn't wont make
everyone angry just with title.:) I am sure not expert to language design, so
I should probably be quiet, but I have question.
My question is: Didn't break it (i.e. removing delete) co
On 29-04-2011 12:37, Daniel Gibson wrote:
Am 29.04.2011 12:11, schrieb lenochware:
This has been acknowledged. Yes, removing delete in D2 will break
compatibility with existing code. However, I'm sure that at an early
stage, the compiler will probably issue error messages once it
encounters dele
On 28-04-2011 17:09, Steven Schveighoffer wrote:
On Wed, 27 Apr 2011 17:30:54 -0400, Alexander wrote:
On 27.04.2011 19:13, Steven Schveighoffer wrote:
clear is not a keyword, it is possible to name a member clear, and
also have a clear global function.
Sure it is, though it is counter-intu
I think adopting ssize_t, thus improving parity with C would be more
reasonable than a size_s that can be easily mistaken for size_t when
reviewing long code.
Either way, sizediff_t isn't used that often anyway, so I don't know if
this minor issue should take too much priority.
On 10-05-2011
On Friday, 25 May 2012 at 18:22:08 UTC, Andrei Alexandrescu wrote:
On 5/25/12 12:37 PM, Mirko Pilger wrote:
Now I don't have a good name. Finalize isn't right, and
neither is
dispose...
what about "invalidate"?
Whatever it is, I should say I'll be very strongly opposed to
any proposal if i
On Sunday, 12 August 2012 at 16:58:08 UTC, asker wrote:
hi,
is there a working dfl for dmd 2060 win?
thanks
Hi there.
Not too long ago, I checked out DFL and got the library, plus
most samples, to build with DMD 2.059, so I do have a local
modified copy that works (for the most part).
I th
I agree, deprecating a fundamental operator like delete should not be
taken lightly. A lot of us prefer to manage the memory manually and do
RAII for our own reasons. By all means, add clear(obj) to the
language/standard library, but both methods should always be available.
There is no valid reason
Replacing delete or forbidding it in detriment of a safer alternative
function indeed makes sense when compiling in the SafeD language subset.
However, the delete operation has a well defined role in "unsafe" D.
The most advantageous would be adding clear() as well as a possible
"destroy()" functio
23 matches
Mail list logo
