With C++/WinRT Microsoft apparently made quite the effort to make their APIs standard-conformant.
And finally they've also released a machine learning API along with a code sample repo.
Unfortunately, all samples are dependent on Visual Studio. Even the simplest command line demo (CustomTensorization) requires .snl files and VisualStudio.
Is it possible to write code for this API without VisualStudio by just downloading an SDK and using a regular make file?
If so, how? Please post or point to a MCVE.
Thank you.
I don't know anything about the machine learning API, but C++/WinRT is a header-only library that you can include and build from a developer command prompt quite easily. Here's a simple example:
C:\ml>type sample.cpp
#pragma comment(lib, "windowsapp")
#include <winrt/Windows.AI.MachineLearning.h>
#include <stdio.h>
using namespace winrt;
using namespace Windows::AI::MachineLearning;
int main()
{
init_apartment();
puts("Sample");
}
C:\ml>cl /EHsc /std:c++17 /nologo sample.cpp
sample.cpp
C:\ml>sample.exe
Sample
For an actual example using the machine learning API I'd suggest you start here:
https://learn.microsoft.com/en-us/windows/ai/get-started-desktop
But again, you can follow along and substitute Visual Studio with the command line and use cmake, or any other build system, if so desired.
Related
C++, WinRT, VS2017, Windows10, Bluetooth LE
I have a stand-alone C++/WinRT VS2017 console app that was used for testing code to control a Bluetooth LE device. That console app works and I am now in the process of moving that code into an existing C++ MFC VS2017 app which also works.
In the existing MFC app I first installed the NuGet cppwinrt package that I used in the test console app (no problems)
I then put the various WinRt header files that were in the console app's pch.h into the MFC's stdafx.h file
#pragma comment(lib, "windowsapp")
#include <condition_variable>
#include "winrt\Windows.Foundation.h"
#include "winrt\Windows.Storage.Streams.h"
#include "winrt\Windows.Devices.Bluetooth.h"
#include "winrt\Windows.Devices.Bluetooth.Advertisement.h"
#include "winrt\Windows.Devices.Bluetooth.GenericAttributeProfile.h"
So far, so good. The MFC app still compiles without problems. However, I then put the "using namespace" entries, that were at the top of the console app's .cpp file, into the MFC's ...View.cpp and that is when I get the compile problems
using namespace winrt;
using namespace Windows::Foundation;
using namespace winrt::Windows::Foundation;
using namespace Windows::Storage::Streams;
using namespace Windows::Devices::Bluetooth;
using namespace Windows::Foundation::Collections;
using namespace Windows::Devices::Bluetooth::Advertisement;
using namespace Windows::Devices::Bluetooth::GenericAttributeProfile;
The compile error I get is:
Error C2872 'IUnknown': ambiguous symbol MyMFCApp c:\program files
(x86)\microsoft visual
studio\2017\professional\vc\tools\msvc\14.16.27023\atlmfc\include\atlcom.h 3456
I see that IUnknown seems to be fairly universal throughout Windows APIs. How should I go about clearing up this error?
#AlanBirtles answer seems to have solved the problem. In the console app I could not compile without these using namespace entries so I just assumed that I would also need them in the MFC app. As I mentioned in my comment above, all of the namespaces compiled in the MFC app except for the two Foundation namespaces.
//using namespace Windows::Foundation; // errors IUnknown
//using namespace winrt::Windows::Foundation; // errors IUnknown
I left the rest and commented these two out and then added the code to create the BluetoothLEAdvertisementWatcher, attach a callback for the watcher.Received() and let it find my device. It ran fine. I have not yet tried with the rest of the namespaces commented out but I will.
I did try #IInspectable suggestion for using the #include <unknwn.h> before all of the WinRT namespaces. I put that in at the top and then uncommented one of the two Foundation namespaces but still got the ambiguous IUnknown error.
So the answer seems to be (for my situation anyway) that the namespaces were not necessary...at least the two Foundation namespaces.
Thanks for the help. It is really appreciated.
I don't have formal VS training, and I usually use it to program simple tools for my research. (I'm a faculty member).
I'm currently working on a C++ library for Python using SWIG, so I followed the steps suggested in How to create a DLL with SWIG from Visual Studio 2010?
Step no. 25 says "You can't build the Debug version unless you build a debug version of Python itself", but I thought one should be able to build a debug version of the C++ stuff by writing a main that uses the library from C++ itself, without touching Python or involving Python at all. (Please let me know if I'm wrong.)
A while ago I tried creating two projects in one solution (one for the library, one for a testing app), but I wasn't quite convinced with the result, so I thought it was time to try configurations. I modified the Debug config for my SWIG project following the suggestions in Redifining C/C++ entry point in Microsoft Visual Studio 2015 and the comments (changed configuration type, extension, and entry point, and added additional dependencies vcruntimed.lib and ucrtd.lib, also excluded from build the .i and the _wrap.cxx files).
The project compiles and runs, but the methods/functions in the standard <random> C++ library are returning non-random numbers. Update/clarification: In the following code,
std::normal_distribution<double> rand::distn(0, 1);
std::uniform_real_distribution<double> rand::distu(0, 1);
std::mt19937_64 rand::generator;
void rand::init() {
generator.seed((unsigned long)time(NULL));
}
double rand::u01()
{
return distu(generator);
}
the function u01() returns 0.0 always, while when calling it from Python it works as expected.
I checked the code and the generator is being seeded correctly. Also the library is still working fine from Python, so I tend to think this is not a coding but a configuration issue.
I know this would make a better question if I posted a minimal working example, but before investing time (which I think I don't have) on it I was wandering if there is something obvious I'm missing, that a more knowledgeable VS user could easily spot. Please don't get me wrong, if I'm mistaken and the answer is not so apparent, I'll really try to make the time.
Thanks in advance.
I have a header file with the following code:
Microsoft::WRL:ComPtr<ID3D11Device2> m_device;
inside a class definition. Visual Studio 2013 is saying that Microsoft is not a namespace, if I take the code and cut it out and put it in another class in another file unchanged it works just fine!
Any ideas?
Philip
EDIT: All of a sudden (without me having changed anything) Intelissense now accepts Microsoft::WRL::ComPtry as valid but when I compile it still gives me errors that it does not exists.
You need to
#include <wrl.h>
or
#include <wrl/client.h>
To get Microsoft::WRL::ComPtr in your module.
When you say "Visual Studio 2013 is saying that Microsoft is not a namespace" do you mean you get a compiler error or is just Intellisense? When dealing with headers, Intellisense can get a bit out of sync until you build again. For example:
//Test.h
class A { Microsoft::WRL::ComPtr<T> a; };
//Test.cpp
#include <wrl/client.h>
#include "Test.h"
If you just added the #include <wrl/client.h> to the Test.cpp, Intellisense might not know yet it is in scope for the header. It's perfectly valid C++ already, but a better practice is to include in your headers the ones it needs like:
//Test.h
#pragma once
#include <wrl/client.h>
class A { Microsoft::WRL::ComPtr<T> a; };
The other way this sync issue can manifest itself is if you are doing:
//Test.h
class A { Microsoft::WRL::ComPtr<T> a; };
//Test.cpp
#include "pch.h"
#include "Test.h"
//pch.h
#include <wrl/client.h>
Again, fully valid C++ that will build. Intellisense knows it works when you build, but might not until then.
Note: WRL is traditional C++ and is not using C++/CX language extensions. They both exist to make it easier to consume WinRT APIs from C++, and you will see the Microsoft::WRL::ComPtr used inside C++/CX applications when dealing with non-WinRT COM APIs like Direct3D. And you can mix C++/CX with WRL in the same application taking advantage of the fact that you can use reinterpret_cast<> between C++/CX ref ^ and ABI COM pointers. You can use Microsoft::WRL::ComPtr in old-school Windows desktop apps on Windows 7 or Windows Vista too.
With all that said, WRL and C++/CX are two distinct things.
Update: For consuming Windows Runtime APIs, you can also use C++/WinRT which is also 'standard' C++ without any need for the C++/CX extensions. See Microsoft Docs. You can use Microsoft::WRL::ComPtr for C++/WinRT applications, or you can use their variant wrl::com_ptr
I am currently using Graphics, Image, Color, and Bitmap Gdi+ classes in my C++ Application, but whenever I try to use BrightnessContrast and BrightnessContrastParams I get errors:
In Intellisense: Error: Namespace 'Gdiplus' has no member 'BrightnessContrast'
When Compiling: 'BrightnessContrast' : is not a member of 'Gdiplus'
What gives? I did find a forum post that said to add a line to "Additional Manifest Dependencies:" in the project properties, I did this but it still didn't work. The post goes on to say try looking in %windir%\winsxs if that doesn't work but I don't see how to make sense of the files in that directory. I am using VisualStudio 2010 on Windows7 64bit.
Also, I am aware that I can create my own Brightness and Contrast functions. I am wondering why I can't use the build-in Classes that are documented on MSDN.
Thanks
These members are only available in GDI+ version 1.10, the version that shipped first with Vista. You have to explicitly opt-in to use them. Like this:
#define GDIPVER 0x110
#include <gdiplus.h>
Beware that your program won't run on XP when you do this.
Where can I find these header files on Windows 7? I just installed VS2010, but seems dont have these header..
CoreLib.h
#include "Buffer.h"
#include "Logger.h"
#include "CoreLibImpl_.h"
Why would you expect them to be a part of Windows 7 or VS2010?
Google tells me what you're looking for is a part of Apache ActiveMQ. So go ahead and install the source. If you already have them and you just can't get VS to find the files, add them to the include directories.
Those names don't sound familiar. They're not one of the standard C++ headers like <iostream>, or the C headers like <stdlib.h>. Nor do they appear to be MFC headers. Why do you expect VS2010 to ship with these?