Error with Lambda Expression C++ in VS Code - c++

I'm trying to sort an array m of class measure using a lambda expression as follows:
#include <iostream>
#include <vector>
#include <string>
#include <algorithm>
#include <math.h>
using namespace std;
struct measure{
int day;
int cow;
int change;
};
int main()
{
int N;
cin >> N;
measure m[N];
for (int i = 0; i < N; i++){
measure m_i;
cin >> m_i.day >> m_i.cow >> m_i.change;
m[i] = m_i;
}
sort(m, m + N, [](measure a, measure b) {return a.day < b.day;});
}
However, an error occurs when trying to build the task in VS Code (using C++17):
error: expected expression
sort(m, m + N, [](measure a, measure b) {return a.day < b.day;});
^
1 error generated.
Build finished with error(s).
I've tested this code on other compilers with no difficulties. Why is this error happening on VS Code?

Okay, so it does not look like you are compiling with c++17. I can reproduce this error if I roll back the gcc version to 4.x and leave the standard up to the compiler. Here is how it would look on an older compiler. Here is how it would run properly on a newer compiler. Most likely that you are using something like c++98 or c++03.
Note - I have taken the liberty of modifying your code to make it more C++. Also, please stop with using namespace std.
A simple fix is to just make sure that you are using the right version of the compiler basis the features you need. Lambdas in C++ were introduced in C++11, so clearly you are using a compiler that is at a much lower version.
VS Code does not have a compiler built-in. It uses the system compiler you have installed. You can configure things to use the system compiler and pass the flag --std=c++17 to the compiler command line.
Both gcc and clang++ support this command line flag.

Related

How to compile generator and coroutine using c++2a on Mac

I am setting up my MacBook for C++20 and having problem to compile the code. I have installed latest Xcode, llvm and gcc. Here is the code that I am trying to compile
#include <chrono>
#include <experimental/coroutine>
#include <future>
#include <iostream>
using namespace std;
generator<int> getInts(int first, int last) {
for (auto i = first; i <= last; ++i) {
co_yield i;
}
}
int main() {
for (auto i : getInts(5, 10)) {
std::cout << i << " ";
}
}
however I am getting following error:
$ g++ gen.cpp -std=c++2a
In file included from gen.cpp:2:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/experimental/coroutine:66:5: warning:
<experimental/coroutine> cannot be used with this compiler [-W#warnings]
# warning <experimental/coroutine> cannot be used with this compiler
^
appreciate any insight how to resolve this compile issue.
The Coroutines TS has not been voted into C++20 (indeed, there have been three separate votes, with approval not achieving consensus in all of them), so even if GCC implemented it (which it doesn't), it wouldn't be activated by the -std=c++2a switch.
Now, Clang does implement the Coroutines TS, which you have to turn on with -fcoroutines-ts. And apparently, you have to be using libc++.

(Software issue) Can anyone suggest a download that will definitely bring my Mingw32 compiler up to speed?

#include <iostream>
#include <string>
using namespace std;
int main(){
string s = "wassup", newVal = "though";
cout << *(s.insert(s.begin(), newVal.begin(), newVal.end()));
}
This brings up the problem that the return type of string's insert member function is void (error: void value not ignored as it ought to be). This link indicates C++98 returns void but the "new" standard C++11 does indeed return an iterator.
A bit of context, I actually faced this problem earlier. I was/am using CodeBlocks (GCC Compiler Collection) on Windows 7 64-bit and this program gave the same issue (dereferencing void):
#include <iostream>
#include <list>
int main(){
list<int> x = {1,2,3,4};
*(x.insert(++x.begin(), 3, 2));
for(auto c : x)
cout << c;
}
I posted my issue on a different forum and a user pointed out Mingw32 was missing that particular C++11 change, indicating Mingw-w64 does not have this issue. So I went straight to installing Mingw-w64 on Code::Blocks using this guide and the problem was resolved. It's only now I've found out that the overloaded function which takes three iterator parameters STILL returns void.
I'm a little confused as to why Code::Blocks Mingw32 didn't supply a fully updated C++11 standard. Can anyone suggest a download that will definitely bring my compiler up to speed?

Parsing int in C++11 - stoi

I am trying to take a string and parse it into an int. I have read the many answers out there, and it seems that using stoi is the most up-to-date way. It appears to me that stoi uses std, but I am getting Function 'stoi' could not be resolved despitre using namespace std;
#include <iostream>
#include <string>
#include <cstring>
#include <fstream>
#include<stdlib.h>
using namespace std;
int main(int argc, char* argv[]) {
string line = "";
string five = "5";
int number = stoi(five); //Error here with stoi
return 0;
}
Any ideas what is causing this?
Update:
I am using Eclipse. My flags are: -c -fmessage-length=0 -std=c++11
If you are using GCC or MINGW, then this is the answer:
std::stoi doesn't exist in g++ 4.6.1 on MinGW
This is a result of a non-standard declaration of vswprintf on
Windows. The GNU Standard Library defines
_GLIBCXX_HAVE_BROKEN_VSWPRINTF on this platform, which in turn disables the conversion functions you're attempting to use. You can
read more about this issue and macro here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522.
If you're willing to modify the header files distributed with MinGW,
you may be able to work around this by removing the
!defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF) macro on line 2754 of
.../lib/gcc/mingw32/4.6.1/include/c++/bits/basic_string.h, and adding
it back around lines 2905 to 2965 (the lines that reference
std::vswprintf). You won't be able to use the std::to_wstring
functions, but many of the other conversion functions should be
available.
Please always provide platform and compiler information.
Toggle on C++11 support in your compiler flags. -std=c++11 for a recent gcc. For Eclipse, please refer to the corresponding question in the FAQ and this answer explains how to get rid of the remaining Eclipse warning.
If you are amenable to parsing an int another way, how about using an STL algorithm and a C++11 lambda expression?
#include <algorithm>
#include <iostream>
#include <string>
using namespace std;
int main() {
string str = "12345";
int num = 0;
for_each(str.begin(), str.end(), [&num](char c){ num = 10 * num + (c - '0'); });
cout << str << " = " << num << endl;
}

Why a variable length array compiles in this c++ program?

It is said that arrays are allocated at compile time, then the size must be const and available at compile time.
But the following example also works, Why?
#include <iostream>
#include <vector>
using namespace::std;
int main()
{
vector<int> ivec;
int k;
while(cin>>k)
ivec.push_back(k);
int iarr[ivec.size()];
for (size_t k=0;k<ivec.size();k++)
{
iarr[k]=ivec[k];
cout<<iarr[k]<<endl;
}
return 0;
}
Compile your code with -pedantic.
Most compilers support variable length arrays through compiler extensions.
The code works due to the compiler extensions, However as you noted the code is non standard conforming and hence non portable.

Why do statements after return change the return value?

C++ returns invalid value in the following code:
#include <iostream>
#include <vector>
using namespace std;
int f(){
vector< int * > v[2];
return 1;
v[1].push_back(NULL);
}
int main(){
cout << f();
}
The output is:
205960
When I commnet line after return, it works fine:
#include <iostream>
#include <vector>
using namespace std;
int f(){
vector< int * > v[2];
return 1;
//v[1].push_back(NULL);
}
int main(){
cout << f();
}
The output is:
1
I am using code::blocks with mingw32-g++.exe compiler. The mingw version is: gcc version 4.4.1 (TDM-2 mingw32).
Your compiler has a bug. Fortunately, it is also obsolete. You should upgrade — G++ is up to version 4.6.2, which also implements much of C++11, which is very useful.
If you choose to stick with an older compiler, that is also a decision to accept its flaws.
Edit: If you are really stuck with 4.4 (for example due to a PHB), that series is still maintained. You can upgrade to GCC 4.4.6, released just this past April.