SlickEdit Product Discussion > SlickEdit®

type with auto and dynamic_cast<> not determined - C++

<< < (5/5)

Dennis:
Things go haywire before that.  It picks up a #define for dynamic_cast from your Qt tag file.

rowbearto:
I found below code in /usr/include/QtCore/qglobal.h.

It comes from tagfile: GCC-4.8.2-x86_64-redhat-linux.vtg

I added an #undef of QT_NO_DYNAMIC_CAST into preprocessing and rebuilt the GCC-4.8.2-x86_64-redhat-linux.vtg

Now it does find the right type, DerivedClass*

Strange thing is that there were other auto var = dynamic_cast<> in my codebase where the SE was correctly figuring out the type. Don't know why it worked sometimes and not others.

I suppose it is working now for me but would be nice is somehow SE got around this issue, or at least gave some indication to the user so they could easily find this issue and know to do an #undef.

Here is the code in /usr/include/QtCore/qglobal.h:


--- Code: ---#ifdef QT_NO_DYNAMIC_CAST
#  define dynamic_cast QT_PREPEND_NAMESPACE(qt_dynamic_cast_check)

  template<typename T, typename X>
  T qt_dynamic_cast_check(X, T* = 0)
  { return T::dynamic_cast_will_always_fail_because_rtti_is_disabled; }
#endif

--- End code ---

Dennis:
I am adding the same #undef to the pre-configured preprocessing for the hot fix.

I am also going to double-fix it by specifically not allowing "dynamic_cast" to be expanded as a #define

I also found a separate tagging issue with anonymous enumerate types nested in classes which will be fixed in 26.0.2.

There will also be another issue with preprocessing addressed in 26.0.2.

The issue with the global typedef "name" is less fixable.  It is a legitimately defined global, SlickEdit cannot just ignore it, however, the code to avoid going down that path makes it a moot point anyway.

rowbearto:
Thanks Dennis!

Navigation

[0] Message Index

[*] Previous page

Go to full version