stoi() CodeBlocks not working - c++

I am using codeblocks and i can't make stoi() function work. I read other questions regarding this issue but I couldn't solve it. I checked C+11, I am using namespace std and I have the string header. I don't know how can I solve this problem.
error: 'stoi' was not declared in this scope

found the answer on almost the same question here:
"It seems your MinGW needs a patch: Enabling string conversion functions in MinGW"
From this link you can download a .zip, than follow the instructions.
This patch enables the following list of C++11 functions and
templates in the std namespace:
stoi, stol, stoul, stoll, stof, stod, stold, to_string, to_wstring
Attention, maybe you will haver errors with later versions, after using the copy/paste:
As Conduit said here:
"People should note that direct replacement of the files is not guaranteed to be safe on versions later than MinGW GCC 4.7 - use the pastebin snippets, open the files, and comment/add to the existing files. Applied as such, this still works fine on MinGW GCC 4.8.1 afai"

I would use atoi on the str.data() returned value, since it is supported in all compiler versions.

Use
#include <string>
That should work. For reference: C++11 standard plus minor editorial changes.
Or perhaps you are forgetting to prefix with std::?
A workaround is calling .c_str() and using the <cstdlib> or <stdlib.h> functions.

Related

How to make sure code (c++) written in Xcode can compile on other platforms?

I am a beginner was trying to do some C++ programming on Xcode. It works fine, but when I try to compile the same c++ file on my windows pc using VS, there were some errors. After I look at my code closely, there are really some stupid mistakes that I have made which caused the errors, but Xcode seemed to have ignored them...
My question is that is there any setting that I need to change to prevent Xcode from being so smart?
For example, the following code can actually compile in xcode:
#include <iostream>
using namespace std;
int main() {
if (true or false){
cout << "How is this possible? \n";
}
return 0;
}
There are also other cases where the code is actually wrong, but it can compile just fine is Xcode which is the annoying part and I want to disable that.
As far as I can see there is nothing wrong with your code.
The ISO C++ standard does not specify which standard headers are included by other standard headers. So, it is entirely possible that the version of iostream used by Xcode directly or indirectly includes ciso646. Whereas Visual Studio's version of iostream does not include ciso646. There are many similar cases with other headers. You just need to read the error messages and realize that your error (when you move your file to a different platform) is due to a missing header file.
It would be nice if writing portable code meant writing code in accordance with the C++ standard specification, but unfortunately that's not the case. Although there are various compiler options on various implementations which can help bring different implementations closer together, in general you will just have to bring the code into the target environment and actually test it there.
So ultimately writing portable code means you'll have to learn some subset of C++ that is accepted by all the implementations you want to target.
or is an 'alternative token' in C++, and VS is incorrect to reject it. There's no option in Xcode to disable support for alternative tokens. However VS has non-standard support for or as a macro using the header <ciso646>, and Xcode does have a header <ciso646> which does nothing (as the standard specifies). So you can write code which uses or and which works in both Xcode and VS by including this header.
#include <iostream>
#include <ciso646> // does nothing in Xcode, allows `or` in VS
using namespace std;
int main() {
if (true or false){
cout << "How is this possible? \n";
}
return 0;
}
Unfortunately VS can't support all of the alternative tokens through macros and so Xcode will still support some that VS doesn't.
There are also other cases where the code is actually wrong, but it can compile just fine is Xcode which is the annoying part and I want to disable that.
If you give specific examples then I can provide additional advice on how to write portable code.
Rather than changing your Xcode settings, I suggest cross-checking your code using another development environment.
If you're looking for something cheap and full-proof. Download a VirtualBox Windows VM, and run download Dev C++ (bloodhshed)
VS does not support or: you need to use || instead.
You can include some special files but it doesn't inject or sufficiently well into the language for it to work in all instances.
If you want to suppress use of or (and your compiler supports no better way)
#define it to something that emits a compiler error, for example
#define or OR
This at least means that the nature of the compilation errors will be identical on Xcode and VC.

Orwell Dev C++ doesn't work with C++11

I'm trying to use any of the C++11 features in Orwell Dev C++ but with no luck. I installed the version with minGW and whatever I set in the compiler options, I just get the "[Error] 'to_string' was not declared in this scope" in this code:
#include<iostream>
#include<string>
using namespace std;
int main()
{
string test = to_string(5);
}
I tried setting -std=gnu++11 and -std=c++0x but neither does the job. What's the most curious is that when I click on to_string, it shows me the overloaded functions - for long, float, int and so on. Thus, it must somehow get what the function does - how come it doesn't compile it, then? The compiler is set correctly to MinGW GCC 4.7.2 (the one bundled with the installer).
If you want to use C++11 in Dev-C++ you should to this steps:
Go to Tools > Compiler Options
Go to the tab Settings > Code Generation
Change the parameter Language Standard (-std) to ISO C++11
It is a known bug that to_string does not work with MinGW yet (which is actually GCC's fault, to a degree):
http://sourceforge.net/p/mingw/bugs/1578/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52015
Intellisense is often driven by a different engine than the compiler (as very few compilers have hooks to make intellisense easy), so that's likely why you're seeing it in your IDE when it's not supported by your compiler.

error: strstream.h: No such file or directory

I am trying to run an old C++ code in Linux (Redhat). I am using gcc version 4.1.2.
I got the following error:
error: strstream.h: No such file or directory
/trnuser1/rmtrain/DevelopmentEnv/Generic/CoreObjects/GCVTransformationServices.cpp:41: error: âostrstreamâ was not declared in this scope
/trnuser1/rmtrain/DevelopmentEnv/Generic/CoreObjects/GCVTransformationServices.cpp:41: error: expected `;' before âstrDestXMLâ
/trnuser1/rmtrain/DevelopmentEnv/Generic/CoreObjects/GCVTransformationServices.cpp:62: error: âstrDestXMLâ was not declared in this scope
This code was running fine under Solaris with gcc version 2.95. The line pointed to by the error contains the following statement:
ostrstream strDestXML;
How do I solve this?
You can #include <strstream> (note absence of the '.h' suffix).
But if you want to properly port the code to modern C++, you should consider changing this to #include <sstream> and std::ostringstream strDestXML; as suggested in the comment.
Standard C++ headers do not have extension.
#include <sstream>
Standard classes are contained in std namespace:
std::ostringstream strDestXML;
Finally, strstream is deprecated; use stringstream instead - that's why I used it here.
And, just a note about GCC version - 4.1.2 is old, no matter what - use something newer.
The modern name for this include is <strstream>. (Although it's formally deprecated, it's still required.) The classes it defines are in namespace std, and have slightly different semantics than the classical iostream, so you may have to do a little bit of modification later anyway. (Depending on how it is being used, it might make sense to change to <sstream>, replacing [io]strstream with std::[io]stringstream.)

How to get headers for unordered_set in gcc v4.1.2?

I'd like to use unordered_set without installing Boost. I tried to add --std=gnu++0x but it is not a recognized option. Does v4.1.2 include unordered_set? If so, how do I get the header file for it?
This is a Centos 4 machine.
unordered_set is in the purview of the standard C++ library, not gcc, the compiler (although most programs built using gcc are linked against libstdc++).
The way you generally include it is #include <tr1/unordered_set>. Then, to use it, you must either do a using std::tr1::unordered_set; or qualify the name each time.
The C++ standard version you choose to use doesn't have much effect because that's the language standard, and the availability of standard library constructs is semi-independent.
IIRC, gcc-4.2 did not have unordered containers at least not in namespace std. I know -std=c++0x was not in place till around gcc-4.3.
Have you tried this:
#include <tr1/unordered_set>
...
std::tr1::unordered_set<int> usint;
...
Notice the tr1/ in the header.
Having said that, gcc-4.1 is pretty old. Any chance you could try say gcc-4.5 or 4.6 and use the std container?

How can I make Keil RealView ARM MDK (for Cortex-M3) work with BOTH retargeting(to USART) and STL?

I've been searching for a workaround for days. So far no luck.
What I use:
STM32F103VET6
J-Link
RealView MDK-ARM v4.12
Both C and C++ code in my program
Before I included STL in my code, everything works fine. I can retarget printf() and scanf() to USART without a problem. This is done by including Retarget.c that came with RV-MDK and writing my own sendchar() and getkey(). Retarget.c has a line that says #pragma import(__use_no_semihosting_swi) which demands the linker to use the retargeting version of <cstdio>, instead invoking the semihosting implementation.
But when I started to #include <deque> and deque<int> buffer;, it doesn't work anymore. It seems that the linker had decided that <deque> depends on the the semihosting <cstdio>, which conflicts with the retargeting code I wrote just now.
What I tried and failed:
Get rid of __no_semihosting_swi and instead try to override _sys_open(). It doesn't work because the semihosting <cstdio> depends on an object file which already exports this symbol.
Use $super$$ and $sub$$ syntax suggested here (I think I've tried everything they provided!)
Use "MicroLIB". It's EPIC FAIL.
Digging into the supplied STL headers. I found NO reference to any stdio. And, since I can #include <cstdio> and still have retargeting, I don't think even an reference would make any difference.
I suspect the solution has something to do with directing the linker, but so far I haven't figured out... This is getting so frustrating!