In most cases the same code can be used on both Windows and Mac unless you've. In the C++ implementation of the Fusion 360 API, all errors are reported. You should always use the Ptr template to create a smart pointer of a specific type. You can debug your C++ script or add-in using Visual Studio on Windows. See C++ Windows Forms - Visual Studio Marketplace. Perhaps you can use it if you download outside of VS but I don't know what the installation procedure is. Other than that, as I said, there are instructions for converting a CLR project to a Forms project; there is a little bit more to the procedure beyond adding a form.
MFC wasn't well adopted at Microsoft outside the Visual Studio team, but boy howdy did they promote the heck out of it to the Microsoft Developer Network (to the point of driving Borland's competing OWL library completely out of business). MFC was really well integrated in to Visual Studio, with the GUI builder naturally supporting MFC, resulting in a LOT of MSDN/Visual Studio developers embracing it. Development work on the library took place around the backdrop of the ANSI C standard being finalized, well before pretty core features of C like templates were part of the language, let alone the language being standardized or that the features were implemented by the Visual C compiler. MFC abhorred virtual tables, instead using macros to construct horrific switch statements. It had its own way of doing serialization, RTTI, exceptions and dynamic class instantiation (and remember, this started before templates existed, so a lot of these features were implemented with macros!). It generally avoided using a lot of C language features, instead using MFC alternatives so that all the tools they implemented didn't have to deal with complex parsing logic for C.
These early decisions, in not insignificant ways, contributed to later delays in introducing these C features in the VC compiler, let alone adopting these C features in MFC. Some of the design principles of the library were rather contrary to general OO practices and reflected an ambition to be the Visual Studio API for Windows, rather than a good object oriented API that evolved over time. In particular, I remember the shocking decision to default to having methods and instance variables predominantly be public, with the idea that subclasses and callers be intimately aware of the internals of components.
As a consequence, even though the library was presented as a near canonical 'C API', it was an abomination. The Windows & Office teams didn't use it, leading to the MFC team effectively building work alike components for new innovations from these teams (e.g. 'ribbons'), but more importantly making the practical feedback in to the library largely from external developers who were duped in to using it. This does not make for a robust library.
MFC was largely preferred by developers who were more 'Windows platform' focused than 'C focused'. Often they were C developers using the very selective bits of C that MFC employed (often not even all of these).
This lead to a significant contingent of developers who self-identified as C developers (rather than Windows developers or C developers) disliking MFC, and really VC right along with it. Given its design principles, it wasn't surprisingly that MFC rapidly became bloated, complicated and fragile. You can imagine how much that improved the odds of it being adopted by groups within Microsoft.;-). It really blew up with the publishing of Modern C Design, which kind of blew the doors off the design advantages that came from exploiting all those advanced multi-paradigm language features that VC had such poor support for, and which were design locked away from MFC. While initially few compilers were able to properly compile Loki library, most needed only a few tweaks and within short order were able to make it work. VC took a long time, to the point where it felt like the VC team didn't consider the language itself an important requirement; I remember Herb Sutter declaring with excitement when VC belatedly hit a major milestone: 'We can now compile unaltered Loki! Even then, MFC could be made to work with Loki, but I never remember it adopting even Loki's design patterns, let alone the library itself.
Eventually WTL emerged as a lighter weight alternative to MFC, which helped a bit. Until was all kind of washed away with the.NET runtime & libraries being the new object-oriented API for Windows.
That in turn lead to the integration of the CLR in to the C language, which, further drove a further wedge between C purists and VC. So yeah, a lot of bad blood. Much of it earned, but some of it not. Either way, a lot of emotional baggage that is more reflective of the past than the tool as it stands today (though you still see that history reflected in bits of the tool). As it happens, after years and years of coding C on Unix, I had my first experience of using Visual Studio Community on Windows just three days ago. For reference, these days I use CLion on Mac and QtCreator on Linux, both of which I like very much. I'm neither a Vim nor an Emacs guy.
Let's start with the good: the debugger seems excellent, from the little I've used of it. Context-sensitive syntax highlighting and 'intellisense' work very well too, as long as you stay within the subset of C they understand. The Git/Github integration works surprisingly well, although I'm not sure why the window says 'Team Explorer' on it, rather than just, y'know, 'Git'. So now the downsides. Please bear in mind that these are very much initial impressions: as I said above, I've only been using it for a couple of days, after a decade of Mac and Linux.
If I'm off the mark, blame it on my newbie-ness:. The installation. Whatever it is that's taking up that space, I'm pretty sure I'm never going to need 95% of it. I realise there's the cut-down VS15 preview (at a more reasonable 1.1GB), so hopefully the next version will be better in this regard. (So apparently, VS15 will be the next version of Visual Studio, the current version being VS 2015, right?
Who on earth came up with this numbering scheme? It seriously confused me when I was looking this stuff up: I assumed VS15 preview was an early and now outdated release of VS2015.). The terminology is very confusing for a newcomer. I can guess what a 'project' is, but what on earth is a 'solution'?
Does a 'solution' contain 'projects', or the other way around? If I have a 'solution', what's my 'problem'?.
Speaking of which, please please please just add good CMake support in a plugin or something. It's the de facto standard build system for C at this point, and even MS is using it for things like the GSL. I know CMake can generate MSVC proje er, solution files, but this feels very 'foreign' (what the heck are BUILDALL and ZEROCHECK, for example?). Maybe I'm being stupid, but where's the 'run' option??
There's 'build this solution' in the menus, and a big button in the middle that says 'debug locally', but I can't seem to get it to just run, without the debugger attached. Both CLion and QtCreator have a 'play' button that just builds and runs the current target like you'd expect. Obviously, the compiler is lacking. It's incredibly frustrating to type things that I know are standard C, only to have the compiler whinge at me. Because of the above, I quickly switched to using 'Clang with Microsoft Codegen'. Now my code compiles without error, but 'intellisense' still incorrectly underlines a lot of things in red, because they're unsupported with the default compiler. More than anything, there's something that is hard to put my finger on, and perhaps it's just my lack of familiarity, but I just don't feel.
'in control' in Visual Studio. With CLion and QtCreator, I feel like I know what's going on, and the interface is light enough that I don.