C++ Directly calling a vector element's function (Eclipse CDT bug?) - c++

I'm getting a weird error when trying to call a vector element's function. For example, if I do this
However it works fine if I do this:
The code runs fine in Visual Studio, so is this a bug with Eclipse CDT?
P.S. ignore the endl bug
EDIT:
Compiler error from Visual C++
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\Include\vector(1494) : error C2528: '_Ptr' : pointer to reference is illegal
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\Include\vector(1658) : error C2528: '_Pval' : pointer to reference is illegal
Compiler error from MinGW
c:\mingw\lib\gcc\mingw32\4.8.1\include\c++\bits\stl_vector.h:87:68: error: using invalid field 'std::_Vector_base<_Tp, _Alloc>::_Vector_impl::_M_finish'
c:\mingw\lib\gcc\mingw32\4.8.1\include\c++\bits\stl_vector.h:87:68: error: using invalid field 'std::_Vector_base<_Tp, _Alloc>::_Vector_impl::_M_end_of_storage'
Note that it compiles fine in Visual Studio
EDIT 2:
ok so...now it works for some reason. Yes I was wrong for choosing the back() method as an example, because it was failing for any method I tried. But for some reason, after a couple days of this problem, Eclipse fixed itself, and now the only error message I get from this code is
..\src\main.cpp:48:21: error: 'class std::basic_string<char>' has no member named 'back'
I wouldn't be surprised if the issue came back though, but I guess it really is a problem with Eclipse, either with the IDE itself or with my environment/linker settings

It appears that std::basic_string::back is new in C++11. So unless you compile in C++11 mode (using -std=c++11 for gcc, for example), it's not going to compile. Here's the complete test code I used:
#include <iostream>
#include <string>
#include <vector>
int main() {
std::vector<std::string> strings;
strings.push_back("test");
std::cout << strings[0].back() << '\n';
}
So, you'd have to configure your Eclipse to use C++11 mode, also.

Related

Unable to compile example boost::multiprecision with intel compiler on windows

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.

Why visual studio needs <string> to compile, but codeblocks doesnt?

Basically, the program is compiling on codeblocks, but not on visual studio 2015 unless I add
#include <string>
to one of the files, then I get about errors from the first line of the code
1>------ Build started: Project: ConsoleApplication2, Configuration: Release Win32 ------
1> pytanie.cpp
1>pytanie.cpp(25): error C3861: 'getline': identifier not found
1>pytanie.cpp(42): error C2679: binary '<<': no operator found which takes a
right-hand operand of type 'std::string' (or there is no acceptable
conversion)
and about 200 lines of this stuff
'std::basic_ostream<char,std::char_traits<char>>
&std::basic_ostream<char,std::char_traits<char>>::operator <<(const void *)'
So the question is, why codeblocks can compile and run this program, but visual studio needs
#include <string>
I found out - thanks to this forum - that using getline and << operator requires including the 'include string' line, but why can codeblocks work without it, or why visual studio 2015 CAN'T?
edit: yes, codeblock is using GNU GCC compiler and VS2015 is using default one
Any standard header file is allowed, but not required, to include any other.
So on one compiler one of the headers you're including does include <string>, and on the other compiler none of them do.
This is generally tricky (by which I mean it's extremely hard to get right, even for experts), but for portability I'm afraid you need to know which headers include the declarations you use, and make sure you include all of them.

Visual C++ syntax error for pointer reference initialization

Why does Visual C++ 2008 give a syntax error for the following code?
int* x;
int*& xalias(x); //error C2061: syntax error : identifier 'x'
Is this simply a bug? (gcc and clang accept this...)
Do later versions of Visual Studio fix this, or should I just work around this as below?
int*& xalias = x;
Your workaround is fine, and yes it is a bug in Microsoft's C++ compiler. Here is the bug report submitted to Microsoft. They don't appear in a hurry to fix it as there is a trivial work around, as you found yourself.

Unable to compile CUDA C sources. Simple version is provided

Here is the problem...
For school project I need to write parallel application using CUDA C. Even the most simple example will not compile. I'm using Windows7 and MS visual studio. The code is taken from the book: CUDA by example. An introduction to general purpose GPU computing.
#include<iostream>
#include<cuda.h>
using namespace std;
__global__ void kernel(void){
}
int main(){
kernel<<<1, 1>>>();
cout << "Hello world" << endl;
return 0;
}
Here are the errors:
1>c:\users\administrator\documents\visualstudio2010\projects\test\test\test.cpp(6): error C2144: syntax error : 'void' should be preceded by ';'
1>c:\users\administrator\documents\visualstudio2010\projects\test\test\test.cpp(6): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>c:\users\administrator\documents\visualstudio2010\projects\test\test\test.cpp(10): error C2059: syntax error : '<'
Do I need to set nvcc.exe as default compiler instead of cl.exe? If that is the case, how to do it?
Any help is much appreciated!
CUDA code needs to be written in a .cu file and compiled with the NVCC compiler. You are seeing the above errors because you have written your code in a .c or .cpp file and are trying to compile it with a C++ compiler (the Visual C++ compiler).
You have chosen the right book to learn CUDA from. However, you are not following all the steps given in the book. Please have a look at the details of compilation in the book :-)

Very Mysterious/Random C++ WDK STL 7 Error: iosfwd(202): error C2144: syntax error

I have the following trivial file named Temp.cpp:
#include <string>
int main() { return 0; }
and I'm trying to compile it with the following command-line in the Windows XP Free Build Environment, using WDK 7.1:
cl.exe /Iinc\api\crt\stl70 /Iinc\crt C:\Temp.cpp
and I'm getting really random errors like:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.207 for 80x86
C:\WinDDK\7600.16385.1\inc\api\crt\stl70\iosfwd(202) :
error C2144: syntax error : 'int' should be preceded by ';'
The error goes away if I use stl60 instead of stl70, but that doesn't solve the problem.
What's the cause of the problem?
Update: I tried uninstalling and installing the WDK again, but nothing changed. :(
Update 2: Okay, apparently the error is screaming out at the header file itself: _SCL_INSECURE_DEPRECATE is the cause. Does anybody know how to turn it off correctly? (If I just comment out the lines, I get a ton more errors regarding a bunch of other macros.)
Found the answer myself, through modifying the headers and guess'n'checking:
I need to have _STL70_ defined.
Which cl.exe are you picking up? If your path happens to have an older (VC6) compiler before the WDK one, you'd expect these errors. VC6 can't compile the STL as shipped with VC7
apparently the error is screaming out at the header file itself: _SCL_INSECURE_DEPRECATE is the cause. Does anybody know how to turn it off correctly?
If you're having problems with _SCL_INSECURE_DEPRECATE, try setting:
/D_SCL_SECURE_NO_DEPRECATE
But given the error message you're seeing it sounds like you're the compiling headers with a a compiler that's older than the headers support (so this might not get you very far anyway).