I am following the quickstart guide for boost::spirit, and I get this compiler warning when I include : "This header is deprecated. Please use: boost/spirit/include/classic_core.hpp" Should I be worried about this?
(quick start guide: http://spirit.sourceforge.net/distrib/spirit_1_8_5/libs/spirit/doc/quick_start.html , with full source of the program I am trying to compile here: http://spirit.sourceforge.net/distrib/spirit_1_8_5/libs/spirit/example/fundamental/number_list.cpp)
edit: Additionally, when I try to compile with the recommended classic_core.hpp and classic_push_back_actor.hpp headers, I get the following compiler errors:
test7.cpp: In function 'bool parse_numbers(const char*, __gnu_debug_def::vector<double, std::allocator<double> >&)':
test7.cpp:18: error: 'real_p' was not declared in this scope
test7.cpp:18: error: 'push_back_a' was not declared in this scope
test7.cpp:23: error: 'space_p' was not declared in this scope
test7.cpp:23: error: 'parse' was not declared in this scope
[EDIT:] The original answer is badly out of date; in particular the link is broken. The current version of Boost (since 2012-02-24) is 1.49.0.
The warning mentioned is a result of #include <boost/spirit.hpp> which is a deprecated header; however old examples on the web use this form. To get started, try the boost tutorials. Once you see the correct includes and namespaces, most old examples can easily be converted.
[OLD ANSWER:]
You must be using boost 1.39 or later (via SVN). This presentation should help:
http://www.boostcon.com/site-media/var/sphene/sphwiki/attachment/2009/05/07/SpiritV2.pdf
In short, there's a brand new way of doing thing and these are the namespaces to use:
boost::spirit:qi (for the parser)
boost::spirit::karma (for the generator lib)
The official release is 1.40 so probably by that time the doc will be updated.
EDIT: the doc in the boost SVN repository is being worked on and probably reflect the new architecture in a more faithful manner.
When you're including the classic headers the parsers are in the boost::spirit::classic namespace. Try:
using namespace boost::spirit::classic;
When a library indicates that a class/header/method/etc. is deprecated, it means that the maintainer of the library will most likely stop maintaining the functionality, and may remove it in the future. I would recommend to switch to the suggested header sooner than later, so save yourself from headaches in the future.
The new header may have a slightly different way of handling the feature, so you may need to make some code changes.
(I don't know much about boost, this is just a general comment)
Related
I would like to use different libraries in my fortran code (I am using intel fortran compiler as well) depending on which version of MKL is available at compile time. There is a file interface included with an install of MKL which defines preprocessor macros for version numbers and build date - /opt/intel/mkl/include/mkl.fi
I thought the flow would be as follows:
Get version number of MKL from file interface mentioned above
Use the version number to decide which library to use via preprocessor directives
execute use statement to compile with correct library
If I place any use statements after an include statement, however, the compilation aborts after throwing error #6278: This USE statement is not positioned correctly within the scoping unit.
Is there any way to achieve conditional selection of use statements using preprocessor directives which rely on information from a file interface or header file?
I cannot see how it is possible, because any use statements have to be before the include statement which provides the data required to decide which use statement to execute. I have included below a sample which demonstrates what I'm trying to do, but will not work·
module MKLVersion
!Test for definition and value up here
#ifdef INTEL_MKL_VERSION
#if INTEL_MKL_VERSION >= 110200
use LAPACK95, only : ggevx, geevx, sygvd
#elif INTEL_MKL_VERSION < 110200
use MKL95_LAPACK, only : ggevx, geevx, sygvd
#endif
#endif
! but dont actually get the definition till we get here
include '/opt/intel/mkl/include/mkl.fi'
end module MKLVersion
The short answer to this question is, ultimately, no - as Steve Lionel pointed out, the included file had INTERFACE statements, which cannot come before a USE statement.
However, I found a solution for my particular use case, which enables compilation of code with both old and new MKL versions. According to this intel article from 2009, there is a way to call libraries which will work with older version of MKL:
Notes:
* f95_precision.mod, mkl95_lapack.mod and mkl95_precision.mod files will be removed in one of the future releases. The current version supports two USE statements - so you can choose or "USE MKL95_LAPACK" or " USE LAPACK95 ". For the future compatibility we recommend using "USE LAPACK95" statement.
So USE MKL95_LAPACK can be replaced with USE LAPACK95 without breaking everything, which is good.
I am doing some arduino development using cpp and h files and I am having some troubles using string with them. Currently I have
#include <string>
at the top of both the cpp and the h file. When I do that it gives me the error:
string: no such file or directory
If I go into the h file and change it to
#include <string.h>
then it gives me the error:
std::string has not been declared
Anytime I use the string I use: std::string to declare it. I am not using namespace std and these files were working together fine before I started to try to use string. I am new to C/C++ so I appreciate any help. Thanks!
In short, there is a way to use std::string with the Arduino.
TL;DR:
link to the arduino STLv1.1.2
NOTE
Please note that currently the harrdwareserialstream class provided by this STL should be considered broken (as per my testing, with version 1.6.5 of the IDE, and possibly anything after 1.0.6). therefore, you can't use
hardwareserialstream << "Hi there person number " << (int)i
and so on. it seems to no longer work due to taking a reference to the serial port it would interact with rather than a pointer - in short, continue using
Serial.print("Hi there person number");
Serial.print((int)i);
Lastly the serial classes don't know what a std::string is, so if using them, give it std::string.c_str() instead
Background
As McEricSir says in the comments, the arduino does provide its own string class, though i have found it to have problems related to memory leakage, which eventually ate all of the memory i had and the program stopped running - though this was in the arduino IDE v 1.0.5, it may have been fixed since then.
I had the same problem, and found someone who had created a version of the STL for the arduino (props to Andy Brown for this) which is a cutdown version of the SGI STL. it provides std::string, std::vector and a large amount of the STL to the arduino.
there are some things to be aware when using it though; if you have a board with very little memory, you will fill it quite quickly using the smart containers and other advanced features.
Using the Library
To use the library, you'll need to read the article, though I'll summarise the main points for you here:
Installation
simply extract the library to (assuming you are using the standard Arduino IDE) hardware\tools\avr\avr\include folder and you are good to go.
Using It
To actually use the new libraries, you need to include 2 additional things as well as the library you wanted.
firstly, you need to include the header iterator BEFORE any libraries that come from this STL - and in every file you reference the STL in.
Secondly, you also need to include the file pnew.cpp to provide an implementation of the new operator for the STL to work with.
Lastly, include any header files as you would normally.
to make use of the types gained from them, don't forget the the std:: namespace notation for them. (std::string and so on)
Bugs with it
Since Andy posted the library, there have been two bugs (that i'm aware of).
The first one Andy himself rectifies and explain in the blog post:
The compiler will spit out a typically cryptic succession of template errors, with the key error being this one:
dependent-name std::basic_string::size_type is parsed as a non-type,
but instantiation yields a type c:/program files (x86)/arduino-1.0/
hardware/tools/avr/lib/gcc/../../avr/include/string:1106: note:
say typename std::basic_string::size_type if a type is meant
Basically the STL was written a long time ago when C++ compilers were a little more forgiving around dependent types inherited from templates. These days they are rightly more strict and you are forced to explicitly say that you mean a type using the typename keyword.
Additionally, he provides the updated version for you to grab.
Lastly, there are reports in the comments about a bug in the newer versions of the IDE pertaining to the vector class where the compiler complains about the use of _M_deallocate without a prepending this->, which you can fix if you search for them inside the vector class
For your convenience
As i use this quite frequently, i've packaged up the current version, which can be found here (this includes both the fixes i have commented on)
Lastly
When using this, make sure to keep an eye on your free memory, and to that end i recommend the excellent class MemoryFree Library found here
on a side note if you #include<string> inside the header you won't need to include it in the relevant .cpp file
What strategies are there for deprecating functions when their return type needs to change? For example, I have:
BadObject foo(int); // Old function: BadObject is being removed.
Object foo(int); // New function.
Object and BadObject are very different internally, and swapping their return types will break code for current users of my library. I'm aiming to avoid that.
I can mark BadObject foo(int) deprecated, and give users time to change affected code.
However, I can't overload foo based on return-type. foo is very well named, and it doesn't need to take extra parameters. How can I add the new function to my library whilst maintaining the old version, at least for a while?
What's the strategy to deprecate the old function without breaking too much dependant code, while providing users the time to migrate to the new version? Ideally I'd keep the current function name and parameter list, because it's named quite well now. It feels like this should be a reasonably common problem: what's a decent way to solve it?
Although the solution will force you to change your function names, but it'll be a compromise between your old users and your new ones.
So - rename the old foo into deprecatedFoo and your new foo into foo2 (or anything you want). Then, in the header file you include with your library, you can simply:
#define deprecatedFoo foo
and inside the function itself do:
#warning ("This function is deprecated. Use 'foo2' or change the #define in LINE in file HEADER.")
Users of the old versions won't have to change their code, and will be issued a warning, and the new users will probably listen and change the #define in order to use the new foo.
In the next version you'll just delete the old foo and the define.
I think a classic example is Boost's Spirit.
From their FAQ:
While introducing Spirit V2 we restructured the directory structure in
order to accommodate two versions at the same time. All of
Spirit.Classic now lives in the directory
boost/spirit/home/classic
where the directories above contain forwarding headers to the new
location allowing to maintain application compatibility. The
forwarding headers issue a warning (starting with Boost V1.38) telling
the user to change their include paths. Please expect the above
directories/forwarding headers to go away soon.
This explains the need for the directory
boost/spirit/include
which contains forwarding headers as well. But this time the headers
won't go away. We encourage application writers to use only the
includes contained in this directory. This allows us to restructure
the directories underneath if needed without worrying application
compatibility. Please use those files in your application only. If it
turns out that some forwarding file is missing, please report this as
a bug.
You can ease migration by keeping the new and old versions in separate directories and using forwarding headers to maintain compatibility. Users will eventually be forced to use the new headers.
SDL 2.0 has a different approach. They don't provide a compatibility layer but instead a migration guide walking the users through the most dramatic changes. In this case, you can help users understand how they need to restructure their code.
What if to make your Object class inherit from BadObject (which you'll keep temporarily)? Then the old user code won't know about that, so it won't break provided that your new "foo" function still returns your objects correctly.
We have a fairly large C++ project which I am now in the process of moving to VS2010 and also updating a few libs along the way. So far everything builds just fine now, except I get (to me) quite weird errors where apparently a number of (edit: non-)standard C functions and symbols are not defined:
error C2039: 'strdup' : is not a member of '`global namespace'' ...\ACE_wrappers\ace\OS_NS_string.inl 222
...
error C2065: 'O_WRONLY' : undeclared identifier ...\ACE_wrappers\ace\OS_NS_unistd.inl 1057
...
This affects the following functions and symbols for me:
strdup getcwd O_WRONLY
putenv swab O_TRUNC
access unlink S_IFDIR
chdir mkdir S_IFREG
rmdir tempnam O_RDONLY
isascii
One part in the include file from ACE I experimented with was the strdup part which looks like this:
ACE_INLINE char *
ACE_OS::strdup (const char *s)
{
# if (defined (ACE_LACKS_STRDUP) && !defined(ACE_STRDUP_EQUIVALENT)) \
|| defined (ACE_HAS_STRDUP_EMULATION)
return ACE_OS::strdup_emulation (s);
# elif defined (ACE_STRDUP_EQUIVALENT)
return ACE_STRDUP_EQUIVALENT (s);
# elif defined (ACE_HAS_NONCONST_STRDUP)
return ::strdup (const_cast<char *> (s));
#else
return ::strdup (s);
# endif /* (ACE_LACKS_STRDUP && !ACE_STRDUP_EQUIVALENT) || ... */
}
There are loads of similar sections for other functions above and below, all of which compile just fine.
The path taken in my case is the last one, i.e. return ::strdup (s);. If I hit F12 on the ::strdup VS takes me to the declaration in string.h of the C standard library.
If I remove the namespace qualifier it builds, although IntelliSense tells me that it's now a recursive call so it probably won't work. If I change the namespace to std:: I get around 270 more errors, this time from several other projects. If I change the function to ::_strdup it builds. Including string.h as the very frst thing changes nothing.
(Nota bene: “it builds” refers to “this particular compiler error disappears at that location, but it still leaves the errors about the other functions, obviously.)
I'm a little at a loss here. I noticed that many larger libraries either build their own abstraction over the standard library or provide things that are not there by default and that was a point where ACE and ImageMagick already clashed (in both typedefing ssize_t but with incompatible definitions). Since we pull in quite a few libraries (I don't have an exact overview either, right now) this could well be another clash, caused by the wrong include order and similar things. This is also hinted at by the fact that the same includes from ACE apparantly work fine in other projects in the same solution.
Anyone have an idea what I could look for here at least? The build log with /showIncludes is just 24k lines so I don't exactly see many patterns there, except that string.h gets included way before the problematic ACE header.
And I wouldn't want to modify the library source code as that will only bite us again if we update to a newer version.
"a number of standard C functions and symbols are not defined"
strdup is not a standard C function. It is defined in POSIX, but not in C or C++. Quoting MSDN:
These POSIX functions are deprecated beginning in Visual C++ 2005. Use the ISO C++ conformant _strdup, _wcsdup, _mbsdup instead.
It appears to me that none of the symbols you list are standard C functions.
With Mark B's comment which prompted me to look at 12 MiB of Preprocessor output I was able to solve it. In string.h the snippet where strdup is defined looks like this:
#if !__STDC__
...
_Check_return_ _CRT_NONSTDC_DEPRECATE(_strdup) _CRTIMP char * __cdecl strdup(_In_opt_z_ const char * _Src);
It so happened that this single project defines the __STDC__ symbol which causes a lot of non-standard-C-but-still-in-the-C-standard-library (thanks, Robφ for nitpicking but not solving the issue) functions to disappear completely.
I know they're deprecated, I got plenty of warnings that tell me so. But as noted, I'm not maintaining project-specific patches to 3rd-party libraries we use just to have the same fun all over again if we ever update them.
If I understand VS correctly, the strdup, etc. function names are deprecated nowadays (not POSIX compliant, I think). You should use the underlined versions.
When this happened for me, I ran a global search and replace, since it seemed like a sensible thing to do and keeps the source code in good condition for the future (VS 2012 is already out! :) ).
I am so frustrated right now after several hours trying to find where shared_ptr is located. None of the examples I see show complete code to include the headers for shared_ptr (and working). Simply stating std, tr1 and <memory> is not helping at all! I have downloaded boosts and all but still it doesn't show up! Can someone help me by telling exactly where to find it?
Thanks for letting me vent my frustrations!
EDIT:
I see my title has been changed. Sorry about that.
So... it was also because it was not clear to me that shared_ptr is "C++ version dependant" --> that's why I did not state my environment --> therefore probably why it was so difficult for me to find it.
I am working on MSVS2008.
EDIT 2:
I don't know why, but I was including [memory] and [boost/tr1/memory.hpp] and [boost/tr1/tr1/memory] while looking everywhere for the shared_ptr.. of course, i couldn't.
Thanks for all the responses.
There are at least three places where you may find shared_ptr:
If your C++ implementation supports C++11 (or at least the C++11 shared_ptr), then std::shared_ptr will be defined in <memory>.
If your C++ implementation supports the C++ TR1 library extensions, then std::tr1::shared_ptr will likely be in <memory> (Microsoft Visual C++) or <tr1/memory> (g++'s libstdc++). Boost also provides a TR1 implementation that you can use.
Otherwise, you can obtain the Boost libraries and use boost::shared_ptr, which can be found in <boost/shared_ptr.hpp>.
Boost Getting Started
If you want to use it from Boost TR1 instead
shared_ptr Example
for VS2008 with feature pack update, shared_ptr can be found under namespace std::tr1.
std::tr1::shared_ptr<int> MyIntSmartPtr = new int;
of
if you had boost installation path (for example # C:\Program Files\Boost\boost_1_40_0) added to your IDE settings:
#include <boost/shared_ptr.hpp>
If your'e looking bor boost's shared_ptr, you could have easily found the answer by googling shared_ptr, following the links to the docs, and pulling up a complete working example such as this.
In any case, here is a minimalistic complete working example for you which I just hacked up:
#include <boost/shared_ptr.hpp>
struct MyGizmo
{
int n_;
};
int main()
{
boost::shared_ptr<MyGizmo> p(new MyGizmo);
return 0;
}
In order for the #include to find the header, the libraries obviously need to be in the search path. In MSVC, you set this in Project Settings>Configuration Properties>C/C++>Additional Include Directories. In my case, this is set to C:\Program Files (x86)\boost\boost_1_42