How to call StorageFile.OpenReadAsync in C++/winrt? - c++-winrt

In my continuing efforts to load a collection of .svg files in C++/winrt I'm encountering a mysterious link error. I'd like to try using CanvasSvgDocument.ReadAsync(resourceCreator, filestream). To get there it is first necessary to get the stream from the StorageFile, and this would appear to be the way to do it (nextFile, a StorageFile, is already loaded in this example). This is of course within a method defined as an IAsyncAction. I'll list the #includes and namespaces from the top of the file.
#include "winrt/Windows.ApplicationModel.h"
#include "winrt/Windows.Storage.h"
#include "winrt/Windows.Storage.Streams.h"
#include "winrt/Windows.Foundation.Collections.h"
#include "winrt/Windows.Storage.Search.h"
#include "winrt/Windows.UI.Core.h"
#include "winrt/Windows.UI.Xaml.Media.h"
#include "pch.h"
using namespace winrt;
using namespace Windows::Foundation;
using namespace Windows::Foundation::Collections;
using namespace Windows::Storage;
using namespace Windows::Storage::Provider;
using namespace Windows::Storage::Search;
using namespace Windows::Storage::Streams;
Here is the problematic call:
IRandomAccessStreamWithContentType fileStream = co_await nextFile.OpenReadAsync();
That produces a link error that I'll put in below. It doesn't matter whether or not I try the fully qualified name of the fileStream result:
winrt::Windows::Storage::Streams::IRandomAccessStreamWithContentType fileStream = co_await nextFile.OpenReadAsync();
either way I get this link error:
Error LNK2019 unresolved external symbol "public: struct
winrt::Windows::Foundation::IAsyncOperation
__thiscall winrt::impl::consume_Windows_Storage_Streams_IRandomAccessStreamReference::OpenReadAsync(void)const "
(?OpenReadAsync#?$consume_Windows_Storage_Streams_IRandomAccessStreamReference#UIStorageFile#Storage#Windows#winrt###impl#winrt##QBE?AU?$IAsyncOperation#UIRandomAccessStreamWithContentType#Streams#Storage#Windows#winrt###Foundation#Windows#3#XZ)
referenced in function "public: struct
winrt::Windows::Foundation::IAsyncAction __thiscall
AppEngine::ResourceManager::LoadSvgResources$_ResumeCoro$2(struct
winrt::Microsoft::Graphics::Canvas::UI::Xaml::CanvasControl)"
(?LoadSvgResources$_ResumeCoro$2#ResourceManager#AppEngine##QAE?AUIAsyncAction#Foundation#Windows#winrt##UCanvasControl#Xaml#UI#Canvas#Graphics#Microsoft#6##Z)
I've also tried using auto as the result type, no luck. What is the right way to obtain a stream using OpenReadAsync() in C++/winrt?

You are apparently compiling with precompiled headers enabled (hinted to by the #include "pch.h" directive). When doing so, the header used to generate the precompiled header must be included on the first non-empty, non-comment line in the compilation unit consuming it.
The /Yu (Use Precompiled Header File) documentation has the relevant information:
The compiler treats all code occurring before the .h file as precompiled. It skips to just beyond the #include directive associated with the .h file, uses the code contained in the .pch file, and then compiles all code after filename.
In other words, all your includes preceding the #include "pch.h" directive are ignored. Since C++/WinRT is a header-only library, this will eventually result in linker errors.
To fix the issue
Move the #include "pch.h" directive to the very top of the file, or
Replace the #include directive with the /FI (Name Forced Include File) compiler option on the relevant compilation units, or
Disable use of precompiled headers.

Related

numpy C-API extension fails to compile in separated file

Currently writing a C extension for Python,
I successfully compiled and use the numpy C-API within the main/loader file of the module extension.
I am now trying to move the logic into a different C file.
Following the documented procedure, I set up the following declarations.
Inside the module loader file:
#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION
#define PY_ARRAY_UNIQUE_SYMBOL CCMAP_ARRAY_API
#include "numpy/arrayobject.h"
Inside the file carrying the interactions with the numpy API
#define NO_IMPORT_ARRAY
#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION
#define PY_ARRAY_UNIQUE_SYMBOL CCMAP_ARRAY_API
#include <Python.h>
#include "numpy/arrayobject.h"
The compilation breaks on the file carrying the interactions w/ the numpy API
In file included from ccmap/src/molecular_object.c:1:
In file included from ccmap/include/molecular_object.h:25:
In file included from /Users/MYNAME/Library/Caches/pypoetry/virtualenvs/pcmap-zIv2c8Xw-py3.9/lib/python3.9/site-packages/numpy/core/include/numpy/arrayobject.h:5:
In file included from /Users/MYNAME/Library/Caches/pypoetry/virtualenvs/pcmap-zIv2c8Xw-py3.9/lib/python3.9/site-packages/numpy/core/include/numpy/npy_interrupt.h:23:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/signal.h:69:42: error: use of undeclared identifier 'NSIG'
extern __const char *__const sys_signame[NSIG];
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/signal.h:70:42: error: use of undeclared identifier 'NSIG'
extern __const char *__const sys_siglist[NSIG];
^
2 errors generated.
error: command '/usr/bin/clang' failed with exit code 1
Under MacOS 11.6, I am missing a point here. Should I change/adapt my toolchain for such a seemingly minor change in file organization ?

typedef an sc_fixed but got template error

Trying to define a simple sc_fixed type in Visual Studio 2017:
#include <systemc.h>
#include <sysc/datatypes/fx/sc_fixed.h> # just in case
....
typedef sc_fixed<16, 4> fixed_type;
....
This typedef line resulted an error:
E0864: sc_fixed is not a template
Had no idea why this error popped, even included sysc/datatypes/fx/sc_fixed.h. Why does it say "not a template"?
From INSTALL file shipped with SystemC
SystemC 2.3 includes a fixed-point package that is always built.
When compiling your applications with fixed-point types, you still have
to use compiler flag -DSC_INCLUDE_FX. Note that compile times increase
significantly when using this compiler flag.
Using your code as an example
#include <systemc.h>
#include <sysc/datatypes/fx/sc_fixed.h>
#include <iostream>
typedef sc_dt::sc_fixed<16, 4> fixed_type;
int sc_main(int, char**){
fixed_type ft(1.25);
std::cout << "ft = " << ft << '\n';
return 0;
}
Gives me the output
ft = 1.25
As a caveat it is best to check the docs for your particular version of SystemC as I believe this #define may have been removed in 2.3.3 (I am using 2.3.2) I am not certain.
I got the same type of error message in one of my C++ programs - E0864 - unique_ptr is not a template
I managed to get rid of this error in my program by adding this to my header file.
#include <memory>
My program managed to compile okay using this. I am using Visual Studio 2019 if that helps.

PostgreSQL C functions not resolved by Eclipse CPP

I am trying to write a C function to be executed within PostgreSQL, something that will be declared like
CREATE OR REPLACE FUNCTION ...
RETURNS ... AS 'my_c_function' LANGUAGE C;
I followed the documentation and wrote a code containing stuff like PGFUNCTION_INFO_V1(func); or PG_GETARG_VARCHAR(0);. The problem is Eclipse keeps telling me these cannot be resolved. Here are the libraries I included:
#include <libpq-fe.h>
#include <postgres.h>
#include <fmgr.h>
#include <funcapi.h>
#include <executor/executor.h>
#include <string.h>
Should I include something else ? What am I missing ?
Your index may be out of date. Try rebuilding your index from the project menu.
Project > C/C++ Index > Rebuild
Additionally, make sure your included path is specified in your project settings if there is an issue including <postgres.h>.

Implicit declaration of function 'ether_ntoa' is invalid in C99

It's part of a series of functions that retrieve IP & Mac addresses from the phone.
strcpy(temp, (char *)ether_ntoa((const struct ether_addr *)LLADDR(sdl)));
EDIT: No equivalent function needed, there were just a few missing headers.
EDIT: Added cast to LLADDR(sdl)
As I read it, the error message isn't claiming that the function is missing, only that you don't include its declaration. (I don't know that it exists, only that the message has a different complaint.)
In case it helps, man ether_ntoa tells me:
#include <sys/types.h>
#include <sys/socket.h>
#include <net/ethernet.h>
I included following header file and source code compiled successfully:
#import <arpa/inet.h>

How to change #import "..." into #import <...> in Objective C

I have this problem with a library. I want to add it to my Objective C (iOS) project, but their docs don't say how to do that. I simply copied it over. Now their main file has this:
#include <LIB/Class1.h>
#include <LIB/Class2.h>
...
It didn't work for me, so I changed each <> to "":
#include "LIB/Class1.h"
#include "LIB/Class2.h"
...
And with this syntax everything works fine, I can use the lib. I guess it's not a good practice, though. How should I add a library to a project so that it works without this modification?
In Xcode Build Setting, Header Search Paths (HEADER_SEARCH_PATHS) affects search path of #include <foo.h>, User Header Search Paths (USER_HEADER_SEARCH_PATHS) affects search path of #include "foo.h".
So, set HEADER_SEARCH_PATHS for your library's header path, #include <LIB/Class1.h> should be work.
Also, Always Search User Paths (ALWAYS_SEARCH_USER_PATHS) setting can change behavior for search path #include <foo.h>. When ALWAYS_SEARCH_USER_PATHS is YES, #include <LIB/Class1.h> should be work as well.
Add path to the libpath... "" relative from source and <>relative from the external libs
ALWAYS_SEARCH_USER_PATHS is deprecated now & should be avoided. Explicitly set
USER_HEADER_SEARCH_PATHS for ".h" include syntax header files.
SYSTEM_HEADER_SEARCH_PATHS for <.h> include syntax header files.
HEADER_SEARCH_PATHS: for fallback of USER_HEADER_SEARCH_PATHS for compilers which don't support separate include paths.
https://help.apple.com/xcode/mac/current/#/itcaec37c2a6?sub=deved642222b