I'm writing a stack class in C++ for an Arduino sketch. I believe it is fully compliant with the AVR (if that's what it's called; I can't remember exactly) compiler; I've used all malloc and free instead of new and delete and so on.
So I have a .h file with my class. I've imported it into the sketch, but when I try to compile, I get these errors:
In file included from sketch_may15a.cpp:1:
/CStack.h:58:18: error: string: No such file or directory
In file included from sketch_may15a.cpp:1:
CStack.h:61: error: variable or field 'Error' declared void
CStack.h:61: error: 'string' was not declared in this scope
And here are the first few lines for my class:
#include <string>
using namespace std;
void Error(string message) {
So the Arduino compiler can't find <string>, and the next few problems seem to relate to it (not sure what variable or field Error declared void means, my error function is just for debugging purposes).
I know Arduino sketches support strings without need for an import, but I'm not sure how that works out with C/C++/.h files. I've tried googling it, but there isn't much documentation.
Arduino sketches don't support any of the C++ standard library as they are compiled using avr-libc which doesn't support it. However, Arduino does provide the String class which should do what you need.
If you are writing a library you'll also need to #include <Arduino.h> (or #include <Wiring.h> if you are using a pre-1.0 version of the Arduino IDE).
Using String class in microprocessors is advised against due to heap fragmentation and other problems
The new SafeString library (available from the library manager) solves all those problems and is completely safe and will never cause your sketch to reboot.
see the detailed tutorial at
https://www.forward.com.au/pfod/ArduinoProgramming/SafeString/index.html
Related
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.
I've recently started diving into the code of an open source project, which is largely written in C++. I'm using Eclipse 3.8 in Ubuntu 12.10.
THE PROBLEM:
Eclipses is incorrectly flagging fields as unresolved because of a particularly elaborate convention used to separate field declarations out of the header files.
someclass.h
class SomeClass
{
public:
#define MACRO_CLASS_PARAM(Name) SomeType m_##Name;
#include "fields.h"
#undef MACRO_CLASS_PARAM
};
fields.h
MACRO_CLASS_PARAM(Field1)
MACRO_CLASS_PARAM(Field2)
...
Now in the cpp file, if I want to do something like instanceOfSomeClass.Field1 Eclipse will flag it as an error with "Field 'Field1' could not be resolved".
THE QUESTION: Is there any way to get Eclipse to correctly handle this situation?
The inability to correctly process #include statements that are not at global scope is a long-standing deficiency in Eclipse's indexer.
Things you could do about it:
Revise your code to avoid this pattern. Once the textual header inclusion model is superseded by C++ Modules, it's going to be invalid anyways.
Contribute a fix for this deficiency to Eclipse CDT.
Use a different IDE that can parse this pattern. (I don't know of one off the top of my head, but I also haven't spent a lot of time looking.)
What is the simplest to use c++ library that graphs functions like matlab and octave do? I have looked over several and have found similar major problems with all of them: i cannot compile an empty program that only has
#include <iostream>
#include "header_to_include.h"
int main(){
return 0;
}
i have found koolplot, some wxwidget stuff, sdl_graph, gnuplot++, and something with Qt. ive looked at some of the ones on the list here, but some are for other languages while others use installers or depended on other programs. When I got files extracted and tried compiling my simple code or given example code from within the download, codeblocks always complains about missing headers or variables or some other things.
i would use gnuplot, except i dont want to create gnuplot files from my cpp files, even if its through a pipe. i want to be able to graph straight from the program.
is there nothing that is simply a handful of files in a zip that can be extracted and used in moments rather than having to figure out which files to include, installing/downloading other major libraries, etc?
edit:
for example, i found http://sdl-grapher.googlecode.com/svn/trunk/ and downloaded the files. i already have sdl, so i copied sdlgraph.h into the includes folder and left a copy in the same directory as example.c. when i compile, i find that for some reason, #include <sdlgraph.h> doesnt work. also the int main() has no arguments despite being a SDL program. after fixing that up, i get undefined reference to 15 different functions that i can clearly see in the sdlgraph.h file such as init_graph and draw_grid
About your errors:
Since you're very new to C++ I'll explain your undefined reference errors.
In C++ you can declare a function like this:
void foo();
However, since it's declared, it doesn't main it's defined. Definitions can exist in C++ source file, libraries but also headers.
Defining the previous example:
void foo() {
std::cout << "void foo() has been called." << std::endl;
}
The error you get means that those functions just aren't defined.
I quess you have to link your application with the SDL libraries.
For more info see:
http://content.gpwiki.org/index.php/SDL:Tutorials:Setup
For more info about dynamic and static linking see:
http://www.learncpp.com/cpp-tutorial/a1-static-and-dynamic-libraries/
Hope it helps!
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!
I am currently writing a CUDA application and want to use the boost::program_options library to get the required parameters and user input.
The trouble I am having is that NVCC cannot handle compiling the boost file any.hpp giving errors such as
1>C:\boost_1_47_0\boost/any.hpp(68): error C3857: 'boost::any': multiple template parameter lists are not allowed
I searched online and found it is because NVCC cannot handle the certain constructs used in the boost code but that NVCC should delegate compilation of host code to the C++ compiler. In my case I am using Visual Studio 2010 so host code should be passed to cl.
Since NVCC seemed to be getting confused I even wrote a simple wrapper around the boost stuff and stuck it in a separate .cpp (instead of .cu) file but I am still getting build errors. Weirdly the error is thrown upon compiling my main.cu instead of the wrapper.cpp but still is caused by boost even though main.cu doesn't include any boost code.
Does anybody know of a solution or even workaround for this problem?
Dan, I have written a CUDA code using boost::program_options in the past, and looked back to it to see how I dealt with your problem. There are certainly some quirks in the nvcc compile chain. I believe you can generally deal with this if you've decomposed your classes appropriately, and realize that often NVCC can't handle C++ code/headers, but your C++ compiler can handle the CUDA-related headers just fine.
I essentially have main.cpp which includes my program_options header, and the parsing stuff dictating what to do with the options. The program_options header then includes the CUDA-related headers/class prototypes. The important part (as I think you've seen) is to just not have the CUDA code and accompanying headers include that options header. Pass your objects to an options function and have that fill in relevant info. Something like an ugly version of a Strategy Pattern. Concatenated:
main.cpp:
#include "myprogramoptionsparser.hpp"
(...)
CudaObject* MyCudaObj = new CudaObject;
GetCommandLineOptions(argc,argv,MyCudaObj);
myprogramoptionsparser.hpp:
#include <boost/program_options.hpp>
#include "CudaObject.hpp"
void GetCommandLineOptions(int argc,char **argv,CudaObject* obj){
(do stuff to cuda object) }
CudaObject.hpp:
(do not include myprogramoptionsparser.hpp)
CudaObject.cu:
#include "CudaObject.hpp"
It can be a bit annoying, but the nvcc compiler seems to be getting better at handling more C++ code. This has worked fine for me in VC2008/2010, and linux/g++.
You have to split the code in two parts:
the kernel have to be compiled by nvcc
the program that invokes the kernel has to be compiled by g++.
Then link the two objects together and everything should be working.
nvcc is required only to compile the CUDA kernel code.
Thanks to #ronag's comment I realised I was still (indirectly) including boost/program_options.hpp indirectly in my header since I had some member variables in my wrapper class definition which needed it.
To get around this I moved these variables outside the class and thus could move them outside the class defintion and into the .cpp file. They are no longer member variables and now global inside wrapper.cpp
This seems to work but it is ugly and I have the feeling nvcc should handle this gracefully; if anybody else has a proper solution please still post it :)
Another option is to wrap cpp only code in
#ifndef __CUDACC__