I've been experiencing this error for a while now, on every project that I have built with the CryEngine2 SDK in Visual Studio 2013 Professional.
Most of the time, I have just edited the function from this:
void CMultipleGrabHandler::Reset()
{
std::for_each (m_handlers.begin(), m_handlers.end(), std::mem_fun (&CBaseGrabHandler::Reset));
std::vector <CAnimatedGrabHandler*>::iterator it = m_handlers.begin();
std::vector <CAnimatedGrabHandler*>::iterator end = m_handlers.end();
for ( ; it != end; ++it)
delete *it;
m_handlers.erase (m_handlers.begin (), m_handlers.end ());
}
to this:
void CMultipleGrabHandler::Reset()
{
}
I know it's not a good approach to the problem, but it got rid of the 'mem_fun' : is not a member of 'std' error.
I am now looking for a solution to overcome this problem, since I have just started working on a new project, where stability is key; it's not good if I remove the body of CMultipleGrabHandler::Reset(), since it could possibly induce crashes in certain situations.
I have browsed the internet for a solution to this problem, but I have not found anything (closest thing I found was an explanation of what mem_fun does).
I have tried taking std:: off mem_fun, but I just get an mem_fun is undefined error, suggesting that this isn't exactly the right way to go about mending this error.
The project was originally created in Visual Studio 2005, and was migrated to Visual Studio 2013's format when I first opened the solution.
Might this be the cause of the problem?
How can it be fixed?
Edit: Added visual-studio-2015 as this also applies to the new VS version.
The function std::mem_fun is defined in the header <functional>.
On some older compilers, you don't necessarily need to #include a standard library header in order to use functions and classes defined in that header, because it might already be included by some other standard library header that you #include. This is not exclusive to VS; it was also true for older gcc versions, like 4.0. Newer compilers are more standard-conforming and will require you to #include the actual headers that define standard library functions and classes.
Related
I'm using an external library (Qpid Proton C++) in my Visual Studio project.
The API includes a method like:
container::connect(const std::string &url) {...}
I call it in my code this way:
container.connect("127.0.0.1");
but when debugging, stepping into the library's function, the string gets interpreted in the wrong way, with a size of some millions chars, and unintelligible content.
What could be the cause for this?
You need to put the breakpoint inside the function and not at the function declaration level, where the variable exists but is not yet initialized.
Just in case someone runs into a similar problem, as Alan Birtles was mentioning in his comment, one possible cause is having the library and your code using different C++ runtimes, and that turned out to be the case this time.
In general, as stated in this page from Visual C++ documentation,
If you're using CRT (C Runtime) or STL (Standard Template Library) types, don't pass them between binaries (including DLLs) that were compiled by using different versions of the compiler.
which is exactly what was going on.
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
There is a large legacy project I have to maintain, which I recently upgraded from Visual Studio 2008 to Visual Studio 2012. As it is a COM server and a OCX control, creating all the typelib stuff etc. resulted in some problems that I managed to solve. However, when I run the Release build now I frequently get crashes.
I followed some advise I found here on SO and was able to track down the crash to the following piece of code:
int Phx2Preview::ClearOvlElementList() {
for (int i = 0; i < (int)m_vOvlElements.size(); i++) {
P_SAFE_DELETE(m_vOvlElements[i].pPolyOrig); // <- code crashes here
P_SAFE_DELETE(m_vOvlElements[i].pPolyDispl);
}
m_vOvlElements.clear();
m_vRefElemList.clear();
m_pRefElemSelected = NULL;
return PHXE_NO_ERROR;
}
P_SAFE_DELETE is a macro that checks if the pointer is null, and in case it's not deletes and sets it to null. The actual vector elements are created like this:
if (v1) {
tNew.pPolyOrig = new CInPolygon();
tNew.pPolyDispl = new CInPolygon();
tNew.pPolyOrig->FromSafeArray(v1);
tNew.pPolyOrig->Rotate(NULLPOINT, m_nTurnAngle*__pi/180.);
tNew.eType = (overlayET)type;
tNew.nImagenr = nImageNr;
m_vOvlElements.push_back(tNew);
}
Now, the thing is that CInPolygon is a class from an external library which is created with Visual C++ 7.1. The P_SAFE_DELETE is also defined in a header from that library. From here I know that mixing different runtime versions is bad, and this question lets me suspect that this mixing may be responsible from the crash.
My question is: Why does it happen? After all, since both new and delete are called from the same place, no actual objects are passed between the different CRTs. Also, when the OCX is compiled using Visual Studio 2008, no problems occur. Is this due to pure luck? I guess the basic issue is existing in that setting, too. And, well, what can I do to solve to problem? Switch back to VS2008?
Edit:
As asked: The destructor of CInPolygon is just
CInPolygon::~CInPolygon(void) {
m_vPoints.clear();
}
here the m_vPoints is a std::vector<..> defined in the class. Maybe I should mention that CInPolygon inherits from that:
interface IRoi {
virtual ~IRoi() {
return;
}
public:
// other stuff
};
(Didn't even know that interface was a valid keyword in plain C++...) Could it be that the fact that the base class destructor is defined in the header is causing the problem? After all, that header is also known to the host programm..
tNew.pPolyOrig = new CInPolygon();
Yes, this is guaranteed to fail. Short from having different allocators in your program, your host program cannot possibly compute the size of the CInPolygon object correctly. It uses an entirely different implementation of std::vector. It was significantly rewritten in VS2012 to take advantage of C++11. Inevitably, the code in the library using the old version of vector will corrupt the heap.
You must rebuild the library as well, using the exact same version of the compiler with the exact same settings.
We will convert a number of programs written in C++ and MFC in Visual Studio.NET 2002 to Visual Studio 2010. What problems can we expect to encounter? What changes are there in the libraries that are worth knowing?
MFC has had a number of breaking changes over those releases. All the changes are documented on MSDN, and usually they're pretty straightforward - function signature changes and the like (which can often be fixed simply by inspecting the compiler error message and working out what it wants instead).
I've been through this moving a project to VS 2008 and the two big ones were the "secure CRT" functions and the for loop scope change. (I can't remember precisely when that happened, but it might affect you.) Basically the compiler is your friend ... build the whole thing and it will find the problems, which you can then fix. You can suppress the secure CRT warnings but you might as well get them taken care of.
I'm not aware of any "I'm happy to compile but I won't do quite what I used to do at runtime, thus ruining your world" breaking changes in MFC or C++ over the last decade. So once you make the compiler happy you should be confident your app still works.
dynamic_cast will behave differently at runtime
class A
{
}
class B : public A
{
}
class C : public A
{
}
//...
C* c = new C();
//This used to work, i.e. didn't return NULL, with 2002
B* b = dynamic_cast<B*>(c); //... won't work any more --> returns NULL.
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