Coffeehouse Thread

48 posts

C++ needs extension methods

Back to Forum: Coffeehouse
  • User profile image
    spivonious

    The real solution is to take away the sealed keyword. Then you can subclass and add whatever you want. Extension methods just confuse things, imo.

  • User profile image
    Sven Groot

    , spivonious wrote

    The real solution is to take away the sealed keyword. Then you can subclass and add whatever you want. Extension methods just confuse things, imo.

    Extension methods were added primarily for LINQ. LINQ requires that certain methods are available on all types that implement IEnumerable<T> or IQueryable<T>. Just subclassing doesn't solve that problem, as every pre-existing list type would have to be subclassed to support LINQ in that case. And since C# doesn't support multiple inheritance, an implementation would have to written for all of them.

    Similarly, would deriving from the String class allow you to do "foo".SomeMethod()? No, because string literals still aren't an instance of that class. Same if you want to use the method on an object retrieved from another source (e.g. a method in third-party code returning an instance) which wouldn't be an instance of your derived class.

    Extension methods solve a different problem than derived classes. And the sealed keyword exists for good reason: some things just aren't suitable to be extension points.

  • User profile image
    ryanb

    , Charles wrote

    @ryanb: I'm not sure this is correct, actually, but I'll ask Herb...

    C

    You're right Charles.  I realize now that I was thinking about partial classes, not extension methods.  I retract my previous statement.  And I should have been more clear about all of this as things that MIGHT be coming in the standard at some point.  Never mind.  Nothing to see here.

  • User profile image
    BitFlipper

    @SteveRichter:

    Then maybe a modification to the extension class idea can be to allow something like this:

    if (this == null)
        ...

    ...to do what you describe. In that case the NullReferenceException will not be thrown when calling the extension method itself, but when actually trying to use "this" either explicitly or implicitly (like calling a non-static method etc).

  • User profile image
    Charles

    @ryanb: And Herb told me that there is not much momentum behind extension methods in the ISO committee...

    C

  • User profile image
    SteveRichter

    , Charles wrote

    @ryanb: And Herb told me that there is not much momentum behind extension methods in the ISO committee...

    C

    is there any talk within Microsoft to have its own native programming language? I guess, kind of like Apple has Objective-C.  A C like language with built in behavior that makes sure handles are closed and memory deallocated. Can call managed code, WinRT and COM.  Easily handle ANSI and Unicode strings. Maybe I am describing C++, but without all the stuff that makes the language hard for me to understand.

     

  • User profile image
    evildictait​or

    , SteveRichter wrote

    *snip*

    is there any talk within Microsoft to have its own native programming language?

    Not that I've seen. Most programmers are either happy using the C/C++/ManagedC++ that they have, or have chosen to go for a managed language. I'm not sure adding a new native language to the mix would have any momentum at Microsoft or with developers.

  • User profile image
    Bass

    You can also just have modifiable classes like many dynamic languages have. That lets you do extension methods and a lot of other metaprogramming type things.

  • User profile image
    evildictait​or

    , SteveRichter wrote

    A C like language with built in behavior that makes sure handles are closed and memory deallocated. Can call managed code, WinRT and COM.  Easily handle ANSI and Unicode strings.

    Like C#:

    * A C like language Check

    * makes sure handles are closed and memory deallocated. Check.

    * Can call managed code, Check

    * WinRT Check

    * and COM Check

    * Easily handle ANSI and Unicode strings. Check.

  • User profile image
    BitFlipper

    I think instead of spending resources on creating a whole new language, it might be more beneficial to spend those resources focusing on fixing areas of .Net/C# that cause people to want to use something else.

    I imaging most of the time it is because .Net is too "slow"? IIRC, tests show it is within 10% of C++'s performance. I'm sure in some areas it is significantly slower, like say when doing DSP. If you look at the IL of .Net code, it is already in a pretty optimized state but it really depends on how the JIT compiles it. I wonder how much performance can be gained by improving the JIT. Maybe have a AOT (ahead of time) compiler that is more agressive and does more optimizations etc.

    Oh and much more aggressive method inlining...

  • User profile image
    Charles

    C++ is the native language of choice at Microsoft (and C for low level kernel stuff). For Metro, we have a small C++ extension, C++/CX. For GPGPU programming, we have a small C++ extension, C++ AMP.

    C

  • User profile image
    Bass

    I don't see why open classes can't work for static/native languages by the way. Some people really think open classes it's a SUPAR BAD idea, but I never seen any argument on why.


    (Open classes means you can "reopen" any class, eg std::string, and add features to it. Similar to BitFlipper's idea.)

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.