July 12, 2012 Re: All right, all right! Interim decision regarding qualified Object methods | ||||
---|---|---|---|---|
| ||||
Posted in reply to kenji hara | 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 necessary? | ...but, I would never be opposed to an advancement toward that better | language design. Or simply: | ...but, I am not opposed to advance to that better language design. Bye, bearophile |
July 12, 2012 Re: All right, all right! Interim decision regarding qualified Object methods | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | 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 their function pointers
> distinct).
>
That is IMO the way to go instead of cluttering the language.
|
July 12, 2012 Re: All right, all right! Interim decision regarding qualified Object methods | ||||
---|---|---|---|---|
| ||||
Posted in reply to kenji hara | 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 opEquals(Object o) { ... } // add overload for mutable object comparison
> }
>
> auto c1 = new C(), c2 = new C2();
> c1 == c2; // the both hand side is mutable, so mutable opEquals will run
>
> In git head, it is not disallowed, but it is a *compiler bug*.
> To fix the problem, I have a pull request for dmd.
> https://github.com/D-Programming-Language/dmd/pull/1042
> (The pull will kill attribute inference for const, but I think it is
> unnecessary for D.)
>
> ...But, I would never opposed to advancing toward the better language design.
>
mutable and const overload of the same function is a bit weird. I'm not sure this is a bug a feature we should keep.
|
July 12, 2012 Re: All right, all right! Interim decision regarding qualified Object methods | ||||
---|---|---|---|---|
| ||||
Posted in reply to kenji hara | 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 opEquals(Object o) { ... } // add overload for mutable object comparison > } > > auto c1 = new C(), c2 = new C2(); > c1 == c2; // the both hand side is mutable, so mutable opEquals will run > > In git head, it is not disallowed, but it is a *compiler bug*. > To fix the problem, I have a pull request for dmd. > https://github.com/D-Programming-Language/dmd/pull/1042 > (The pull will kill attribute inference for const, but I think it is > unnecessary for D.) I didn't know of that, thanks. > ....But, I would never opposed to advancing toward the better language design. Thanks for being so helpful and flexible! Let's discuss matters a little more in this forum before making a decision. Andrei |
July 12, 2012 Re: All right, all right! Interim decision regarding qualified Object methods | ||||
---|---|---|---|---|
| ||||
Posted in reply to Tobias Pankrath | 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 keep their
>> function pointers distinct).
>
> Why not drop that requirement? What is the use case of different
> function pointers for different but equivalent functions? Does anyone
> depend on this?
Nothing prevent the linker to link directly to the new function if the body is only a branch instruction. This have a cost only when doing indirect call, and the indirect call is greater than a branch instruction.
|
July 12, 2012 Re: All right, all right! Interim decision regarding qualified Object methods | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Thu, Jul 12, 2012 at 09:31:27AM -0400, Steven Schveighoffer wrote: > On Thu, 12 Jul 2012 00:15:48 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@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 moribund .sort method.) The thing is, the design of built-in hashes predates the existence of templates. There are reasons to move to generic-based hashes instead of today's runtime hashes (such as the phenomenal success of templated containers in C++), so it can be argued that opCmp, opEquals, and toHash exist for reasons that are going extinct. > > Yes. Where's that new AA struct, Mr. Teoh? :) [...] The code is still here: https://github.com/quickfur/New-AA-implementation But I got roadblocked, partially because of constness issues (ironically, the problem was that toHash, toString, etc., weren't const, and now we're talking about supporting non-const versions of them), but more because of problems with IFTI. Or at least, that's where I left it about a month ago -- then I was away on vacation and haven't had the chance to go back to the code since. :( T -- There's light at the end of the tunnel. It's the oncoming train. |
July 12, 2012 Re: All right, all right! Interim decision regarding qualified Object methods | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | 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
|
July 12, 2012 Re: All right, all right! Interim decision regarding qualified Object methods | ||||
---|---|---|---|---|
| ||||
Posted in reply to Michel Fortin | On 12/07/2012 15:20, Michel Fortin wrote:
> On 2012-07-12 11:41:46 +0000, "bearophile" <bearophileHUGS@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 industry
>>> and market forces, it's just not an issue anymore.
>>
>> 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).
>
> I don't think templates were the culprit for the D/Objective-C bridge.
> Code bloat was, but that's something that was inherent to the design of
> the bridge. The bridge was using mixins extensively, and while I did
> everything I could to use regular non-mixin templates (because those can
> be reused when the template arguments are the same), it wasn't enough.
> In fact, given that all the wrapper functions written using mixins were
> virtual (so you could override them, which is quite a feature!) it meant
> they all needed to be instantiated even though they were not used anywhere.
>
> There's actually no way I could have reduced code bloat significantly
> even by writing all the code by hand in the most optimized way. Not
> unless I abandoned the capability to override functions, but that'd make
> the bridge almost useless.
>
> One thing that might have helped is if the linker could have striped all
> the classes that were not used in the final executable, something it
> couldn't do because all module info refers to them. But that wouldn't
> have helped with the compilation speed, which was becoming the second
> problem not far behind code bloat.
>
>
>> And it seems L1 code caches of CPUs aren't growing a lot (so I suggest
>> to not ignore having lot of code to swap in and out of those 32 kbytes).
>>
>> So maybe it will be useful to introduce in D some means to attack the
>> code bloat problem from several sides at the same time.
>>
>> Some time ago I have suggested one of such weapons, the @templated()
>> that allows to select what parts of a struct/class are templated
>> regarding to what template arguments (it's a refinement of an idea of
>> Stroustrup).
>>
>> 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).
>
> 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 isn't a big deal for any modern computer, not even for most cell phones now.
|
July 12, 2012 Re: All right, all right! Interim decision regarding qualified Object methods | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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 of LDC.
|
July 12, 2012 Re: All right, all right! Interim decision regarding qualified Object methods | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | 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 T.init; }
}
Bye,
bearophile
|
Copyright © 1999-2021 by the D Language Foundation