I want to compile the beecrypt library under VS2008. But several of the below structures produce a syntax error (C2059 syntax error: '.'):
const hashFunction md5 = {
.name = "MD5",
.paramsize = sizeof(md5Param),
.blocksize = 64,
.digestsize = 16,
.reset = (hashFunctionReset) md5Reset,
.update = (hashFunctionUpdate) md5Update,
.digest = (hashFunctionDigest) md5Digest
};
VC++ does not accept the dots in the beginning. If I comment the above, I get Linking errors later (LNK2001 unresolved symbol _md5) - so I guess it has to be uncommented.
What is this structure? For what do I need it? How do I tell VS2008 to compile it?
This type of struct initialization is a feature of C99 (ISO/IEC 9899:1999). It is not valid C++ or C prior to the latest standard.
Visual Studio 2008 only supports C90 (aka C89), so this isn't going to compile.
Edit It looks like BeeCrypt very recently changed to require a C99 compiler which effectively rules out Visual Studio. You other option is to use an older version of BeeCrypt.
Related
I am using VS 2017 Community edition, Intel Compiler 17.00 update 6 and and boost 1.66, trying to learn my way around boost::multiprecision::float128. Literally taking the example code from here and putting it in a new project for VS.
Compiling gives multiple errors, in roughly two categories/files:
In float128.hpp:
three errors of "error : identifier "xxx" is undefined" for fmaq, remquoq and remainderq. Indeed I am not able to find definitions for them - a missing include?
the global scope has no "signbitq" - this again looks like missing definition (i.e. the same as above)
For GCC the above functions are found within quadmath.h, however, the boost header doesn't seem to include it when using ICC (i.e BOOST_MP_USE_QUAD is set).
In C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\xutility: an explicit template argument list is not allowed on this declaration. There are three counts
I assume that i need to remove something that has been put in by default from the VS, but I am at a loss what exactly.
Thank you for your help
EDIT: Errors #2 above are actually not against boost at all (should I move this to a separate question?).
The following code copied from here! is not being compiled in my setup:
#include <iostream>
#include <string>
int main() {
std::string str("Test string");
for (std::string::iterator it = str.begin(); it != str.end(); ++it)
std::cout << *it;
std::cout << '\n';
return 0;
}
The exact error (one of them) is:
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\xutility(680): error : an explicit template argument list is not allowed on this declaration
1> _INLINE_VAR constexpr bool _Is_iterator_v<_Ty, void_t<_Iter_cat_t<_Ty>>> = true;
1> ^
1> detected during:
1> instantiation of "const bool std::_Is_iterator_v [with _Ty=char *, <unnamed>=void]" at line 520 of "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\string"
1> instantiation of "std::basic_string<_Elem, std::char_traits<_Elem>, std::allocator<_Elem>> std::_Integral_to_string<_Elem,_Ty>(_Ty) [with _Elem=char, _Ty=int]" at line 554 of "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\string"
I found this which indicates that there could be a problem with the particular versions used (ICC- 17.0 Up6 and VS 15.6), however i cannot really move to new intel compiler and i cannot test VS 15.4
I would like to write down how I managed to deal with error #2 from the original question, as it might be useful to someone.
Just as a reminder, the second errors I was seeing were in xutility. With the help of everyone that provided suggestions, it turned out that icc was in fact failing on very simple code - the following is enough to "break" it
int main() {
std::string str("Test string");
}
I have posted the question to intel's forums, however so far I have not received answers (for the 17.0 version of the compiler). Link here if anyone is interested.
That said, I came upon this blog post from the VC++ team, showing that the base toolset shown as v141 in VC2017 actually has had several minor revisions. It is possible to change the version of the MSVC toolchain but this needs to happen via editing of project files (rather than UI parameter changes).
My testing shows that version 14.11 (which is part of VS2017 15.3 and 15.4) works for Intel 17.0 while versions 14.12 and 14.13 (the last one is the current default for VS2017 15.6.4) do not. This has been done for Update 6 of the compiler. So in order to use the intel compiler on windows with visual studio, one needs to use particular MSVC toolchain versions.
Side note: I also installed icc version 18.0 update 1 for testing -- it too was giving compiler errors (and not just for me this time). The reason there though can be linked to some internal issue for icc, per this forum post. I can confirm that removing the compiler option /permissive- from the compiler fixes the errors irrespective of the base toolchain. Using v14.11 as base toolchain also fixes this particular problem for me with or without the option. /permissive- is a new option for icc (it is not part of 17.0).
The above solves more or less the second part of my problem with the icc. The rest of the question (boost's float128) though still remains. I will add more if i hear from boost's guys.
EDIT: the errors coming from boost turned out to be an issue there -- it was fixed by the maintainers in development branch, so this is resolved as well.
For Error #1, I got the same thing. However, after commenting the code blocks in boost float128.hpp where those four functions invoked, the float128 example code can be compiled with success. The side effect is unknown. I'm looking forward a revision on boost::multiprecision::float128.
I ran into this while compiling some portable code in gcc. Basically this strange code compiles in Visual studio which really just blows my mind:
class Zebra {int x;};
Zebra goo() {Zebra z; return z;}
void foo(Zebra &x)
{
Zebra y;
x = y;
foo(goo());
}
Visual studio lets this one fly. gcc will catch this as a compile error. Interestingly, If you typedef Zebra to int, VC++ will complain. Quite contradictory behavior. Thoughts?
This is old extension to Visual Studio, the only reference I could find on the Microsoft site was this bug report: Temporary Objects Can be Bound to Non-Const References, which has the following example code:
struct A {};
A f1();
void f2(A&);
int main()
{
f2(f1()); // This line SHALL trigger an error, but it can be compiled without any errors or warnings.
}
One of the responses notes:
There is a level 4 warning (level 4 warning are enabled if you pass /W4 to the compiler) for it
This blog post: Visual C++ is so Liberal which covers this extension notes that:
Using Disable Language Extensions (/Za) makes it an error:
As others said, this is due to Microsoft C++ extension. Though /Za flag is not recommended as it can break things.
Instead use the /permissive- switch for better standards compliancy and you will get healthy errors for these cases. Note that this flag is available since VS 2017.
The switch /Za does not support certain key Microsoft SDK header files. By contrast /permissive- offers a useful conformance mode where input C++ code is interpreted according to ISO C++ rules but also allows conforming extensions necessary to compile C++ on targets supported by Visual C++.
More info is on Visual C++ Team Blog.
I am porting my tool to PIN 3.0 using Visual c++ 2012 because I now have Windows 10. I followed the porting guide provided here
However, I ran into an error:
error C4890: '__value': use of this keyword requires the command line option: /clr:oldSyntax
When turning this /clr:oldSyntax option on, plus adding RTTI availability (/GR instead of /GR-) as otherwise it is not compatible with /clr:oldSyntax, I get more or less the same issue:
error C2059: syntax error: '__value'
this error is located in the file type_trait.h (header file of the PIN 3.0 Library)
#ifdef _STLP_STATIC_CONST_INIT_BUG
static const bool __value;
#else
static const bool __value = sizeof(__test<_Tp>(0)) == sizeof(__select_types::__t1);
#endif
Is this a common issue, and if so is there any workaround ? Or did I missed something in the porting guide ? I understand that the name __value introduced in this PIN 3.0 header is in conclict.
This is apparently a "bug" in visual c++ as reported here
The solution is to add the following preprocessor definition:
/D__value=_value
The "not", "and", etc... are keywords in C++ (macros in C). Is there any way to "enable" them in Visual Studio 2013? I'm able to use the words as macroses with iso646.h included. But VS seems not be able to recognize them as keywords.
Using /Za seems to enable them without including iso646.h, see it live, the following program produces an error without using /Za but works fine otherwise:
int main()
{
int x = 1, y = 0 ;
if (x and y)
{
//...
}
return 0;
}
As ta.speot.is indicates /Za disables extensions, the following documentation indicates you must include ios646.h otherwise:
Under /Ze, you have to include iso646.h if you want to use text forms of the following operators:
and it lists the alternative tokens below.
Note, I knew I saw this before, I include a link to a bug report for this in my answer to a similar question. Although this does not include the workaround noted above.
Note 2: Cheers and hth. - Alf indicates that there may be many undesirable consequences to turning off extension and therefore you may be better off just including iso646.h.
Use a forced include (option /FI) of the iso646.h header.
For work in the command interpreter you can put this in your CL environment variable, or e.g. in a response file.
Turning off Visual C++ language extensions with /Za can also do the trick, at the cost of rendering the compiler pretty much useless – since Microsoft code such as the Windows API headers generally uses the extensions.
On a more recent version of VS (tested on Version 15.7.0 Preview 3.0); ensure that conformance mode is set for visual studio:
It then compiles with the alternative operator representations.
I am trying to build a DLL from source-code from the Crysis Wars SDK, and have successfully done so in the past on previous versions of Visual Studio (namely 2005, 2008, and 2010).
My specific problem is this:
Error 4 error LNK2019: unresolved external symbol "struct CTypeInfo const & __cdecl
TypeInfo<char>(char *)" (??$TypeInfo#D##YAABUCTypeInfo##PAD#Z) referenced in function
"void __cdecl SwapEndian<char>(char *,unsigned int)" (??$SwapEndian#D##YAXPADI#Z)
G:\Noctis\Mods\Noctis\Code\GameCVars.obj GameDll
I have attempted to clean the code in Visual Studio and rebuild it on the off-chance this'll work, but this has not changed anything.
Am I missing something here, or has something changed from C++03 to C++11 that means that this code is no longer compilable without reverting to an older version of C++?
I have successfully compiled this code on Visual Studio 2010 in both 64 bit and 32 bit, so it must be some issue related to migrating the project to Visual Studio 2015.
Compilation on 2012, 2013, and 2015 versions of Visual Studio reproduce this error but not 2010, so it seems that the change to trigger this problem was introduced in C++11.
What am I doing wrong?
Reading the answer to mem-fun is not a member of std, it could just be that I need to include a standard library that I didn't need to include in earlier versions of Visual Studio.
If this is true, which library would I need to #include?
I have also created a GitHub repository containing only the original unmodified code provided from the SDK, for testing purposes (in the event I myself made a typo, which doesn't seem to be the case here but I've put the link here as it may be helpful).
If it matters, I'm using Visual Studio 2015 Enterprise edition on Windows 10 Professional x64.
What does the error mean?
The error message hints towards a classic "declared but not defined" scenario.
TypeInfo<char>(char*) is declared in TypeInfo.h (through some macros) and declared in AutoTypeInfo.cpp in project CryCommon.
Usually you would just make sure the CryCommon project is built correctly and linked into your final GameDll project properly and that's it.
But it turns out here that the CryCommon project has not been built for a long time - it references many other Crytek libraries etc. So the problem must be that something now needs these TypeInfo<> definitions and previously it did not.
What is referencing the TypeInfo<> code?
In your project it's function CmdHelp() in Aurora/Code/GameCVars.cpp, precisely this line:
nRead = gEnv->pCryPak->FRead( buf, BUFSZ, f );
The implementation of the FRead() method is in CryCommon/ICryPak.h:
template<class T>
size_t FRead(T *data, size_t elems, FILE *handle, bool bSwap = true)
{
size_t count = FReadRaw(data, sizeof(T), elems, handle);
if (bSwap)
SwapEndian(data, count);
return count;
}
As you can see, if bSwap is true (the default), SwapEndian() is invoked there.
Why hasn't this manifested before?
Perhaps the compiler was indeed behaving differently.
Or, more likely, you have been always compiling the project as Release before. The whole byte-swapping functionality is enabled only on big-endian systems (and your target is most probably not one of those) or during debug - then the bytes are actually swapped twice to test the related code (see CryCommon/Endian.h).
What can be done to fix it?
You have several options now:
Keep compiling as release only (probably as before). Perhaps you will never be debugging the code in a debugger anyway.
Just comment the swap call in FRead() code out. You are using it to load a text file anyway, no point in swapping the characters around.
...
FWIW, other things I had to do to make your code compile:
Check out the earlier commit before "Broken"
Load Mods\Aurora\Code\Aurora.sln
Remove non-existing .vcprojx projects
Add all 3 .vcproj files again, let them be converted to VS2015 ones
For GameDll project, add preprocessor definition _SILENCE_STDEXT_HASH_DEPRECATION_WARNING
For GameDll project, set enabled C++ exception handling /EHsc
Comment out the code above