Googling for an windows example of a recursive search i found this but trying to compile this with cl (and the MSVC++ tool chain) the compiler states error over error. Do I need to include some extra libraries directly as soon as i am not using the usual setup done by the MSVC++ GUI.
The posted example error codes are translated and therefore might not look exactly like they would in English.
"*": This referencing cannot be done for System::String the compiler substitutes "*" by
"^" to continue analysis
and
System::String ^ a system-owned array cannot contain this managed type
both those errors are on this line
String* directories[] = Directory::GetDirectories(dir.c_str()); //dir is a usual string
and therefore are not my coding.
What am I messing up?
The compile-line was:
cl /w /c /clr file.cpp
Directory::GetDeirectories is a .net call so it will return a .net object. You are trying to cast it to a c++ pointer. Your best bet is to declare a .net string array instead. The type is like so
array<String^>^ directories = Directory::GetDirectories(dir.c_str());
Related
Is there a way within an Intel Visual Fortran project to get a string representing the Visual Studio Solution Directory?
Get_Environment_Variable doesn't seem to have that ability as far as I can tell.
Intel Fortran 2017 and VS 2015.
From your other comments, it seems to me that you're possibly more interested in the directory containing the executable. If you know your solution directory structure you can work out the solution location from that.
You do this in two steps. First you call the Windows API routine GetModuleHandle, passing NULL as the argument. This returns a handle to the current executable. Then you pass this handle to GetModuleFileName which returns the path to the executable as a NUL-terminated string.
If you wanted to separate out just the path, you could use the Intel library routine SPLITPATHQQ.
Example:
program whereami
use kernel32
use, intrinsic :: ISO_C_BINDING
implicit none
integer(HANDLE) :: h
character(MAX_PATH) :: f
integer(DWORD) :: ret
h = GetModuleHandle (NULL)
ret = GetModuleFileName (h,f,len(f))
print *, f(1:index(f,C_NULL_CHAR)-1)
end program whereami
Within the property pages for an Intel Fortran project you can use the $(SolutionDir) macro to query the solution directory.
There are a number of ways to then incorporate the value of this macro into Fortran source when it is compiled (e.g. define a preprocessor symbol on the compiler command line and then reference that preprocessor symbol in the source), or pass the value of that macro to a runtime instance of your program (e.g. through a command line argument, specified via the relevant project property) when the program is started from within Visual Studio.
I came across an interesting error when I was trying to link to an MSVC-compiled library using MinGW while working in Qt Creator. The linker complained of a missing symbol that went like _imp_FunctionName. When I realized That it was due to a missing extern "C", and fixed it, I also ran the MSVC compiler with /FAcs to see what the symbols are. Turns out, it was __imp_FunctionName (which is also the way I've read on MSDN and quite a few guru bloggers' sites).
I'm thoroughly confused about how the MinGW linker complains about a symbol beginning with _imp, but is able to find it nicely although it begins with __imp. Can a deep compiler magician shed some light on this? I used Visual Studio 2010.
This is fairly straight-forward identifier decoration at work. The imp_ prefix is auto-generated by the compiler, it exports a function pointer that allows optimizing binding to DLL exports. By language rules, the imp_ is prefixed by a leading underscore, required since it lives in the global namespace and is generated by the implementation and doesn't otherwise appear in the source code. So you get _imp_.
Next thing that happens is that the compiler decorates identifiers to allow the linker to catch declaration mis-matches. Pretty important because the compiler cannot diagnose declaration mismatches across modules and diagnosing them yourself at runtime is very painful.
First there's C++ decoration, a very involved scheme that supports function overloads. It generates pretty bizarre looking names, usually including lots of ? and # characters with extra characters for the argument and return types so that overloads are unambiguous. Then there's decoration for C identifiers, they are based on the calling convention. A cdecl function has a single leading underscore, an stdcall function has a leading underscore and a trailing #n that permits diagnosing argument declaration mismatches before they imbalance the stack. The C decoration is absent in 64-bit code, there is (blessfully) only one calling convention.
So you got the linker error because you forgot to specify C linkage, the linker was asked to match the heavily decorated C++ name with the mildly decorated C name. You then fixed it with extern "C", now you got the single added underscore for cdecl, turning _imp_ into __imp_.
malloc returns a void pointer.so why is it not working for me without typecasting the return value?
The error pretty clear said that gcc is not allowing conversion from void* to int*.
In C, you don't have to cast. In fact it's a bad idea to cast there since it can cause certain subtle errors.
However, casting is required in C++ so that would be my first guess, that you're somehow invoking the C++ compiler. Perhaps your source files are *.cpp or *.C both of which may be auto-magigically treated as C++ rather than C.
See here for more detail:
C++ source files conventionally use one of the suffixes ‘.C’, ‘.cc’, ‘.cpp’, ‘.CPP’, ‘.c++’, ‘.cp’, or ‘.cxx’; C++ header files often use ‘.hh’, ‘.hpp’, ‘.H’, or (for shared template code) ‘.tcc’; and preprocessed C++ files use the suffix ‘.ii’. GCC recognizes files with these names and compiles them as C++ programs even if you call the compiler the same way as for compiling C programs (usually with the name gcc).
The fact that it knows you're trying to convert void* to int* means that you have a valid malloc prototype in place so I can't see it being anything other than the imposition of C++ rules.
Without code I can't help you properly, but you can try this:
p = (int*)malloc(sizeof(int));
Give more info about what you want to do and what you are allocating.
My C++ Library function is int RFD_startBackgroundThread()
My code in the overlay.js is
uri = addon.getResourceURI("components/mac/libReverbFirefoxExtensionLib.dylib");
this.extensionLib = ctypes.open(uri.path);
this.startBackgroundThread = this.extensionLib.declare("RFD_startBackgroundThread", ctypes.default_abi, ctypes.unsigned_int);
The code throws an exception on the last line. It says "Couldn't find function symbol in library".
The library is a "fat dylib binary" combining both i386 and x86_64 (but not PPC arch) on OS X Lion (10.7). Firefox version 11.
Desperately need help.
Thanks.
Rahul.
In most Unix platforms, including OS X, C functions are mapped to symbols just by prefixing with an underscore, so int foo(int) ends up as just _foo.
But that doesn't work for C++, because in C++, you can have two different functions with the same name, in a variety of different ways—you can have int foo(int) and double foo(double), or int MyClass::foo(int), or int foo<int>(int), and so on. So, C++ functions have to be "mangled" to give a unique string. (And then, that unique string is treated like a C function—that is, prefixed with an "_".)
jsctypes knows about knocking off the _, but it can't know how to mangle your function, because you're just giving it a name, not a full prototype. So, you have to figure out in some other way that the mangled name of your function is _Z25RFD_startBackgroundThreadv.
There's no portable standard for how names get mangled. However, the C++ ABI that Apple uses is based on the Itanium C++ API, which requires an API to mangle and demangle C++ functions. Xcode comes with a tool called c++filt that wraps up that API for use at the command line—but it only handles demangling, not mangling. So, it can tell you that _Z25RFD_startBackgroundThreadv means RFD_startBackgroundThread(), but it can't get the other way around.
One way to get the mangled name is to start with nm libfoo.dylib, then use c++filt to check the ones that look like good candidates, until you find one that matches the prototype you're looking for.
Another way is to automate that. Something like this:
nm libfoo.dylib | awk 'NF==2 {printf "%s ",$1; system("c++filt " $2)} NF!=2{print $0}'
… will print the demangled names of all of your symbols.
But probably the best way to go about it is to create a tiny .cpp file that has nothing in it but that one prototype, compile it, and use "otool -SV tiny.a" to see the mangled name.
So, it's not that hard to get the name of the symbol for the C++ function you want to call.
But that doesn't mean you can just call it as if it were a C function. For one pretty obvious example, if you want to call (non-static) Foo::bar(int), you'd better have a valid thing to pass as a "this" pointer, and know how to pass it. See https://bugzilla.mozilla.org/show_bug.cgi?id=505907 for details on what jsctypes in Mozilla can't do, and why.
Well, the problem was, the library does not store the symbol as-is. To see the actual names of the symbols dump the library using nm library-name (optionally redirecting it to a txt file, easier to read).
The symbol in my case was written as __Z25RFD_startBackgroundThreadv. Apparently, I had to know off one underscore and use only _Z25RFD_startBackgroundThreadv.
Thanks to Michael Dautermann!
I am trying to look for definition and declaration of the function nanf() - return 'Not a Number function, which is related to the floating point functionality on Linux gcc compiler environment - (glibc).
I need to use similar/same definition for nanf() on windows to build my code using Visual Studio.
I checked following header files in the Linux src/include folders but did not see anything related to nanf declaration.
/usr/include/math.h
/usr/include/bits/nan.h
Any pointers will be helpful.
thank you,
-AD
The declaration is just (C99 §7.12.11.3):
float nanf(const char *tagp);
or macros that expand to something equivalent. A conformant implementation is highly platform-specific, however, because the standard does not define how to interpret tagp, except to say that the behavior is equivalent to a certain call to strtof, and "The nan functions return a quiet NaN, if available, with content indicated through tagp."
Instead of trying to shoehorn C99 features into the one compiler and library that stubbornly refuses to even try to implement them, why not just use a real C compiler? There are plenty out there.