Working with a C++ class library. One class has a function that returns the position and size of a window.
void  GetWindowRect(long *XPos, long *YPos, long *Width, long *Height) const; 

But I need the window info as a RECT. In C# that is no problem. Just code an extension method. No can do in C++.  Even the simple process of organizing your code is a bit of a chore in C++ compared to C#.  As I code the helper functions which will work like extension methods, where to place the code? I do not think I can add sub folders to a c++ project like I can in C#.

-Steve

In the meantime you can just use a static method:

__inline void GetWindowLongFromObject(__in Object* o, __out RECT* rect)
{
  o->GetWindowRect(&rect->x, &rect->y, &rect-.w, &rect->h); 
} 

5 minutes ago, evildictaitor wrote

{
  o->GetWindowRect(&rect->x, &rect->y, &rect-.w, &rect->h); 
} 

neat. Drop the values directly into the RECT struct.  Only problem is a WIN32 RECT does not contain a height and a width. But I like the idea.

thanks,

10 minutes ago, evildictaitor wrote

This sounds like something you should take up with the C++ standards committee. They decide how the language works.

I would rather Microsoft go the route of Microsoft extensions to the standard..  And I assume the organization of a C++ project is not something the C++ standards commitee deals with.  I asked about organizing code in a project with sub folders.
http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/f9d51ab4-a7ff-46e2-9471-143536e0d2be

You can add filters to C++ project source files and header files. They are kind of like logical folders in that they organize the code for you, but do not actually create a sub folder in the file system.

I always find it interesting when people say "I wish that Microsoft would stop following standards,"

15 minutes ago, Ion Todirel wrote

Extension methods is one of my least favorite features in C#, they are a hack to inject functionality into something that doesn't have it. Mixins can be a better choice sometimes, and you can do that in C++.

a mixin is created by creating a new class that is based on the class being extended?

http://www.jakesee.com/2009/04/c-mixins-a-powerful-concept/

I have a class library that is returning an instance of a class. How to apply the mixin pattern to an object that already exists?

24 minutes ago, evildictaitor wrote

Raymond Chen puts it better than I can (http://blogs.msdn.com/b/oldnewthing/archive/2012/01/13/10256146.aspx):

I always find it interesting when people say "I wish that Microsoft would stop following standards,"

no, I want Microsoft to adhere to standards. But I also want them to provide extensions. in my case, the code I use comes from all platforms. The code I write only needs to run on Windows.

Edit:  I want Microsoft to make it easier for me to write and organize my code.  As it is, using C++ is more wrestling than coding.

1 hour ago, SteveRichter wrote

*snip*

a mixin is created by creating a new class that is based on the class being extended?

http://www.jakesee.com/2009/04/c-mixins-a-powerful-concept/

I have a class library that is returning an instance of a class. How to apply the mixin pattern to an object that already exists?

 

Indeed, mixins, at least the mixins I've seen are no substitute for extension methods at all.

I like the |> pipe operator in F# but in terms of tool and user friendliness, nothing beats extension methods. Dot dot dot...

EDIT -- Never mind -- I was thinking of partial classes, not extension methods...

C

3 hours ago, SteveRichter wrote

*snip*

no, I want Microsoft to adhere to standards. But I also want them to provide extensions

You can't have it both ways. Either Microsoft conforms to standards and doesn't provide extensions, or it provides extensions that don't conform to standards.

40 minutes ago, Bass wrote

You just need to support the standard, and provide a strict standards mode flag 

Internet Explorer tried that, and they get endless criticism for doing so.

13 minutes ago, evildictaitor wrote

*snip*

Internet Explorer tried that, and they get endless criticism for doing so.

Users can run code compiled by a standards non compliant compiler. They can't use a web site that does not conform to their browser.

IE does support web standards really well these days, while still supporting IE-only extensions. That's fine.

public static extension class string
{
    /// <summary>
    /// Shows how a method is implemented
    /// </summary>
    public int GetWordCount()
    {
         var wordCount = 0;
         // Code that counts words
         return wordCount;
    }

    /// <summary> 
    /// Shows how a property is implemented
    ///</summary>
    public int WordCount
    {
        get 
        { 
             var wordCount = 0; 
             // Code that counts words
             return wordCount;
        }
    }
}

Other than the "extension" keyword, it is identical to how the "partial" keyword works. Of course the extension keyword will cause the compiler to impose extension-specific rules. For instance, you can't add fields to the extension class. Doing so will result in a compiler error.

In addition, the compiler will handle the "this" pointer automatically, and a NullReferenceException will be thrown if you try to access an extension method/property when the object is null. So if I type...

string nullString = null;
var wordCount = nullString.WordCount;

...I will get a NullReferenceException thrown just like I would if I called any other method on it.

The advantage is that we don't have to deal with the current awkward syntax that itself can't handle properties. I remember reading somewhere that supposedly the reason that extensions do not support properties is because they could not come up with satisfactory syntax to do it.

BTW this also allows you to create static methods.

28 minutes ago, Bass wrote

What about C++/CLI? 

That's not C++.

15 minutes ago, BitFlipper wrote

BTW this also allows you to create static methods.

Static extension methods don't make sense, because extension methods are syntactic sugar around being able to use the "." notation on an object. Static methods don't use that "." so there's no point.

class StringHelpers { 

static int StringToIntDoesntNeedToBeAnExtensionMethod(string str)
{
  return int.Parse(str);
}

int ButItDoesIfItRequiresDotSyntax(this string str)
{
  return int.Parse(str);
} 

void Main()
{

  int i = StringToIntDoesntNeedToBeAnExtensionMethod("foo");

  int j = "foo".ButItDoesIfItRequiresDotSyntax();
} 

} 

2 minutes ago, evildictaitor wrote

*snip*

That's not C++.

They still extend C++, though. There are various MS-specific #pragmas, some behaviours that deviate from the standard, various __ keywords like __declspec (those may be allowed by the standard, but using them still breaks portability), the COM smart pointer #import directive, and I'm sure there's more I'm forgetting right now.

We must go deep into the philosophy of what it means to be a type. Methods can naturally belong to classes, while fields belong to objects.

6 minutes ago, Sven Groot wrote

They still extend C++, though.

That's true (tbh I'm not sure a standards compliant C++ exists at all). But that doesn't mean making it less standards compliant would make it better.

The point of standards is that there is a common baseline that just works. If I write standard compliant code I expert it to work on all standard compliant platforms (if that be compilers, OSes, browsers, etc.). This is very helpful for portability, having the baseline with clearly defined boundaries. But it does not mean every platform has to be bit-for-bit the same interface.

7 minutes ago, Bass wrote

Standards compliant means it implements the standard.

No, it means that it complies the standard. The C++ standard includes as normative the C++ grammar and parsing rules, so anyone who extends that is not standards compliant.

Mac OS X is POSIX compliant even though it has an entire universe of APIs besides POSIX.

So is Windows

Web standards are much the same.

Web standards don't exist. Nobody owns the web. On the other hand, C++ is an ISO standard.

The point of standards is that there is a common baseline that just works. 

The point of standards is to be standard. If I write some code on my standards compliant machine it should succeed or fail in the same way on your standards complaint machine.

I think it's fine as long as there is a way to enforce strict standards compliance (eg: a compiler switch). Just my opinion.

In school for C code we used to pass the -ansi flag to gcc to ensure strict[er] standards compliance. I've never seen that done in the "real world" yet, since project design often guaranteed to use a specific compiler and platform anyway.

Apparently you can get finer grained than that with the -std flag. gcc also documents all it's extensions, which is nice (and educational, I think).

It's interesting that the Linux kernel actually uses many of these extensions, so gcc is typically the only compiler that can reliably compile Linux. Although Clang has been implemented many of gcc's extensions and has made a lot of progress in this.

So anyway I think the point is, extensions to standard languages are pretty common and not very controversial.

It makes sense when you want to do something like:

public static extension class string
{
    public static string Longest(string s1, string s2)
    {
        if (s1 == null)
            return s2;

        if (s2 == null)
            return s1;

        return s1.Length >= s2.Length ? s1 : s2;
    }
}

...or...

public static extension struct float
{
    public static float[] FromPcm16(Int16[] srcBuffer)
    {
        var dstBuffer = new float[srcBuffer.Length];

        // Convert to float...
       
        return dstBuffer;
    }
}

44 minutes ago, cbae wrote

@BitFlipper: In your example, where is the field "wordCount" declared? And how is it declared? Is it a static field? If it is, then it's useless since all instances would share the same value. If it's not static, how can this static extension class reference it?

You misunderstood the example."wordCount" is not a field, it is a local variable inside the method (or property) that is used to calculate the number of words. That is why I specifically said you will get a compiler error if you try to add field members. I'll edit the example to make it more clear.

Assuming that you design an useful feature, based on an actual need, there are several possible disasters that might happen:

- the relevant standard body decides to implement that feature, but with a different syntax. Politics aside, that's quite likely to happen as nobody is perfect and they have the 20/20 hindsight your implementation provides. You end up with a compiler that implements the same feature in two different ways, one of which (yours) is considered inferior. Ouch.

- the standard body decides to implement that feature, but with different semantics. You have to decide whether it's better to break everybody's code and documentation or fail to implement the standard correctly.

- Worst of all: the standard body decides to implement an unrelated, but more visible feature whose syntax clashes with yours. Good luck fixing that.

If the browser wars taught us anything is that the only way to properly extend a standard is to participate and put pressure on the committees. With a big smile, of course.

59 minutes ago, Bass wrote

@evildictaitor:

I think it's fine as long as there is a way to enforce strict standards compliance (eg: a compiler switch). Just my opinion.

In school for C code we used to pass the -ansi flag to gcc to ensure strict[er] standards compliance. I've never seen that done in the "real world" yet, since project design often guaranteed to use a specific compiler and platform anyway.

Apparently you can get finer grained than that with the -std flag. gcc also documents all it's extensions, which is nice (and educational, I think).

It's interesting that the Linux kernel actually uses many of these extensions, so gcc is typically the only compiler that can reliably compile Linux. Although Clang has been implemented many of gcc's extensions and has made a lot of progress in this.

So anyway I think the point is, extensions to standard languages are pretty common and not very controversial.

I think you have a good point here.

I also like the way you can switch on extensions for GHC.

There was also quite some negative reactions to some new WinRT extensions for C++ in one or more video posts on this site - but why, if it's restricted to a switchable compiler extension (which admittedly, I'm assuming it is).

As for extension methods, I seem to remember D having something close to it, where you can declare a function on a type, including a primitive type and instead of calling it like foo(x) you can say x.foo. But that's more like an extension property.

Anyway, there are good uses and probably not so good uses for extension methods but look at LINQ and how useful they are there. Also, don't extension methods prevent you from using implementation details (no access to private and protected parts)? This makes them just syntactic sugar for static functions and how can one argue against those?

The disadvantage there is that it can lead to horribly ugly syntax (witness the first version of Managed C++).

52 minutes ago, BitFlipper wrote

public static extension class string

{
    public static string Longest(string s1, string s2)
    {
        if (s1 == null)
            return s2;

        if (s2 == null)
            return s1;

        return s1.Length >= s2.Length ? s1 : s2;
    }
}

...or...

public static extension struct float
{
    public static float[] FromPcm16(Int16[] srcBuffer)
    {
        var dstBuffer = new float[srcBuffer.Length];

        // Convert to float...
       
        return dstBuffer;
    }
}

What's wrong with 

public static class StringHelper

{
    public static string Longest(string s1, string s2)
    {
        if (s1 == null)
            return s2;

        if (s2 == null)
            return s1;

        return s1.Length >= s2.Length ? s1 : s2;
    }
}

...or...

public static struct FloatHelper
{
    public static float[] FromPcm16(Int16[] srcBuffer)
    {
        var dstBuffer = new float[srcBuffer.Length];

        // Convert to float...
       
        return dstBuffer;
    }
}

Then why have extension methods at all when helper classes is all we need?

40 minutes ago, BitFlipper wrote

@evildictaitor:

Then why have extension methods at all when helper classes is all we need?

The difference is that invoking a method as if it was an instance method if it logically operates on that instance has actual readability benefits (especially in the context of LINQ, which the feature was invented for), e.g. list.Where(condition) vs. Enumerable.Where(list, condition), whereas the difference between writing String.Longest or StringHelper.Longest isn't that great.

11 hours ago, BitFlipper wrote

I still think the way extensions in C# was implemented is wrong. It looks and feels like they could not really come up with an ideal syntax and ended up with the awkward result we have today. My suggestion is to do it this way:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

public static extension class string {     /// <summary>     /// Shows how a method is implemented     /// </summary>     public int GetWordCount()     {          var wordCount = 0;          // Code that counts words          return wordCount;     }        }

 

keep in mind that extension methods apply to all types, like enums and interfaces.

Also, I like that an extension method can be called on a this value that is null.

For a lot of the classes I create I code two extension methods. One, named "ToXElement" returns the object in XElement form. The 2nd, named "[ClassName]OrDefault" is an extension of XElement and returns the object instance from an XElement.  Being able to test for null in an extension method is great when going from XElement to object because you never know if the XDocument contains your XElement or not. And these two methods belong in the same source file with the class they are extending, despite one apply to XElement and the other to the actual class.

  public static class PresentationSpaceExt  {    public static XElement ToXElement(this PresentationSpace Space, XName Name)    {      if (Space == null)        return new XElement(Name, null);      else      {        XElement xe = new XElement(Name,             new XElement("Fields",               from c in Space.Fields               select c.ToXElement("Field")),               Space.Dim.ToXElement("Dim"),               Space.CursorLocation.ToXElement("CursorLocation")          );        return xe;      }    }    public static PresentationSpace PresentationSpaceOrDefault(      this XElement Elem, XNamespace ns, PresentationSpace Default = null)    {      if (Elem == null)        return Default;      else      {        var dim = Elem.Element("Dim").PresentationSpaceDimOrDefault(ns, null);        var loc = Elem.Element("CursorLocation").DisplayLocationOrDefault(ns, null);        var flds =        from sam in Elem.Element(ns + "Fields")          .Elements(ns + "Field")          select sam.PresentationSpaceFieldOrDefault(ns, null) ;        var ps = new PresentationSpace(loc, dim, flds);        return ps;      }    }  }

59 seconds ago, 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.

17 hours ago, 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.

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).

C

15 minutes ago, 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.

12 minutes ago, 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.

5 hours ago, 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.

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...

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