extern "C" _declspec(dllexport)void Export3DS(const char* inputname,const char* Objname,const char* mtlname);
I am using vs2008 C++ I need the dll to be output in two mode 32 bit and 64 bit. I am able to compile the code without any error for 32 bit platform but when I switch the platform to x64 bit the error C2065: 'dllexport': undeclared identifier and C2448"_declspec': function-style intializer appears to be a function definition come out. In fact when I switch to x64 platform I didn't make any changes on the code (even a single line of code). Can somebody help me? Thanks in Advance!!!
Try __declspec, with two underscores.
Related
We are compiling fmt with the Intel C compiler on Windows 32bit and 64 bit. On 32 bit we get a strange error. Maybe we are doing something wrong but the issue is what? Here is the error message:
../master/extern/fmt/8.0.1/include/fmt/format-inl.h(1126): error: expression must have a constant value
static constexpr const uint128_wrapper pow10_significands[] = {
^
Any suggestions for a fix? We could potentially build with MSVC.
Update: format-inl.h (=inline format) is only supposed to be used in a header only mode as far I understand and that is not what I want and has not turned on. So I have to figure why this happens.
PS: fmt is great.
The expression in question is constant so this looks like a bug in the compiler or possibly incomplete implementation of constexpr. The error message is misleading but you might be able to workaround the issue by removing constexpr or some other way.
Have you tried building with a C++17 compiler? constexpr isn’t a C keyword afaik.
tried many methods, ex:
-fsyntax-only
-Wno-format
still got this warning:
xxxxx passing argument x of xxxx make pointer from integer without a cast
I want to disable this warning in any way.
//////////////////////
update:
in order to follow the rule here, I provide the specific code:
here is the source code I was testing:
https://github.com/vladermolaev/jam2ftdi
It can build successfully by Visual Studio.
However, I want to test it in Linux, I built it in Linux.
I saw the error log as I described in this issue.
Here is the problem code, the problem is the third input parameter, unsinged char *tdo.
because when calling this function in this project, it takes int as input parameter, not unsinged char*
https://github.com/vladermolaev/jam2ftdi/blob/master/FTDI_API.h#L5
int FTDI_WriteTMSandTDIandReadTDO(const unsigned char tms, const unsigned char tdi, unsigned char *tdo);
therefore, I already know it works since I built in Windows OS, I don't want to change code everywhere in linux platform.
Hope this is clear, and please unlock this issue.
Thanks.
///////////////////////
update:
for which line caused this error:
https://github.com/vladermolaev/jam2ftdi/blob/9af9c7a055707b178e5aa91ae4447686256a4790/JAMSTUB.C#L328
tdo = FTDI_WriteTMSandTDIandReadTDO(tms, tdi, read_tdo);
the usage in this project, read_tdo is int which generated this compiling warning.
Add this parameter for gcc as following:
-Wno-int-to-pointer-cast
it solves this issue.
So here is the preprocessed output of a struct:
typedef struct RPT_Item
{
wchar_t *fullPath;
RPT_ItemFlags_t itemFlags;
int isComposite;
const void *reserved;
} RPT_Item_t;
Visual Studio complains because wchar_t is not defined, its own cryptic way:
error C2016: C requires that a struct or union has at least one member
I looked at the project files and also at the particular C file where the error appears and I can confirm that "Treat wchar_t as built-in type is set to YES".
If I define the type using a typedef it compiles fine.
I used the preprocessor output so I can exclude that some nasty preprocessor #define trick play the main role.
This project contains many low-level hacks, for example the CRT is not linked (/NODEFAULTLIB).
Most of the code is not written by me, and I'm tasked to remove reference to wchar.h from a public header that uses wchar_t, because VS treats it as a built in type default. (This particular module is built only on Windows.)
I totally ran out of ideas. Is there a compiler option or a pragma that can interfere? Or could it be even a compiler bug?
Microsoft didn't explicitly document this until VS 2013, but the docs for /Zc:wchar_t says
The wchar_t type is not supported when you compile C code.
It seems that including nearly any header from the runtime or from the SDK will typedef wchar_t tounsigned short using the following sequence:
#ifndef _WCHAR_T_DEFINED
typedef unsigned short wchar_t;
#define _WCHAR_T_DEFINED
#endif
you might want to do something similar in your file that uses wchar_t.
Note that when compiling a C++ file, if /Zc:wchar_t is in effect then the compiler pre-defines _WCHAR_T_DEFINED. If /Zc:wchar_t- is in effect it doesn't - so the above snippet should work nicely with C++ as well (for MSVC anyway - I don't know how other compilers might deal with this if you're looking for something portable).
The _WCHAR_T_DEFINED macro is documented:
MSVC Predefined Macros
I have just downloaded MinGW 64 bit for Windows (I'm not quite used to Linux) on http://sourceforge.net/projects/mingw-w64/?source=dlp
When I compile the following code, I get no errors:
#include <iostream>
int main()
{
std::cout << "Code 64 bit :D !" << std::endl;
return 0;
}
Also, when I execute the program in Code::Blocks, eveything works perfectly (using cb_console_runner.exe). The problem occurs when I execute my program outside Code::Blocks. I get the error "The application couldn't start properly (0xc000007b)". By the way, I translated the error from french. Do you have any idea what is the problem or how I can debug this? Oh I forgot: I don't get any errors when code is empty (i.e. when int main(){return0;}).
Thank you!
I've seen this happen here and there when GCC's standard C++ library (libstdc++) (or libgcc as well) is not in your %PATH%. Furthermore, this may also be the case that you have a mismatched version (i.e. a 32 bit version) of the same DLL in your path. Use something like Dependency Walker to determine this.
This doesn't happen when your program is empty since you are not using any symbols from the standard C++ library and thus it is not linked with your application. However when you use std::cout that references a symbol defined in the C++ library and thus it must be linked.
While migrating a program from windows in linux I encountered a problem using the c++ standard template library. I am trying to typedef a template and I am getting the error 'expected initializer before '<' token on this line
typedef std::list< std::pair< int,double> > PairList;
Any ideas why this would work using mvc++ and not using g++ and how I can fix it?
I think this is about #includes.
The following really minimal piece of code compiles perfectly here with g++ on Linux
#include <utility>
#include <list>
typedef std::list< std::pair< int,double> > PairList;
PairList x;
One thing to remember about standard include files is that they are allowed but not required to call each other. (It's not like they're potentially polluting the namespace by this, since they all use namespace std, which you aren't supposed to mess with.)
It is possible that, in MSVC++, includes , or vice versa, but this is not the case in the g++ headers. Therefore, a program might compile in MSVC++ and not in g++, with a required header missing in the source.
Make sure all of your required headers are actually included, and you should be fine.
Did you #include <utility> for pair?
I have had no problems with the code in G++, and generally found its STL support to be superb. Do you have all the #include directives there? Sometimes those differ from platform to platform (even when they shouldn't).