john foo wrote:
Walter Bright Wrote:
Leandro Lucarella wrote:
Exactly, it seems to me that the generalization in this case is
counterproductive.
It's similar to the motivation for the "= delete" capability proposed
for C++0x. Lawrence Crowl makes a good case for it:
http://www.open-std.org/
john foo wrote:
So you're copying yet another C++0x feature and renaming it to
attract more positive publicity..
D is full of good ideas from other languages. Hopefully, we left the bad
ideas behind.
On 01/15/2010 07:35 AM, john foo wrote:
Walter Bright Wrote:
Leandro Lucarella wrote:
Exactly, it seems to me that the generalization in this case is
counterproductive.
It's similar to the motivation for the "= delete" capability proposed
for C++0x. Lawrence Crowl makes a good case for it:
Walter Bright Wrote:
> Leandro Lucarella wrote:
> > Exactly, it seems to me that the generalization in this case is
> > counterproductive.
>
> It's similar to the motivation for the "= delete" capability proposed
> for C++0x. Lawrence Crowl makes a good case for it:
>
> http://www.open-std.org/
Leandro Lucarella wrote:
> Exactly, it seems to me that the generalization in this case is
> counterproductive. What's the point on disabling a function, except for
> those automatically generated by the compiler.
Unwanted inherited functions. Unwanted functions generated by a
template mixin. (B
Leandro Lucarella wrote:
Exactly, it seems to me that the generalization in this case is
counterproductive.
It's similar to the motivation for the "= delete" capability proposed
for C++0x. Lawrence Crowl makes a good case for it:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2326.
Leandro Lucarella wrote:
Pelle Månsson, el 14 de enero a las 19:30 me escribiste:
On 01/14/2010 03:55 PM, Leandro Lucarella wrote:
What is @disable supposed to be for?
http://www.dsource.org/projects/dmd/changeset/336
Thanks.
#define STCdisable 0x20LL // for functions that are
bearophile, el 14 de enero a las 19:05 me escribiste:
> Andrei Alexandrescu:
> > Because @disable applies to any function.
>
> What's the purpose of disabling any random function? (Is such extra
> generality worth its cognitive cost?)
Exactly, it seems to me that the generalization in this case
Pelle Månsson, el 14 de enero a las 19:30 me escribiste:
> On 01/14/2010 03:55 PM, Leandro Lucarella wrote:
> >What is @disable supposed to be for?
> >http://www.dsource.org/projects/dmd/changeset/336
> >
> >Thanks.
> >
> #define STCdisable 0x20LL // for functions that are
> not calla
bearophile wrote:
Andrei Alexandrescu:
Because @disable applies to any function.
What's the purpose of disabling any random function? (Is such extra generality
worth its cognitive cost?)
There's no added cognitive cost from @nocopy to @disable (au contraire
I'd say).
Andrei
Andrei Alexandrescu:
> Because @disable applies to any function.
What's the purpose of disabling any random function? (Is such extra generality
worth its cognitive cost?)
Bye,
bearophile
Denis Koroskin wrote:
On Thu, 14 Jan 2010 21:28:42 +0300, Andrei Alexandrescu
wrote:
Pelle Månsson wrote:
On 01/14/2010 03:55 PM, Leandro Lucarella wrote:
What is @disable supposed to be for?
http://www.dsource.org/projects/dmd/changeset/336
Thanks.
#define STCdisable 0x20LL
On Thu, 14 Jan 2010 21:28:42 +0300, Andrei Alexandrescu
wrote:
Pelle Månsson wrote:
On 01/14/2010 03:55 PM, Leandro Lucarella wrote:
What is @disable supposed to be for?
http://www.dsource.org/projects/dmd/changeset/336
Thanks.
#define STCdisable 0x20LL // for functions that
bearophile wrote:
Andrei Alexandrescu:
Noncopyable types are pivotal for a number of idioms important in
concurrency and elsewhere.
Why isn't it named @nocopy or something similar?
Because @disable applies to any function.
Andrei
Andrei Alexandrescu:
> Noncopyable types are pivotal for a number of idioms important in
> concurrency and elsewhere.
Why isn't it named @nocopy or something similar?
Bye,
bearophile
Andrei Alexandrescu wrote:
On 01/14/2010 03:55 PM, Leandro Lucarella wrote:
What is @disable supposed to be for?
The main idea is to allow creation of noncopyable types by marking
this(this) as @disable.
Noncopyable types are pivotal for a number of idioms important in
concurrency and elsewh
Pelle MÃ¥nsson Wrote:
> On 01/13/2010 06:18 PM, bearophile wrote:
> > bearophile:
> >> And currently the D GC seems to always return aligned to 16 bytes (even
> >> chunks of memory smaller than 16 bytes).<
> >
> > I hope to be wrong :-)
> I think the GC has a 16 byte minimum allocation block, I b
Steven Schveighoffer wrote:
On Wed, 13 Jan 2010 06:28:33 -0500, Jacob Carlborg wrote:
On 1/12/10 23:40, Walter Bright wrote:
It's true that nobody has spent the effort to do this. Anyone is welcome
to step up and work on it.
Hasn't that already been solved with ddl:
http://www.dsource.org/
Pelle Månsson wrote:
On 01/14/2010 03:55 PM, Leandro Lucarella wrote:
What is @disable supposed to be for?
http://www.dsource.org/projects/dmd/changeset/336
Thanks.
#define STCdisable 0x20LL // for functions that are not
callable
The main idea is to allow creation of noncopyab
On 01/14/2010 03:55 PM, Leandro Lucarella wrote:
What is @disable supposed to be for?
http://www.dsource.org/projects/dmd/changeset/336
Thanks.
#define STCdisable 0x20LL // for functions that are not
callable
On 01/14/2010 03:19 PM, retard wrote:
To conclude this discussion, it seems that executable size could be
reduced dramatically. Unfortunately the compiler fails to use the
opportunity in almost all cases.
A typical program would be 50% to 99.999% smaller if the libraries
(including stdlib) were
What is @disable supposed to be for?
http://www.dsource.org/projects/dmd/changeset/336
Thanks.
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E B
To conclude this discussion, it seems that executable size could be
reduced dramatically. Unfortunately the compiler fails to use the
opportunity in almost all cases.
A typical program would be 50% to 99.999% smaller if the libraries
(including stdlib) were dynamically linked in, compiler omitt
On Thu, 14 Jan 2010 00:19:56 -0500, Nick Sabalausky wrote:
"Roman Ivanov" wrote in message
Storing configs in zip files would increase boot and load times, because
applications would waste cycles on unzipping them. That is bloat of a
worse kind.
I'm not sure that would be the case if the da
Steven Schveighoffer:
> I'm not sure if SSE register requires alignment. Typically
> on systems that do not support loading from a byte-aligned memory segment
> will throw a bus error if you try to do it.
I think SSE registers require 8 byte alignment, but some of their operations
are faster
On Wed, 13 Jan 2010 08:52:42 -0500, dsimcha wrote:
Should there be a way, in D, to create a variable that's local to both a
thread and a class instance? For example:
class Foo {
__thread uint num;
}
num would basically be a reference to thread-local storage, with a new
one
created for
On Wed, 13 Jan 2010 12:16:30 -0500, bearophile
wrote:
Justin Johansson:
So why on earth, since Visual Studio 2001 (and before?), was the default
alignment set to 8 bytes for the M$ C/C++ compiler code generation
option?
Maybe because for compatibility reasons they can't require a 16 bytes
On Wed, 13 Jan 2010 06:28:33 -0500, Jacob Carlborg wrote:
On 1/12/10 23:40, Walter Bright wrote:
It's true that nobody has spent the effort to do this. Anyone is welcome
to step up and work on it.
Hasn't that already been solved with ddl:
http://www.dsource.org/projects/ddl/
It's not sol
28 matches
Mail list logo
