 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13/08/2012 03:50 PM, Darren New wrote:
> On 8/13/2012 4:56, Invisible wrote:
>> OTOH, C# does that thing that C++ does where it's impossible to
>> override a
>> method, unless you manually declare it as "virtual".
>
> You can override it. You just don't get virtual dispatch.
I know that's what C++ does. But I got the impression that in C# this is
a compile-time error. (Not that I can find any definitive word on this,
mind you...)
>> It's true that having non-virtual methods introduces a tiny performance
>> benefit.
>
> That has nothing to do with why it was done that way, since the JIT
> removes the virtual dispatch from virtual functions you don't override.
Does that actually work? Given that you can load arbitrary new
subclasses at any moment?
>> And then we get into access specifications. Java has public, private,
>> protected and package-local (which is implicit, and cannot be written
>> explicitly). C++ has... well, I'm not even sure /what/ the hell C++
>> has! And C# has the whole cake shop.
>
> Really, I think that's pretty much it. The same as Java, except instead
> of "package" you have "assembly". Oh, and you can put two of the
> somewhat-private declarations together. (protected assembly or something?)
You have "internal", which means "everything else in this assembly". You
also have "protected internal", which means protected OR internal.
(Because protected AND internal would just be nonsensical...) I'm still
trying to wrap my brain around that last... but presumably you almost
never need it anyway. After all, most things are just public or private.
No, wait! >_< Damnit, I meant protected...
>> You can't make something public if it refers to private types. And so on.
>
> Yes. Well, what would you expect? A public method that returns a value
> of a type you can't see the declaration of?
Haskell lets you do exactly that, yes.
> When you see the formal definitions of what you can and can't do, think
> about what it *means* and it will be clearer.
The rules are set up to make the obvious things work. My complaint is
that due to the complexity of the system, "the obvious thing" is
actually very difficult to codify precisely. Which is usually the sign
of a bad design.
> Admittedly the resolution rules are pretty complicated. In practice, it
> almost never comes into play, just like in practice people don't declare
> the same name to mean different things in similar classes.
> C# has the hindsight of a bunch of OOP development. It's really not that
> complex, unless you try to learn the rules without understanding them.
I guess I'm just spoiled. In Haskell, there are precisely 2 sorts of
type; everything is either an algebraic data type or a function type. C#
has 5 of fundamentally different sorts of type, all with different
semantics.
I especially love how enumerations are a different type but no, not
really, because obviously they're actually just integers... Or how
"bool" isn't an enumeration, it's hard-coded. Or how you can make
primitive types nullable, but you can't make reference types
non-nullable. Or...
> It's an excellent language in its class.
I SEE WHAT YOU DID THERE.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] dev null> wrote:
> > I have never quite understood the reason why C++ and Eiffel seem to be
> > the only programming languages in existence that support multiple
> > inheritance, while the rest of OO languages only support a highly
> > crippled version of it.
> I have to admit, Eiffel /does/ make the solution look very, very
> complicated. (I can't actually remember off-hand how the heck C++ does
> it...)
Does what?
> I would have thought the indirect code jump is probably far more
> expensive than the space overhead.
The additional space consumption is significant if you have eg. a class
that would otherwise be the size of a pointer (and you need to instantiate
millions of them). If you had forced virtual functions, it would double in
size.
> Yeah, I don't know. I'm slowly coming around to the idea that maybe we
> should forget about all this "inheritance" stuff and focus on interfaces
> as the primary thing of interest...
How would you implement a GUI library without using any kind of inheritance?
> > But you should be liking C#. It doesn't leak memory and if it crashes, it
> > tells you where and why. Probably.
> The same can be said of Java. Last time I checked, there's no shortage
> of people who want to do violent things to Java. (I believe your name is
> on that list, for example...)
But C# shouldn't have the same problems as Java. Mostly.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 13/08/2012 18:22, Orchid Win7 v1 nous fit lire :
>>
>> Is there actually a version of Windows out there that does not come with
>> the .NET libraries out-of-the-box? (I mean newer than 10 years.)
>
> How about "the version that ALL of our production systems and every
> customer-facing system in every commercial setting I've ever seen uses"?
> You know, *that* version. :-P
Yep. You have the sames as me. 2000 & XP. Now only XP. Everywhere. Some
SP3, not all...
(and sometime a few 2008-R2 in 64bits servers...)
At least itanium is dead (or might... Oracle has been ordered to
continue software support, for HP...), so Windows on itanium is dead.
Vista, 7, 8... who cares, XP runs!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 13/08/2012 19:26, Warp nous fit lire :
> Orchid Win7 v1 <voi### [at] devnull> wrote:
>>> I have never quite understood the reason why C++ and Eiffel seem to be
>>> the only programming languages in existence that support multiple
>>> inheritance, while the rest of OO languages only support a highly
>>> crippled version of it.
>
>> I have to admit, Eiffel /does/ make the solution look very, very
>> complicated. (I can't actually remember off-hand how the heck C++ does
>> it...)
>
> Does what?
Manage inheritances, including multiple inheritances.
>
>> I would have thought the indirect code jump is probably far more
>> expensive than the space overhead.
>
> The additional space consumption is significant if you have eg. a class
> that would otherwise be the size of a pointer (and you need to instantiate
> millions of them). If you had forced virtual functions, it would double in
> size.
IIRC, C++ does not duplicates the class function members (not even
pointers to them) in each instance. Only the actual class (as 1 pointer)
is stored within each instance. The virtual function is just an index.
The first virtual/inheritance cost a pointer in the class. The next are
free.(in fact, with RTTI, even without inheritance, you might already
have that pointer: so no additional cost)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.08.2012 18:31, schrieb Orchid Win7 v1:
> On 13/08/2012 03:50 PM, Darren New wrote:
>> On 8/13/2012 4:56, Invisible wrote:
>>> OTOH, C# does that thing that C++ does where it's impossible to
>>> override a
>>> method, unless you manually declare it as "virtual".
>>
>> You can override it. You just don't get virtual dispatch.
>
> I know that's what C++ does. But I got the impression that in C# this is
> a compile-time error. (Not that I can find any definitive word on this,
> mind you...)
AFAIK it is a compile-time error, unless you explicitly specify that you
DO want to override it.
C# has a lot of these "if you DO mean it, say so in the code" things.
Which I, personally, think is pretty smart.
>>> You can't make something public if it refers to private types. And so
>>> on.
>>
>> Yes. Well, what would you expect? A public method that returns a value
>> of a type you can't see the declaration of?
>
> Haskell lets you do exactly that, yes.
I /think/ you should avoid trying to compare maintream languages'
features to those of Haskell.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.08.2012 18:22, schrieb Orchid Win7 v1:
>> I have never quite understood the reason why C++ and Eiffel seem to be
>> the only programming languages in existence that support multiple
>> inheritance, while the rest of OO languages only support a highly
>> crippled version of it.
>
> I have to admit, Eiffel /does/ make the solution look very, very
> complicated. (I can't actually remember off-hand how the heck C++ does
> it...)
>
>> And it's not like diamond inheritance is forbidden with interfaces
>> (AFAIK,
>> although I haven't checked this.)
>
> If interfaces aren't allowed to inherit anything, then a diamond is
> impossible.
>
> Weirdly, both Java and C# actually /allow/ interfaces to inherit, thus
> defeating the whole point of the exercise.
>
> My conclusion: WTF?
I suspect it's because if you restrict multiple inheritance to classes
without data members (which is essentially what interfaces are), you can
keep inherited classes' data structure layout fully compatible with
their parents' without additional overhead.
Otherwise, I suspect you'd need some indirection similar to a virtual
method table for the data as well - a virtual data member table, so to
speak.
As current widespread belief is that virtually all multiple inheritance
use cases can be covered with the interface approach, it seems to make
sense to avoid this extra overhead.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.08.2012 19:26, schrieb Warp:
>> Yeah, I don't know. I'm slowly coming around to the idea that maybe we
>> should forget about all this "inheritance" stuff and focus on interfaces
>> as the primary thing of interest...
>
> How would you implement a GUI library without using any kind of inheritance?
By using /interfaces/ maybe?
You can argue that a class that implements an interface effectively
"inherits" from it, but you can also argue against it. It's a matter of
how exactly you define "inheritance".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 13/08/2012 22:22, clipka nous fit lire :
>
> As current widespread belief is that virtually all multiple inheritance
> use cases can be covered with the interface approach, it seems to make
> sense to avoid this extra overhead.
When all you have is a hammer, everything is a nail.
When you make the conception, once you know there can be only one true
linear hierarchy of classes and interfaces on the side, you integrate it
in your problem. You might even forbid yourself of thinking about
multiple inheritances.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13-8-2012 23:00, Le_Forgeron wrote:
> Le 13/08/2012 22:22, clipka nous fit lire :
>>
>> As current widespread belief is that virtually all multiple inheritance
>> use cases can be covered with the interface approach, it seems to make
>> sense to avoid this extra overhead.
>
> When all you have is a hammer, everything is a nail.
or a plank. You need planks too.
or a thumb. Hammers are great to remind one of thumbs.
--
Women are the canaries of science. When they are underrepresented
it is a strong indication that non-scientific factors play a role
and the concentration of incorruptible scientists is also too low
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/13/2012 9:23, Orchid Win7 v1 wrote:
> And yet, not on any official Microsoft site. Weird, eh? (Especially whe
n you
> consider the extensive Java tutorials available from Sun.)
There are plenty of microsoft books on C#. Most of them are pretty good.
> Yeah, I just lost my job. I'm not really in the mood to spend £80+
on
> something that I might not even need...
Well, read the free one, then!
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
