On 2012-07-12 22:20, Steven Schveighoffer wrote:
Many (most?) classes never care about opHash, opCmp, opEquals and
toString. But Object defines them, incorrectly for most cases.
These apathetic classes would not break at all. And to make the default
be to inherit those methods would promote
On 2012-07-12 21:26, Jonathan M Davis wrote:
The recently added attribute inferrence for overridden functions in derived
types makes it impossible to have a non-const overload of a const function.
I wonder if the attribute inference can be fined tuned a bit. So it's
only applied to a method
On Friday, July 13, 2012 08:55:58 Jacob Carlborg wrote:
On 2012-07-12 21:26, Jonathan M Davis wrote:
The recently added attribute inferrence for overridden functions in
derived
types makes it impossible to have a non-const overload of a const
function.
I wonder if the attribute
On 2012-07-13 09:03, Jonathan M Davis wrote:
I believe that Kenji has a pull request intended to resolve the issue
(probably by doing something like that, but I don't know). We'll see what
Walter has to say though.
This one: https://github.com/D-Programming-Language/dmd/pull/1042 ?
It says We
On Friday, July 13, 2012 09:10:17 Jacob Carlborg wrote:
On 2012-07-13 09:03, Jonathan M Davis wrote:
I believe that Kenji has a pull request intended to resolve the issue
(probably by doing something like that, but I don't know). We'll see what
Walter has to say though.
This one:
I always wondered why toString() wasn't just to!string() in the
first place, short of UFCS not being implemented for all types.
On Friday, July 13, 2012 11:02:30 F i L wrote:
I always wondered why toString() wasn't just to!string() in the
first place, short of UFCS not being implemented for all types.
to!string(obj) uses typeof(obj).toString for user-defined types. Even if
to!string is arguably the better way to
On 13/07/12 11:02, F i L wrote:
I always wondered why toString() wasn't just to!string() in the first
place, short of UFCS not being implemented for all types.
toString() comes from the days before D had templates.
On Fri, 13 Jul 2012 00:18:22 -0400, Mehrdad wfunct...@hotmail.com wrote:
On Friday, 13 July 2012 at 03:57:21 UTC, Steven Schveighoffer wrote:
On Thu, 12 Jul 2012 23:51:22 -0400, Mehrdad wfunct...@hotmail.com
wrote:
On Friday, 13 July 2012 at 02:19:49 UTC, Jonathan M Davis wrote:
That
On Fri, 13 Jul 2012 02:49:01 -0400, Jacob Carlborg d...@me.com wrote:
On 2012-07-12 22:20, Steven Schveighoffer wrote:
Many (most?) classes never care about opHash, opCmp, opEquals and
toString. But Object defines them, incorrectly for most cases.
These apathetic classes would not break at
On Fri, 13 Jul 2012 05:02:30 -0400, F i L witte2...@gmail.com wrote:
I always wondered why toString() wasn't just to!string() in the first
place, short of UFCS not being implemented for all types.
toString in itself is wasteful. It allocates a string that will likely be
thrown away
On Thursday, 12 July 2012 at 04:15:48 UTC, Andrei Alexandrescu
wrote:
2. C++ has very, very successfully avoided the necessity of
planting polymorphic comparisons in base classes by use of
templates. The issue is template code bloat. My impression from
being in touch with the C++ community for
On 2012-07-13 14:06, Peter Alexander wrote:
Ironically, I remember you saying a while back that compile times where
a big problem at Facebook. Guess what's causing that?
If I recall correctly, that was due to using too many global variables
and compiler that kept all the global variables in
Timon Gehr , dans le message (digitalmars.D:172014), a écrit :
Thank you for taking the time.
Removing the default methods completely is actually a lot better than
making inheriting from Object optional or tweaking const beyond
recognition and/or usefulness.
I was afraid to suggest this
Mehrdad , dans le message (digitalmars.D:172012), a écrit :
On Thursday, 12 July 2012 at 04:15:48 UTC, Andrei Alexandrescu
wrote:
Required reading prior to this: http://goo.gl/eXpuX
Referenced post (for context):
The problem is not only in the constness of the argument, but
also in
its
On Thursday, July 12, 2012 00:15:48 Andrei Alexandrescu wrote:
What say you?
If you can figure out how to make this work, it's fine by me.
However, I see two potential issuses which cause currently working idioms to
no longer work:
1. Anything which wants to be able to operate on Objects
On 12/07/12 06:15, Andrei Alexandrescu wrote:
Required reading prior to this: http://goo.gl/eXpuX
You destroyed, we listened.
I think Christophe makes a great point. We've been all thinking inside
the box but we should question the very existence of the box. Once the
necessity of opCmp,
On Thursday, 12 July 2012 at 08:40:25 UTC, Jonathan M Davis wrote:
it does appear to solve the const issues that we've been having
quite nicely
How would we expect people to deal with these const issues when
the issues come up in their own libraries?
Or do we not care?
On Thursday, July 12, 2012 11:07:42 Mehrdad wrote:
On Thursday, 12 July 2012 at 08:40:25 UTC, Jonathan M Davis wrote:
it does appear to solve the const issues that we've been having
quite nicely
How would we expect people to deal with these const issues when
the issues come up in their
On 7/12/2012 12:59 AM, Jonathan M Davis wrote:
So, I think that it's probably a solid way to go, and it does appear to solve
the const issues that we've been having quite nicely, but it also appears to
break a number of things which have worked for some time, and we're going to
have to figure
On Thursday, July 12, 2012 02:43:09 Walter Bright wrote:
On 7/12/2012 12:59 AM, Jonathan M Davis wrote:
So, I think that it's probably a solid way to go, and it does appear to
solve the const issues that we've been having quite nicely, but it also
appears to break a number of things which
On Thursday, 12 July 2012 at 08:59:46 UTC, Don Clugston wrote:
On 12/07/12 06:15, Andrei Alexandrescu wrote:
Required reading prior to this: http://goo.gl/eXpuX
You destroyed, we listened.
I think Christophe makes a great point. We've been all
thinking inside
the box but we should question
On 12/07/12 12:00, Paulo Pinto wrote:
On Thursday, 12 July 2012 at 08:59:46 UTC, Don Clugston wrote:
On 12/07/12 06:15, Andrei Alexandrescu wrote:
Required reading prior to this: http://goo.gl/eXpuX
You destroyed, we listened.
I think Christophe makes a great point. We've been all thinking
Andrei Alexandrescu:
What say you?
It's an interesting proposal, and I like it in general.
In D the C++-improved template system and the Java-copied OOP are
partially a duplication, they sometimes offer two different ways
to do similar things. I think this proposal reduces this
Andrei Alexandrescu:
The issue is template code bloat. My impression from being in
touch with the C++ community for a long time is that virtually
nobody even talks about code bloat anymore. For whatever
combination of industry and market forces, it's just not an
issue anymore.
There is no
bearophile wrote in message
news:xrbtkoercscroxgto...@forum.dlang.org...
Andrei Alexandrescu:
What say you?
It's an interesting proposal, and I like it in general.
In D the C++-improved template system and the Java-copied OOP are partially
a duplication, they sometimes offer two different
Another weapon to attack the problem is introducing in the DMD
back-end an optimization (already present in LLVM, but I think
not used on default), merging of functions with the same body
(leaving just a jump as the body of the removed function, to
keep their function pointers distinct).
Why
Tobias Pankrath:
Why not drop that requirement? What is the use case of
different function pointers for different but equivalent
functions? Does anyone depend on this?
It's a requirement that comes from C specs, and I don't know why
C was designed that way, as usual I am not expert enough.
bearophile bearophileh...@lycos.com wrote in message
news:thmrfdsenkmtasilh...@forum.dlang.org...
Another weapon to attack the problem is introducing in the DMD back-end an
optimization (already present in LLVM, but I think not used on default),
merging of functions with the same body
On Thursday, 12 July 2012 at 04:15:48 UTC, Andrei Alexandrescu
wrote:
Required reading prior to this: http://goo.gl/eXpuX
You destroyed, we listened.
[...]
What say you?
Andrei
I agree, they are not needed.
This situation is similar to C#, but there the problem doesn't
seem to be so
Daniel Murphy:
This should be in the linker, not the backend.
What's important is that all D compilers implement this
optimization (or something better, if compatible, like merging
pieces of partially equal functions).
Bye,
bearophile
On Thursday, 12 July 2012 at 12:06:49 UTC, Roman D. Boiko wrote:
Jon Skeet wrote on this long ago:
http://msmvps.com/blogs/jon_skeet/archive/2008/12/05/redesigning-system-object-java-lang-object.aspx
The fact that every object has a monitor associated with it was a
mistake in Java, and was
On 2012-07-12 09:59, Jonathan M Davis wrote:
For the most part, I think that operating on Objects like that is horrible,
and we certainly don't encourage it, but it's been possible for ages, so I'm
willing to bet that there's plenty of code which does it. For instance, what's
Tango do? As I
On Thursday, 12 July 2012 at 12:36:18 UTC, RivenTheMage wrote:
On Thursday, 12 July 2012 at 12:06:49 UTC, Roman D. Boiko wrote:
Jon Skeet wrote on this long ago:
http://msmvps.com/blogs/jon_skeet/archive/2008/12/05/redesigning-system-object-java-lang-object.aspx
The fact that every object
On 2012-07-12 13:41, bearophile wrote:
There is no proof that template bloat won't be a problem in D (I
remember the first version of the D Objective-C bridge failing because
of code bloat, the second version seems to require changes in the D
language).
Yeah, that was insane. 60 MB for a
On 2012-07-12 13:57, bearophile wrote:
It's a requirement that comes from C specs, and I don't know why C was
designed that way, as usual I am not expert enough. I prefer to not
change the semantics of D over C unless there is an important reason,
especially when I don't know/understand the
Jacob Carlborg:
Yeah, that was insane. 60 MB for a hello world application is
not pretty.
I'd like to know how much MB are saved using the @templated()
pervasively in that first implementation... :-)
The second version is not a bridge, it changes the language to
be ABI
compatible with
On 7/12/12 3:59 AM, Jonathan M Davis wrote:
If you can figure out how to make this work, it's fine by me.
However, I see two potential issuses which cause currently working idioms to
no longer work:
1. Anything which wants to be able to operate on Objects generically (e.g.
have a container
On 2012-07-12 11:41:46 +, bearophile bearophileh...@lycos.com said:
Andrei Alexandrescu:
The issue is template code bloat. My impression from being in touch
with the C++ community for a long time is that virtually nobody even
talks about code bloat anymore. For whatever combination of
On Thursday, 12 July 2012 at 13:20:47 UTC, Andrei Alexandrescu
wrote:
On 7/12/12 3:59 AM, Jonathan M Davis wrote:
If you can figure out how to make this work, it's fine by me.
However, I see two potential issuses which cause currently
working idioms to
no longer work:
1. Anything which
On 2012-07-12 13:01:42 +, bearophile bearophileh...@lycos.com said:
Jacob Carlborg:
Yeah, that was insane. 60 MB for a hello world application is not pretty.
I'd like to know how much MB are saved using the @templated()
pervasively in that first implementation... :-)
There's no use
On Thu, 12 Jul 2012 00:15:48 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
You destroyed, we listened.
I think Christophe makes a great point. We've been all thinking inside
the box but we should question the very existence of the box. Once the
necessity of opCmp,
On Thursday, 12 July 2012 at 12:43:01 UTC, Roman D. Boiko wrote:
On Thursday, 12 July 2012 at 12:36:18 UTC, RivenTheMage wrote:
On Thursday, 12 July 2012 at 12:06:49 UTC, Roman D. Boiko
wrote:
Jon Skeet wrote on this long ago:
On Thu, 12 Jul 2012 09:20:47 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 7/12/12 3:59 AM, Jonathan M Davis wrote:
If you can figure out how to make this work, it's fine by me.
However, I see two potential issuses which cause currently working
idioms to
no longer
On Thursday, 12 July 2012 at 12:43:01 UTC, Roman D. Boiko wrote:
On Thursday, 12 July 2012 at 12:36:18 UTC, RivenTheMage wrote:
The fact that every object has a monitor associated with it
was a
mistake in Java, and was unfortunately copied in .NET. This
promotes the bad practice of locking
On Thursday, 12 July 2012 at 13:39:54 UTC, Steven Schveighoffer
wrote:
On Thu, 12 Jul 2012 09:20:47 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
If we define alternative free generic functions in object.d
for the four culprit methods (and have the compiler, druntime,
and
On Thursday, 12 July 2012 at 13:41:52 UTC, Roman D. Boiko wrote:
...
ups. I meant +1.
On Thursday, 12 July 2012 at 13:35:54 UTC, Roman D. Boiko wrote:
OK, I found one myself from this post:
http://michelf.com/weblog/2012/mutex-synchonization-in-d/
Beat me :)
On 7/12/12 9:39 AM, Steven Schveighoffer wrote:
On Thu, 12 Jul 2012 09:20:47 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 7/12/12 3:59 AM, Jonathan M Davis wrote:
If you can figure out how to make this work, it's fine by me.
However, I see two potential issuses which
Andrei Alexandrescu:
Too complicated. I think we can afford one comparison.
An annotation for old style classes?
Bye,
bearophile
On Thursday, 12 July 2012 at 13:49:29 UTC, Andrei Alexandrescu
wrote:
Too complicated. I think we can afford one comparison.
One comparison for each of these basic usages. Would branch
prediction work fine in each use case?
Anyway I vote for removing those methods from the root class.
Is this really need?
The four const operators in Object should not block the user-defined
mutable operators.
// My purpose for 2.060 release
class C {
override opEquals(const Object o) const { ... } // or just alias
super.opEquals opEquals;
bool opEquals(Object o) { ... } // add overload for
On Thursday, 12 July 2012 at 11:03:37 UTC, Don Clugston wrote:
On 12/07/12 12:00, Paulo Pinto wrote:
On Thursday, 12 July 2012 at 08:59:46 UTC, Don Clugston wrote:
On 12/07/12 06:15, Andrei Alexandrescu wrote:
Required reading prior to this: http://goo.gl/eXpuX
You destroyed, we listened.
I
On 12/07/2012 06:15, Andrei Alexandrescu wrote:
Required reading prior to this: http://goo.gl/eXpuX
You destroyed, we listened.
I think Christophe makes a great point. We've been all thinking inside
the box but we should question the very existence of the box. Once the
necessity of opCmp,
On 12/07/2012 15:49, Andrei Alexandrescu wrote:
On 7/12/12 9:39 AM, Steven Schveighoffer wrote:
On Thu, 12 Jul 2012 09:20:47 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 7/12/12 3:59 AM, Jonathan M Davis wrote:
If you can figure out how to make this work, it's fine by
On 12/07/2012 13:21, bearophile wrote:
Andrei Alexandrescu:
What say you?
It's an interesting proposal, and I like it in general.
In D the C++-improved template system and the Java-copied OOP are
partially a duplication, they sometimes offer two different ways to do
similar things. I think
kenji hara:
Is this really need?
...But, I would never opposed to advancing toward the better
language design.
I am not expert on English language, but you are one of my
programming heroes, so please let me try to improve a little
those parts of your post :-)
| Is this really
On 7/12/12 10:40 AM, deadalnix wrote:
And one branching. In itself it isn't high cost, but can become a
problem in a tight loop, say a sort function for instance.
Cost should be assessed in comparison to the baseline work that is being
performed. At any rate, the branch predictor should take
On 12/07/2012 13:41, bearophile wrote:
Another weapon to attack the problem is introducing in the DMD back-end
an optimization (already present in LLVM, but I think not used on
default), merging of functions with the same body (leaving just a jump
as the body of the removed function, to keep
On Thu, Jul 12, 2012 at 09:31:27AM -0400, Steven Schveighoffer wrote:
On Thu, 12 Jul 2012 00:15:48 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
[...]
3. opCmp, opEquals, and toHash are all needed primarily for one
thing: built-in hashes. (There's also use of them in the
On 12/07/2012 16:28, kenji hara wrote:
Is this really need?
The four const operators in Object should not block the user-defined
mutable operators.
// My purpose for 2.060 release
class C {
override opEquals(const Object o) const { ... } // or just alias
super.opEquals opEquals;
bool
On 7/12/12 10:28 AM, kenji hara wrote:
Is this really need?
The four const operators in Object should not block the user-defined
mutable operators.
// My purpose for 2.060 release
class C {
override opEquals(const Object o) const { ... } // or just alias
super.opEquals opEquals;
bool
On 12/07/2012 13:50, Tobias Pankrath wrote:
Another weapon to attack the problem is introducing in the DMD
back-end an optimization (already present in LLVM, but I think not
used on default), merging of functions with the same body (leaving
just a jump as the body of the removed function, to
deadalnix:
That is IMO the way to go instead of cluttering the language.
I think several solutions applied at the same time are needed if
you desire to reduce bloat effectively.
Bye,
bearophile
On 12/07/2012 16:55, bearophile wrote:
deadalnix:
That is IMO the way to go instead of cluttering the language.
I think several solutions applied at the same time are needed if you
desire to reduce bloat effectively.
Bye,
bearophile
The @templated is redundant with that backend capability
On 12/07/2012 15:20, Michel Fortin wrote:
On 2012-07-12 11:41:46 +, bearophile bearophileh...@lycos.com said:
Andrei Alexandrescu:
The issue is template code bloat. My impression from being in touch
with the C++ community for a long time is that virtually nobody even
talks about code
deadalnix:
The @templated is redundant with that backend capability of LDC.
The semantics is not the same. This code doesn't compile, the
compiler enforces you are not using T in code that is annotated
to be a template of just V:
struct Foo(T, V) {
@templated(V) T bar() { return
On Thursday, 12 July 2012 at 09:32:00 UTC, Jonathan M Davis wrote:
The issue that we're trying to solve here is making
opEquals,opCmp, toHash, and toString work both for const and
non-const objects. That's it. We're not talking about revamping
const. It doesn't need it.
Depends on what you
On Thu, 12 Jul 2012 09:30:35 -0400, Michel Fortin
michel.for...@michelf.com wrote:
D/Objective-C (the compiler addition) is much more than that. It's
support and cohabitation of a second object ABI, it's support for
Objective-C exceptions mixed with D exceptions, support for Objective-C
On 7/12/12 11:50 AM, Roman D. Boiko wrote:
On Thursday, 12 July 2012 at 14:58:29 UTC, deadalnix wrote:
I think this is not a problem as big as it is stated.
Most of that code will be executed close to never, and 60Mb isn't a
big deal for any modern computer, not even for most cell phones now.
On Thu, 12 Jul 2012 10:56:13 -0400, H. S. Teoh hst...@quickfur.ath.cx
wrote:
On Thu, Jul 12, 2012 at 09:31:27AM -0400, Steven Schveighoffer wrote:
On Thu, 12 Jul 2012 00:15:48 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
[...]
3. opCmp, opEquals, and toHash are all
On Thursday, 12 July 2012 at 14:58:29 UTC, deadalnix wrote:
I think this is not a problem as big as it is stated.
Most of that code will be executed close to never, and 60Mb
isn't a big deal for any modern computer, not even for most
cell phones now.
L1 cache size is.
On Thu, 12 Jul 2012 11:47:10 -0400, Mehrdad wfunct...@hotmail.com wrote:
But if you're saying this problem is somehow 'special' in some way, then
would you please mention how?
Because you have no choice what your base class is -- Object. And if
Object uses const, so must you.
-Steve
On Thu, 12 Jul 2012 10:58:28 -0400, deadalnix deadal...@gmail.com wrote:
Both desirable things, but I don't think those would have much impact on
the D/Objective-C bridge.
I think this is not a problem as big as it is stated.
Most of that code will be executed close to never, and 60Mb
On Thu, 12 Jul 2012 09:49:29 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 7/12/12 9:39 AM, Steven Schveighoffer wrote:
On Thu, 12 Jul 2012 09:20:47 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 7/12/12 3:59 AM, Jonathan M Davis wrote:
If you can
On Thu, Jul 12, 2012 at 11:51:15AM -0400, Steven Schveighoffer wrote:
On Thu, 12 Jul 2012 10:56:13 -0400, H. S. Teoh
hst...@quickfur.ath.cx wrote:
On Thu, Jul 12, 2012 at 09:31:27AM -0400, Steven Schveighoffer wrote:
[...]
Yes. Where's that new AA struct, Mr. Teoh? :)
[...]
The code is
On 12/07/2012 17:51, Andrei Alexandrescu wrote:
On 7/12/12 11:50 AM, Roman D. Boiko wrote:
On Thursday, 12 July 2012 at 14:58:29 UTC, deadalnix wrote:
I think this is not a problem as big as it is stated.
Most of that code will be executed close to never, and 60Mb isn't a
big deal for any
On 12/07/2012 18:09, Steven Schveighoffer wrote:
On Thu, 12 Jul 2012 10:58:28 -0400, deadalnix deadal...@gmail.com wrote:
Both desirable things, but I don't think those would have much impact on
the D/Objective-C bridge.
I think this is not a problem as big as it is stated.
Most of that
On 12-07-2012 18:33, deadalnix wrote:
On 12/07/2012 18:09, Steven Schveighoffer wrote:
On Thu, 12 Jul 2012 10:58:28 -0400, deadalnix deadal...@gmail.com
wrote:
Both desirable things, but I don't think those would have much
impact on
the D/Objective-C bridge.
I think this is not a
On Thu, 12 Jul 2012 12:46:29 -0400, Alex Rønne Petersen a...@lycus.org
wrote:
On 12-07-2012 18:33, deadalnix wrote:
On 12/07/2012 18:09, Steven Schveighoffer wrote:
On Thu, 12 Jul 2012 10:58:28 -0400, deadalnix deadal...@gmail.com
wrote:
Both desirable things, but I don't think those
On Thursday, 12 July 2012 at 16:22:07 UTC, H. S. Teoh wrote:
I don't always have the time to work on it, and it's not fair to
the community that the fate of such a vital component depends
on the
free time schedule of one person.
*cough* … DMD … *cough*.
On Thursday, 12 July 2012 at 16:22:07 UTC, H. S. Teoh wrote:
I don't always have the time to work on it
... but when I do... :)
On 12 July 2012 18:03, David Nadlinger s...@klickverbot.at wrote:
On Thursday, 12 July 2012 at 16:22:07 UTC, H. S. Teoh wrote:
I don't always have the time to work on it, and it's not fair to
the community that the fate of such a vital component depends on the
free time schedule of one
On 7/12/12 12:05 PM, Steven Schveighoffer wrote:
Aside from this, the baggage of four dead functions in every vtable is
pretty hefty, is there a path to deprecation, or are the four horseman
of the const apocalypse going to exist forever? It would suck to have to
deal with these issues forever.
On Thursday, 12 July 2012 at 04:15:48 UTC, Andrei Alexandrescu
wrote:
Required reading prior to this: http://goo.gl/eXpuX
You destroyed, we listened.
I think Christophe makes a great point. We've been all thinking
inside the box but we should question the very existence of the
box. Once the
On 7/12/12 1:40 PM, David Piepgrass wrote:
1. Most importantly, the C++ template approach is a big pain for
large-scale systems, because in such systems you want to create DLLs/SOs
and C++ has neither a standard ABI nor a safe way to pass around
template instantiations between DLLs (in the
On 2012-07-12 15:48:13 +, Steven Schveighoffer
schvei...@yahoo.com said:
On Thu, 12 Jul 2012 09:30:35 -0400, Michel Fortin
michel.for...@michelf.com wrote:
D/Objective-C (the compiler addition) is much more than that. It's
support and cohabitation of a second object ABI, it's support
On 12/07/2012 19:51, Andrei Alexandrescu wrote:
2. Provide a class modifier that makes immutable(_) illegal, so the
class uses logical const instead of physical const.
I think this would be considerably trickier.
This is orthogonal to what we are dealing here.
On 2012-07-12 14:58:28 +, deadalnix deadal...@gmail.com said:
I think this is not a problem as big as it is stated.
Most of that code will be executed close to never, and 60Mb isn't a big
deal for any modern computer, not even for most cell phones now.
60Mb was only with bindings to the
On 7/12/2012 2:51 AM, Jonathan M Davis wrote:
On Thursday, July 12, 2012 02:43:09 Walter Bright wrote:
A main motivation for going this route is to avoid breaking existing code.
Except that it's _guaranteed_ to break code, because anything which relies on
Object having opEquals, opCmp,
On Thursday, 12 July 2012 at 17:51:32 UTC, Andrei Alexandrescu
wrote:
On 7/12/12 1:40 PM, David Piepgrass wrote:
1. Most importantly, the C++ template approach is a big pain
for
large-scale systems, because in such systems you want to
create DLLs/SOs
and C++ has neither a standard ABI nor a
On 2012-07-12 15:39, Steven Schveighoffer wrote:
I think if we want a solution that allows old code to work, why not what
Timon suggested? Have a base class for Object (RawObject was suggested)
that does not implement the opFunctions. It would still break code, but
would be easy to fix (just
On Thu, Jul 12, 2012 at 01:51:31PM -0400, Andrei Alexandrescu wrote:
On 7/12/12 1:40 PM, David Piepgrass wrote:
1. Most importantly, the C++ template approach is a big pain for
large-scale systems, [...]
The thing is, that can be done in an opt-in manner. People who want
methods in the root
we can't just cast to IObject.
Oops, I meant IComparable
On 2012-07-12 19:52, Michel Fortin wrote:
I just don't have time to work on this right now -- I'm too busy working
on other thing -- even though I'd like very much to work on that.
It would be so, so nice to have this finished and merged upstream.
--
/Jacob Carlborg
On Thursday, 12 July 2012 at 17:51:32 UTC, Andrei Alexandrescu
wrote:
On 7/12/12 1:40 PM, David Piepgrass wrote:
1. Most importantly, the C++ template approach is a big pain
for
large-scale systems, because in such systems you want to
create DLLs/SOs
and C++ has neither a standard ABI nor a
On Thursday, July 12, 2012 09:23:28 H. S. Teoh wrote:
it's not fair to
the community that the fate of such a vital component depends on the
free time schedule of one person.
True, but it does happen all too often around here (e.g. Andrei with
allocators and containers). The real problem is
On 7/12/12 2:50 PM, H. S. Teoh wrote:
On Thu, Jul 12, 2012 at 01:51:31PM -0400, Andrei Alexandrescu wrote:
On 7/12/12 1:40 PM, David Piepgrass wrote:
1. Most importantly, the C++ template approach is a big pain for
large-scale systems, [...]
The thing is, that can be done in an opt-in
On 2012-07-12 16:28, kenji hara wrote:
Is this really need?
The four const operators in Object should not block the user-defined
mutable operators.
// My purpose for 2.060 release
class C {
override opEquals(const Object o) const { ... } // or just alias
super.opEquals opEquals;
bool
On 2012-07-12 20:50, H. S. Teoh wrote:
Having a class RawObject as a superclass of Object is an equally good
solution. Declare a class without a base class, and the base class
defaults to Object. Explicitly write class MyClass : RawObject and
you get a class without the stuff in Object. If you
1 - 100 of 130 matches
Mail list logo
