Thread: Microsoft VC++

MPF is usable by managed languages (C#, C++/CLI (this is not native C++!), etc). All managed languages can interop with native languages (google it).
C++/CLI can also call C++ directly, so you can marshal data between managed/native via some translation layer written in C++/CLI.
.NET and MPF are not the same thing. MPF is a specific GUI framework/library available in .NET.
C# does have a standard library (the .NET framework).

There are also GUI libraries for C++ (e.g. MFC, Qt).

Originally Posted by FourAngels

Okay, that is what I thought, there are now very similar features available in C#. I can still read my textbook and learn the newest C++ from Bjarne and than do a translation to C# by substituting very similar language features instead of doing the unsafe code portions that have std::c++ mixed with the framework code (so I can access .Net instead of MFC).

Well, you probably could, but shouldn't. It is true that if you know C++, learning C# is very simple, but if your goal is to write in C#, learn C#, don't try to learn C++ and then translate. You wouldn't be getting the most out of C#, which while heavily inspired by C++ and Java, is a different language with its own neat features (I absolutely love null coalescing and now the new null conditional operators).

You are mumbling a lot of things here. The Win32 API interface is written in C, not C++. "Modern" C++ refers to using the C++11 and 14 standard as opposed to C++03. Also, it was never, and probably never will be, renamed to modern C++. That's just a phrase that's used by the community today.

C# IS a rich language. Stop pretending it is not. Start trusting it. It's a great language. It's also an open standard.

Just start looking for libraries for either C++ or C#. Can you find anything? If you do, write a quick prototype for both languages. Which is easiest? Pick that one.

Originally Posted by Elysia

"Modern" C++ refers to using the C++11 and 14 standard as opposed to C++03. Also, it was never, and probably never will be, renamed to modern C++. That's just a phrase that's used by the community today.

Indeed, "modern" means "relating to present and recent time", so the term evolves as C++ evolves and depends on the timeframe of the discussion (e.g., my "modern Japanese history" university module started with the battle of Sekigahara in 1600 as the reference point for "modern"). In a general sense "modern C++" refers to multiparadigm programming using standard C++, so maybe a decade ago it would have referred to C++ written according to C++98 and C++03 and associated techniques and styles, as opposed to pre-standard C++ code and associated techniques and styles. However, once C++11 arrived, newer techniques became standard and hence more accessible, and as the pre-standard styles and techniques disappear, "modern C++" now refers to C++ programming that uses such post-C++11 techniques, libraries, etc, but you may find that existing books (that still contain considerable relevant material) refer to C++03 as "modern", which when considering a longer timeframe it still is.

However, once C++11 arrived, newer techniques became standard and hence more accessible, and as the pre-standard styles and techniques disappear, "modern C++" now refers to C++ programming that uses such post-C++11 techniques, libraries, etc, but you may find that existing books refer to C++03 as "modern", which when considering a longer timeframe it still is.

O_o

You would be nearer correct if not for idioms, libraries, and techniques we've used for over a decade. The nature of "Modern C++" hasn't changed very much in a long time. The face of "Modern C++" has only changed. We spell components with `std::` these days because the standard library is catching up with libraries used for years. We use `auto` and lambdas because the standard language is catching up with how we want to express code. We have "rvalue references" because the standard formalizes idiomatic library solutions. The fact is that old,reliable, and well-understood techniques became standard.

A few of the ideas we're using now is slated for the C++17 standard. A great many of the ideas we're using now isn't being conscidered for the C++17 standard. A couple of the ideas we're using now is being delayed for a later standard because C++17 is already so large an update.

The community sets the goal for the standard. The standard, almost by definition, always comes too late for the "Modern C++" benchmark.

Soma

Originally Posted by FourAngels

...but lets get a bit more technical for a minute. The C++ plumbing work on Windows is still fine if you are writing a system application, if you want to access ports and sockets, write a device driver, etc. I would not waste my time however creating Windows in MFC or Win32 when the option of using .Net is available.

Windows programming doesn't have "C++ plumbing". Essentially you have native code and managed code, and you can use a multitude of languages for either. The only thing on your list that's actually necessary to do in native code are device drivers; all kernel-mode code is unmanaged. The .NET framework (which is managed code) actually has great support for ports and sockets, as well as higher-level methods of communication - for example, it's quite easy to both write and consume SOAP / RESTful web services, and do so in a way that the framework handles the underlying details of the communication, making a web service call no more difficult than a function call.

Hold on a sec, listen to this. Right, you can access servers such as the database or a web service or a web server, all from the .Net framework, but is doing it that way better than not using a framework because here with the framework you have objects communicating with each other sending messages back and forth and following protocols. The language now has to support this object oriented functionality and it also has to sit along side with non native languages like XML. The editor (Visual Studio) is able to fold up pieces of code and hide them, the editor also might have to do many other things....is it too cluttered.

Is using the framework faster - yes, it's much, much, much faster, and it makes for very clean, uncluttered code. To consume a single web service requires minimal setup, and calling the service can basically be as simple as two lines of code.

Compare that to what you'd need to do to consume a SOAP-based service without using a framework:

* Open a socket
* Build an XML document with your web request
* Transmit the document
* Receive the response
* Parse the response XML

When you use the framework, all those details happen behind the scenes. You don't need to know or care that a SOAP-based web service is transmitting and receiving XML documents - to you, it's just parameters in a function call.

Sure, it makes some auto-generated code, but you don't really even need to look at those source files.

Originally Posted by FourAngels

Well can you use the c++ stl with WPF or not? I am still confused about that. I am going to have to read a few docs on Visual Studio. I will post questions to the C# forum...maybe even if they are c++ .Net questions? Oh well, I can find out for myself in short order but like I said the default language is C#. Oh well. Now the first thing that I have to do is open a WPF project as my first ever application...see if c++ allows me to.

By "STL" I assume you mean the portions of the C++ Standard Library that were originally modeled after the pre-standardization Standard Template Library?

To use WPF you need to use C++/CLI - which, yes, includes support for the C++ Standard Library as well as other C++ standard code. C++/CLI is Herb Sutter's brainchild and he certainly is going to keep supporting things like templates (although, with access to the CLI, you also have access to generics, which are similar yet distinct).