Related
I want to develop universal windows apps using C++/DirectX/XAML. But it seems like there's no way to escape Microsoft's C++/CLI language. I've already browsed through the code that isnthere by default when you make an pty project, and it is all C++/CLI.
C++/CLI (/CLR) a.k.a. Managed C++ is not supported for the universal Windows apps platform, and is not supported for Windows 8 Store or Windows phone 8 either.
What you are seeing are C++/CX (/ZW) language extensions that are used on MSDN and in most of the C++ samples to consume WinRT APIs. The confusion you are having is common because the same language keywords from C++/CLI were reused when implementing C++/CX. There is no .NET Runtime, no garbage collection, and no interpreted code as there is in C++/CLI. See the Visual C++ Team blog series C++/CX Part 0 of [n]: An Introduction for more on the history of C++/CX.
You do not have to use C++/CX to author or consume WinRT APIs, but they are much easier to code against using C++/CX language extensions than pure C++. You can make use of the C++ template library Windows Runtime Library (WRL) rather than C++/CX, but you will mostly have to figure out how on your own as there are very few samples that use it and MSDN presumes you are going to use C++/CX.
The standard samples make use of Microsoft::WRL::ComPtr smart-pointer when dealing with non-WinRT COM APIs like Direct3D, but generally that's the only part of WRL used by the standard samples. I make use of WRL in DirectX Tool Kit to consume some specific WinRT APIs if you want to see some limited examples of using it instead of C++/CX.
Authoring WinRT APIs with WRL also requires a lot of manual sync work with MSIL files to generate the required metadata (but not code). If you are an expert in ATL, you would be equipped to use WRL for authoring WinRT APIs, but otherwise it's likely not worth the productivity hit to avoid C++/CX entirely.
That said, you can easily isolate C++/CX usage to specific modules in your application. I do this in my Direct3D UWP Visual Studio template so that the majority of the code is in fact 'pure' C++.
Have a look at Modern C++ for the Windows Runtime
From the project description page:
The Modern C++ Library provides a Standard C++ language projection for
the Windows Runtime. No need to use non-standard language extensions
or cryptic ABI interfaces and functions. With Modern you get a power
library for the Windows Runtime, whether you want the convenience of a
class-based API or the ability to go under-the-hood for more control.
It looks like a very complete implementation.
Update (2016-10-07): The author of Modern has joined Microsoft to continue work on a Standard C++ language projection. It has been re-named to C++/WinRT, and was recently presented at CppCon 2016 (see Embracing Standard C++ for the Windows Runtime (on YouTube)).
A pre-release version of the library (just the header files without the compiler) should be available soon. In the CppCon talk it has been announced that "we [Microsoft] hope to have something available for you [us] soon".
Considering Simon Mourier's answer to this question:
Processing Microsoft Office Outlook 2003/2007 email messages…
I plan to use the PST File Format SDK which is written in C++.
I would take this opportunity to learn more about C++ and to renew with it, since it's been quite 15 years since the last time I used it. I have already downloaded and configured Boost 1.45 which is required to work with pstsdk.
Now, I'm currently writing a Windows Forms application using CLR C++ and plan to use the pstsdk to read from PST files.
Does it matter in any way that I'm using both CLR C++ and pure C++ altogether?
Shall I consider using it a different way, or is this okay?
If you want to use a .NET (Windows Forms, or maybe even the newer WPF) user interface, the simplest approach is to build an object model in C++/CLI, implemented in terms of the native code but having a .NET interface.
Then write the UI in C# and call the C++/CLI object model (which differs from using the .NET base class library in only one way -- you have to add a reference to the C++/CLI assembly... but the C++/CLI compiler will create all the metadata that C# uses).
You can mix managed and unmanaged code, but it will be a pain to marshal everything except the built-in types across the boundaries. It's much easier to stay with more powerful unmanaged C++. You could use CodeGear C++ Builder for example (or QT). The problem with CodeGear is compiler isn't that great, so you won't be able to compile everything from Boost, but you might not need that.
C++/CLI is intended to interop with unmanaged C++- that's pretty much it's entire purpose. However, I feel that it's probably easier to write in C# if you need .NET for, say, WPF, which is an excellent technology, and just use C++/CLI for interop.
I'm planning some Symbian related development on S60 3.1 platform. It seems like generally available language options are Python and C++. However Nokia's official forum seems very much tilted towards C++.
I want to know what are the advantages and disadvantages of using Python for S60 over Symbian C++? And is it even possible to do Python programming for S60 3.1 platform?
PyS60 is good when you need to prototype something simple fast. If you try to develop a full application with it though, you'll most likely find yourself sooner or later wanting to use features that are available in Symbian C++ but not in PyS60 without writing bindings (in C++) for it. Also you'll need to deal with the right version of PyS60 runtime being available, and some of them aren't backwards compatible.
If you go for the Symbian C++ route, you can embed a python interpreter in it too.
C++ is very, very fast, and the Qt library is for C++. If you're programming on a mobile phone, Python will be very slow and you'll have to spend ages writing bindings for it.
I answer this as a user.
PyS60 is slow and not so much app and sample to start with.
C++ is good, native, fast, but if you mind deevelop app for most device (current N-series), you will not want to go with Qt, I have a N78 and tested Qt in N82 too, it's slow (more than Python, sadly but true)
PyS60 has a very limited API. Applications written using it are slow, hard to deploy (since you have to install the runtime first) and cannot be posted on the Ovi store. If you're looking for an easy way to write simple Symbian apps take a look at Nokia WRT.
If you don't mind C++ try the recently released Qt SDK 1.0. It's really powerful, future proof and will soon be supported by the Ovi store.
What is the purpose of your programming? Are you planning distribute your app through Ovi Store? If so, you should use a tool that could be tested and signed by Symbian Signed.
What does it mean? As far as I know, they don't provide such functionality for Python. So you have to choose native Symbian C++ or Qt.
By the way, Qt signing procedure is not quite clear for now. It seems Ovi Store and Symbian Signed are only allow Qt apps for a certain devices (Nokia X6, Nokia N97 mini, maybe some other). I suppose it is a subject for a change, and quite fast change, but you should consider this too.
When 3rd edition Feature Pack 1 ran the latest phones on the market, the main runtime people were using to program them was J2ME (http://www.forum.nokia.com/Develop/Java/). I know the title pits C++ against Python, but have you considered Java? It was much easier than native Symbian C++. The performance is good.
-jk
I've decided I want to get more into native code development with C++. I'm trying to decide if I would be better served using CodeGear C++ Builder 2009 or Visual Studio 2008. I currently use Delphi 2007, so I'm very comfortable with C++ Builder's IDE (its the same as Delphi), as well as the VCL and RTL.
I've never been a big fan of MFC (from the first time I played around with it in the VS 6.0 days), but haven't taken a close look at it since then.
I'm interested in hearing from some experts that have experience with both IDE's, whether they are the most recent versions or not.
Right now, I'm leaning towards C++ Builder because I believe the VCL is much more robust and easier to work with than MFC --- but as I said, it's been a while since I've used MFC. I'm not interested in building programs that rely on the .NET Framework because I'm partly teaching myself native development. Is MFC still king for Windows C++? Or is WTL or ATL the big thing?
Any C++ gurus out there want to share their opinions?
EDIT: I understand MFC is not the only gui toolkit for Visual Studio. However, I'm looking for some recommendations based on GUI toolkit + IDE. For C++ Builder, there is only 1 real option, which is C++ Builder + the VCL. For VS 2008, it's VS + MFC/ATL/WTL/QT....confusing for me since I don't know much about them.
Coming from Delphi, you'll find the VCL straightforward to use with C++ Builder. There are a few oddities, like C++ doesn't hide the fact that TObjects are all really pointers (which Delphi hides from you), and some things like array properties are accessed differently.
Two or three years back, I was looking for any way out of C++Builder, but now, with recent releases (and Embarcadero's purchase of Codegear), I'm happy with the product and the direction.
You'll find the number of string types and the assorted potential incompatibilities quite painful with C++Builder, but you'll get used to it! (std::string, char[], wchar_t[], TCHAR, AnsiString, WideString, UnicodeString and String to name a few)
Personally I'd vote for C++ Builder - because of two-way RAD and the VCL, although it may not be the best way of learning modern C++ idioms.
Visual Studio and MFC are not the same. I use Studio all the time and I avoid MFC like the plague. You can use WTL, ATL, Win32 or any number of libraries to create apps without MFC.
The simple answer is that for pure C++ development it has to be VC++.
To expand: as a pure C++ development environment you simply cannot beat VC++, the debugger is better, the IDE is superior (all IMHO, of course). I've used it to develop libraries that I then use from C++Builder because of these reasons.
However once you start into UI development, or anything that you can solve using the VCL or components C++B is the better choice. Compared to the VCL, MFC or ATL are horrible by comparison, and so that leaves you to use .NET, which is probably a better option, but not
I'm not sure that I'd recommend building a new product using C++B or Delphi based on the last few years of 'direction' from the vendors. However that appears to be changing for the better, but until a little more time has passed it is hard to tell how the promises translate into reality.
If you're doing pure C++ development on Windows then it's hard to beat VS. The compiler is fast, quite standards-conforming and produces well optimised code. The debugger is the best on any platform. The IDE is OK.
It's also clearly the most widely-supported compiler toolchain on Windows. Download any open-source project/library and, if Windows is supported, it's likely to have been built and tested using VS. Its popularity also ensures that it's the most useful to have on a resume.
What does Builder give you? A reasonable GUI library. Well, that's good but there are many other decent GUI toolkits out there (wxWidgets, GTK, Qt etc). Many are open source and cross-platform.
However, these days I find it better to restructure my applications to provide an API and then build the GUI on top of it in a different language. C++'s strength is not in GUI development. At least not today...
I'd choose - and recommend - VS over Builder.
I haven't used C++ Builder for years but on the topic of C++ debugging, Visual Studio 2008 is way out in front of other IDEs and previous VS especially if you use STL containers as it makes it very easy to inspect their content.
However, on the GUI side, C++ is now very much a second-class language for Microsoft. The way of the future is WPF and C++ is not supported as a XAML-friendly language: We will continue investing in C++/CLI to enable developers to expose native C++ assets to the managed world and vice versa. We believe that pure .NET development is done best using a .NET focused language such as C# or VB. Investing in C++/CLI will be mainly in the native-managed interop areas.
So, to create a modern-looking C++ GUI, your best option may indeed be VCL - if VCL continues to make such possible ;-)
C++ Builder is far superior than MS-VS when it comes to UI based development and Database oriented application. MFC sucks!! However VS has better debugging capabilities.
I second going for C++ Builder, given that you already know Delphi. MFC has not changed much since the VS6 days, so code written using MFC still looks like shit. However, VS has changed and is now quite a good IDE.
Also, keep in mind that C++ Builder is not stable as a product line. There have times in the past where it was not maintained/its future was not clear etc. So you're taking a chance if you want to build something that lasts.
Just for the hell of it, can we throw in eclipse to the mix as well?
I just found working in eclipse to be better than working in visual studio.
Unless you are using VS2008 with winforms, the gui support is through windows templates (typically from resources) which is old hat and you probably don't want to use. So the gui support in VS2008 isn't that special.
As for gui toolkit, perhaps see What is a good GUI/widgets toolkit
Well, you can use Eclipse + MinGW + Qt4 + QT Eclipse Integration and you get all of the stuff: debugger, visual GUI designer, etc.
Mind that Qt4 is dual licensed: Open Source and commercial license.
Also you can combine Qt4 with Visual Studio (even with Express) and use all goodnes VS gives you.
For me Qt4 is the way to go and VS over Builder.
I loved C++ Builder a couple of years ago. It was fantastic. It was a way better with its VCL than VS with its crappy MFC. Then things have been changing with every year.
Builder has been going down;
1. Builder hasn't been updated with any real functionality.
2. Borland abandoned the idea of rewriting VCL in C++ for use with Kylix and Builder
3. CodeGear mess and uncertain future of Builder put many people off the product.
VS has been getting better;
1. IDE has been improved a lot
2. Compiler from the least standard-compliant one on windows platform became the most standard-compliant (not counting GCC on MinGW of course)
3. .NET emerged and there was Managed C++ and then C++/CLI to make it possible to use this framework from within C++
We got new, strong players
1. Eclipse
2. Qt Creator
and new GUI toolkits
wxWidgets
Qt4 now has also open source license
To summarize; Builder is dead because Borland
was thinking Delphi is so wonderful they don't really need anything else to earn money
has fallen into Java hype and invested too much resources in it
didn't understand great power of C++ and instead stack to pascal, which has always been academic language with no real products created with it
Try Lazarus instead. Write once, compile many. Runs on multiple platforms. Anyone coming from Delphi and Kylix background will feel extremely at home with this RAD tool. As for future, it is open source with a strong community, development will carry on without commercial constrain.
When it comes to windows development nothing really tops Visual Studio. It is very feature rich and has an excellent debugger, not to mention the vast community of users to help you with any problems you may encounter. If a company's development tools for their own operating system weren't the best for it, I'd fear their status in the software world. But if you don't need the extra features and absolutely need a RAD tool with drag & drop (besides MFC) C++ builder isn't too far behind. Using the delphi environment prior is just an advantage for you.
The one thing about last C++ Builder by CodeGear - I mean 2009 version - is that its updates can really make you hate this IDE. After having installed the 2nd update, I found out that if/else block DOESNOT WORK PROPERLY. It can enter IF statement but cannot enter else one - and it doesnot depend on the situation - this language instruction simply stopped work at all. The time it took me to figure it out was about two or three hours - and I started to develop the needed win32 app in VS, I consider it is more reliable than the CodeGear product.
The 2nd feature I dislike that you can`t switch off Unicode support and have to use ANSI versions of win32 functions EXPLICITLY (e.g. SendMessageA(...)) which is very boring.
I barely meet the deadline to finish the job using VS2008.
It s just my experience, the choice to make is yours
For native C++ development I wouldn't want to use either C++ Builder nor VS. These IDEs are all optimized for the use with their frameworks.
I would rather choose Eclipse, Code::Blocks or Codelite. These IDE's are not optimized for any framework and you can switch between several compilers on severeal platforms.
2012 is Almost ending. I was a Borland C++ user and then swithced to VC++ 6.0. Recently there was a requirement ffrom a client who wanted a GUI end for their product and didnt want the dependency on .NET framework. so I explored the Embarcadero RAD Studio XE2.
When it comes to C++ RAD development, I think not even MSVC++ comes close to it. It was like a breeze. although I found problems when compiling templates. for instance if you define a functor and want to combine the constructor with the functor call you cant do it in C++B, you have to create an object and then call the functor seperately. There were other issues also as I could not fully compile Poco library.
I found the solution by creating the DLLs in VC++ and calling them from the C++B frontend. that gives the best of both.
I hope that Embarcadero catches up with the standards soon.
(mingw32, windows xp)
Hello, I am attempting to migrate from Java to c++. I am confused and frustrated about finding, installing, and compiling non-standard c++ libraries. in Java it's so convenient they stuffed every functionality and documentation ever needed in java's standard api. Is there a list of essential c++ library such as Threading, gui, networking, image\ audio processing, xml, etc.etc. in one place? or possibly, offered as a single package?
I tried installing QT library for weeks and it wont even compile. in Java i used to learn by trial-and-error to learn new aspect of functionality, but that would be impossible if i can't fetch and run new api in the first place.
please, i need your suggestion, originally i wanted to break free of Java's abstraction, but now i just want to be able to use c++ before I decided shooting myself in the head.
The C++ standard library is extremely light. It contains nowhere near the functionality offered by the Java runtimes or by the .NET CLR.
The Boost libraries add a whole bunch of functionality to C++, but not much (if any) in the area of user interface.
For UI, there's the question of which platform you're targetting. If it's Win32, then you can use the straight Win32 API (mostly designed for C, but there are some C++ wrappers for parts of it). If you want cross-platform, then you're looking at QT or GTK (although there are others).
But, as Andrew already said: "why do you want to learn C++ anyway?". Don't get me wrong: I program in C++ for a living, and actually enjoy it (although I'm beginning to suspect a case of Stockholm Syndrome). If I had to start again, I'd go with a more modern language and environment (Java or C#; or Ruby or Python).
My advice would be: take it one step at a time.
First, figure out how to include a pre-built library in your code. I'd recommend starting with ZLib (it's got a very easy design to work with and it's also a useful tool to have available). Once you've got the pre-built library working, remove it and try compiling ZLib from the source code. Ask on Stack Overflow if you need help at any point, we'll get you through it.
By the time you get that working, you should have all the knowledge you need to get Qt compiled and installed too.
Threading, XML, Networking, some image generation, encoding and processing - boost provides those. As for XML, there's for example Arabica - it abstracts away platform-specific libraries by wrapping them with a nice standard C++ scent.
The GUI part is a different problem.
There's Qt, wxWidgets, gtk with c++ bindings (gtkmm), native libraries for each platform and their C++ wrappers (WTL is an excellent library for Win32), but as the C++ standard evolved and boost is becoming part of the standard (C++0x coming soon), there are no GUI frameworks that leverage those standard facilities and introduce their own instead. They do their job very well though.