I am working on porting a game from visual studio to xcode the game was completely written in c++ and I am having some troubles with dynamic casting that I never had when running in visual studio. I am wondering if it is a compiler issue or some things are just not supported in the mac environment, any help will be greatly appreciated. Here is a stripped down version of the code that I am running in xcode which will crash when doing the dynamic_cast
class base {
public:
int dm;
virtual void vm(){}
base(){}
};
class specific : public base {
public:
virtual void vm(){dm++;}
specific (){}
};
specific* sp = new specific();
base* b = (base*) sp;
specific * s = dynamic_cast< specific * >( b );
You can try to set "Enable Runtime Type" = YES
Build setting > Apple LLVM 5.0 - Language - C++
In your xcode project.
hope this help.
Related
Has anything changed in C++ interpretations, and __property functionality?
Trivial example:
class TMyLittleClass
{
private:
TDateTime myDateTime;
protected:
TDateTime getMyDateTime();
void setMyDateTime(TDateTime);
public:
TMyLittleClass(){myDateTime=Now();};
__property TDateTime MyDateTime = {read = getMyDateTime,write=setMyDateTime};
};
somewhere further down in the code we make a call:
// it works ok....
TDateTime dttTemp;
dttTemp.Val = 0;
however, something like this:
TMyLittleClass *myClass = new TMyLittleClass();
myClass->MyDateTime.Val =0;
triggers compiler protest "[C++ Error] : expression is not assignable" ... Why?
Compiling with the "Use "classic Borland compiler" setting works ok, compiling with clang causes the problem.Thanks in advance for any hints., as I need to do an upgrade of earlier codes not necessarily of my own making, and there are quite a few such tidbits.
While I understand all the other puzzles, as they are due to syntactic differences between __cplusplus < 201402L and syntaxes of newer versions, this problem is not necessarily clear to me.
In an app I'm working on (built with Visual Studio 2015), I have the following structure:
Project A -> Native DLL project. This references project B
Project B -> Native static lib project. This references project C.
Project C -> Static lib project with CLR support turned on.
Project A call a function from Project B, which in turn creates an instance of a class from Project C. The instantiated class has a member which is a wrapper around a managed object.
The problem I'm facing is that when I build the code in Release mode, once the code tries to instantiate the class from Project C, it blows up and says that heap has been corrupted. The place where it blows up seems to be the following function from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\crt\src\vcruntime\pureMSILcode.cpp
[System::Diagnostics::DebuggerStepThroughAttribute]
_CRT_SECURITYCRITICAL_ATTRIBUTE
int __clrcall _initterm_e (
_PIFV * pfbegin,
_PIFV * pfend
)
{
int ret = 0;
/*
* walk the table of function pointers from the bottom up, until
* the end is encountered. Do not skip the first entry. The initial
* value of pfbegin points to the first valid entry. Do not try to
* execute what pfend points to. Only entries before pfend are valid.
*/
while ( pfbegin < pfend && ret == 0)
{
/*
* if current table entry is non-NULL, call thru it.
*/
if ( *pfbegin != NULL )
ret = (**pfbegin)();
++pfbegin;
}
return ret;
}
Now here is the thing ... If I turn Project C into a DLL (rather than a static lib) everything works fine. What's more interesting is that all this used to work fine when I built the code in Visual Studio 2013. With VS2015, I don't get any heap corruption if I build the code in debug, but it blows up in release.
I'm aware that having CLR support in a static lib is not the best idea, however I can't seem to find any good information about the issues in having CLR support in a static lib. Additionally this was working all fine in VS2013.
I can just change Project C to be a DLL (which makes more sense when having CLR support), however I would like to understand what has caused the current settings to blow up when converting to VS2015.
The following is a close representation of the relevant code from each project:
Project C:
Foo.h
class FooA
{
public:
FooA();
private:
struct FooAImpl;
std::unique_ptr<FooAImpl> _impl;
};
Foo.cpp
struct FooA::FooAImpl
{
gcroot<ManagedFoo^> managedFoo;
FooAImpl(ManagedFoo^ managedFoo_) :
managedFoo(managedFoo_)
{
}
};
FooA::FooA()
{
_impl = std::unique_ptr<FooAImpl>(new FooAImpl(gcnew ManagedFoo()));
}
Project B:
FooB.h
class FooB
{
public:
Result GetResult();
};
FooB.cpp
Result FooB::GetResult()
{
FooA fooA;
Result r = ...;
return r;
}
Project A
FooC.h
class FooC
{
public:
void Bar();
private:
std::unique_ptr<FooB> m_pFooB;
};
FooC.cpp
void FooC::Bar()
{
Result r = m_pFooB->GetResult();
}
Hope someone has some information around what issues may occur in having a static lib with CLR support. Hope the information I provided describes the problem well.
I have a class containing:
class SomeClass {
SomeClass *previous;
static __declspec(thread) SomeClass *stackTop;
public:
SomeClass() : previous(stackTop) { stackTop = this; }
~SomeClass() { stackTop = previous; }
};
__declspec(thread) SomeClass *SomeClass::stackTop = NULL;
This compiles fine for Win32 target, but when compiling for Pocket PC 2003 (ARMV4) fails with error C2485:
error C2485: '$I' : unrecognized extended attribute
in the two places where I set the member in SomeClass constructor and destructor and in all places where I instantiate SomeClass (it is instantiated as automatic variable and needs to know where the next instance higher up the stack is).
Unfortunately the error has no meaningful documentation in MSDN and the documentation for __declspec(thread) does not indicate any conditions under which it will not work. I did check that thread is not defined in preprocessor.
I don't believe that version of Pocket PC (Windows CE) supports the __declspec(thread) attribute (TLS). It would explain why this only comes up when you're compiling for Pocket PC but not for Win32. See the following links:
Windows CE does not
support the __declspec(thread)
attribute
__declspec (thread) returns
error
I have been porting some C++ code, which was written long time ago, and is normally compiled with Visual C++ (Visual Studio 7.1 version) and Intel C++ Compiler 11.0, the target platform is Linux (Suse x86-64), with GCC 4.3.2 and Intel C++ Compiler 11.1
The problem is that code like this
FileA.h
template<typename T, int dim>
class A
{
public:
A(){};
~A(){};
protected:
void foo1(){};
}
FileB.h
#include "FileA.h"
template<typename T>
class B : public A<T, 2>
{
public:
B(){};
~B(){};
void foo(){ foo1(); }
}
main.cpp
#include "FileB.h"
int main()
{
B<float> b = B<float>();
}
does not compile on Linux (Intel C++ 11.1, GCC 4.3.2), but perfectly compiles on Windows (Visual C++ 7.1, Intel C++ 11.0), althow it surely must not depend on platform.
GCC tells that if I change foo1() to foo1(T a) it will work (and it does), but I can not change the code, and have to use Intel C++ for final release.
I would be glad if anyone could help with any advice.
foo1 is not a dependent expression so the base class, which is a dependent type, is not used to resolve the foo1 call.
As you can't change the code, you are stuffed. If you could change the code you would need to change the expression to be dependent. Typically this is done by changing it to this->foo1().
This is a well-known problem with templates. It is explained in the C++ FAQ
On gcc 4.4.1 (os is Ubuntu) version I could turn the compile error into a compile warning, by using the -fpermissive option to the compiler.
Edit: The fact that some compiler accept it, doesn't mean it will continue to accept it in future versions.
I am facing a problem in release build of Visual Studio
pseudo code is given below
#include "lib/A/inc/A.h"
main()
{
A a;
a.f1();//this fails in release build and works fine in debug build
a.f2();//this fails in release build and works fine in debug build
}
A is derived from B present in lib/B/inc/B.h
class A :public B
{
virtual f2();
};
B has a pure virtual function f2() and normal f1()
class B {
private:
string name;
public:
void f1();
virtual void f2() = 0;
};
I stepped in to the f1() function. At this moment this pointer of B has value 0x0000000 and __vfptr is invalid.
But in main() , object a is valid and __vfptr is also valid. Any idea why this happend in release build ?
Have a look through some of the differences between a debug and release build and my tips for finding the bug:
Common reasons for bugs in release version not present in debug mode