Long, long time ago (when I still had a lot of hair ...) I made a 10x10 matrix of LED's, but sir, you pwned! Gread work!
@KMNY_a_ha: First you can see any of the Build2011 videos related to WinRT, second you can see the blog post of Jim. I can understand a person dislike extensions with passion, but if you can't control you rage and put questions in proper way to build a dialog you will never got the answers (I know you agree with PFYB, "knowing me knowing you, a-ha")
@PFYB:: I'll put it clearly and sincere. Herb Sutter, Jim Springfield, Diego, Stephan, Charles, C64, me, and others already answered but you insist in blinded-hate ignoring any start of dialog throwing again and again the same pre-assumptions and misconcepts about the purpose of the language extension. Ignoring its scope, its purpose, its runtime-OS relation and mainly ignoring you can use WRL templates, wrapper classes and macros if you really hate CX.
Jump on any conversation about CX with walls of (rage)text not respecting who want learn and understand more of how it works and how to work with it. For me, my personal impression this is like acting like an internet troll. It is impossible to any of already cited persons deep any conversation cause this posture of bash-demoralize first, ignore later show then you not interested (you will see this posture of not continue a conversation on any teacher or engineer/programmer leader). Why you not make like your nick name and "please fix your bugs" constructivly?
Let can you (in a general sense) respect who are interested in the CX and write your angry in a forum thread?
About the arrays, who can answer this question if, again, you posts show you are not interested in know the why? If you read the answers Stephan and Jim tried to initiate a conversation but you promptly bashed a wall of rage. I want know the deeps for this question too but your attitude is driving them away. What I can presume is cause arrays are a pointer for a chunk of memory and giving this access to the programmer can lead to a corruption of the handlers (managed by the COM apartment), also the scope of CX are the border (yea, you hated word) and its not good/safe/good practice have pointers cross boundaries, so if you want an array, use Stephan's WFC::IVector (?). Because it is a compiler keyword wich meaning is not direct a type but a context relative series of procedures (?) "But but, I will use array only internal to my code" even in this case, its safe to stay on IVector, who knows when something will go crash and leak and let lots of winrt objects orphans (!?) . But serious now, this response can lead to another full length GoingDeep, but why spend hours of labor recording it if people (like you) will throw it in the mud. Change your attitude pls
Sorry Charles for the explosive text, but I have to put it out. From now I'll no more answering to PFYB.
@PFYB : add to your tests the operator %, it retrieve a handler '^'
ref class MyClass;
auto x = %m; //x is of type MyClass ^
//now you can do like "Under the Covers of WinRT Using C++"
//and extract the vtable pointer
auto vtable_array = (ptrdiff_t *)&x;
//auto x = (ptrdiff_t *)&%m is invalid cause '&' needs an lvalue
>>A total mess.
Only because the compiler not let you do wrong stuff?
>>I wonder if they could refine the extensions to reduce the "impedance" with the rest of the C++ language.
For this point I have to disagree, the "impedance" (lets call it pervasibility) in this case is what can prevent from the border/adapter/wrapper code to invade your existent code. CX as less pervasible can force you to be doutrined and write proper wrappers while WRL as more pervasible can let you "mix" code where it is necessary (or for achieve source code compiler portability). But you cant blame the extensions for the poor choses of the programmer in doing wrong stuff (here we have a word for this, it is called "gambiarra" )
>>maybe the upper layers of Microsoft need to invest more money and more brainpower to increase C++11 support in MSVC (e.g. add new developers to VC++ Team).
Enter in the visualstudio.uservoice.com on 'Languages - C++'. There are some suggestions exact on this topic: "Speed up work on VC++: Suggestion 1: allocate more resources. ... Hire more people." (yea! 'moar' jobs! )
In regards of WPF, at least on my computer WPF only bad at cold start, but since VS2010 and the latest WinSDK you can use compiled XAML for native Ribbon and C++, it is how (sort-of) Office are done (also you can compile XAML in binary format for C# too), its verbose, but you can find a good amount of tutorials in the net and in the Chapter 10 of Hilo
(I forgot to add a pinch of speculation, the new Windows Embedded Compact 7 have a 'better' support for compiled XAML with C++ binding time for resurrect my old Axim)
@Garfield: But I was talking about the understanding (feeling) to make additions to the language in order to achieve objectives and not a syntax parallel of each other. In fact, the VCL has nothing to do with the extensions of MS but with proprietary extensions from Borland (now Embarcadero)
What I was referring earlier is to the concept of modules, the modules can export classes and interfaces, which can be written in both Delphi or C++Builder (see I don't write C++ alone cause it is C++ with Borland extensions) and consumed by both. What I see happening today is what many of the so-called "Puritans" condemned Borland for extensions to Pascal in past. Also remember that there is not only the visual components in the VCL. I once implemented a wrapper for a measurement hardware in two phases: first wrapped the driver dll with C++ (pure) classes and then wrapped a non-visual module (component) for integrate it on C++Builder/Delphi.
I do not understand the excessive anger of the people about the extensions of VS because the extensions will only achieve explicitly code going to interact with the core OS. In fact on the codes I've worked until today, VS extensions have minor impact if none at all. C++/CX is only trying to make programming productive (fast and fluid ) and removing the boilerplate but if one want no extensions at all they're already reiterated that you can use full WRT (wich ref, '^' etc are translated into). Or you can still make your killing libraries and let another people do the 'border wrapping'
>why should C++ be stripped naked to cross the border?
See the post of C64 in special about If the shell is written in C++, why not just export its base classes?. Also have of the videos from C++&B, but for shortening name mangling, when on a future version of C++ they resolve the nm plus add an ABI for exporting components then will be the day C++ will not need be "stripped" on cross the border
@C64: Nice explanations. I loved that article of The Old New Thing.
One of things that helped me to assimilate better about language extension and components was when I worked with Borland Delphi (and C++ Builder) years ago. Their component library and language extensions are also mean to be used only at the border and interchangeable for both languages (Delphi and C++). Reading about components and their design decisions worth the time. One also can look at computer science theory books and articles (COM, CORBA etc)
Making a component in RAD was pleasant and this is the why I'm excited with CX
The right tool for the job.
@C64: Yep,waiting for part2 too . I think optimizing will deserve a full talk, as Mahmoud will be giving us hints on pagefile sizes (in the second last slide).
This video reminded me that I should post some screenshots of debugging in my thread in the forums (about alignment for sse wrapped with std::unique_ptr).