2

My code is like this:

void some_func(void *source)
{
    ...
    double *casted = reinterpret_cast<double *>(source);
    ...
}

This causes std::__non_rtti_object exception. Acording to stack trace, it is raised from __RTDynamicCast, which is (as far as i know) MSVC implementation of dynamic_cast.

This exception should occur with dynamic_cast, as the pointer comes from external library (probably compiled without /GR) and points to struct with several doubles. But I would not expect this with reinterpret_cast. Shouldn't it just change the type of the pointer, without any checks at all?

Notes:

  • my compiler is msvc120 (MS Visual Studio 2013)
  • project is compiled with /GR (enable run-time type information)
  • pointer "source" comes from external library (probably compiled without /GR)
  • I also tried static_cast with the same result
suspectus
  • 16,548
  • 8
  • 49
  • 57
Firielentul
  • 193
  • 1
  • 8
  • 3
    Seems odd, RTTI should not affect a `reinterpret_cast`. What happens with an old-style C cast (e.g. `(double*)source`)? – Jonathan Potter Dec 10 '13 at 19:49
  • 1
    Even though [this question](http://stackoverflow.com/questions/5582874/dynamic-cast-throws-pointer-is-not-std-non-rtti-object) deals with that exception being thrown from a `dynamic_cast`, the OP's answer says that the problem was that the pointer was `nullptr`. Are you sure `source != nullptr`? – Praetorian Dec 10 '13 at 19:56
  • 5
    I don't believe you've shown us enough of the code to determine the problem. This looks perfectly valid to me, even if you're casting a null pointer. – Mark Ransom Dec 10 '13 at 19:57
  • Same result, with (double *)source. – Firielentul Dec 10 '13 at 19:58
  • 1
    Is there a chance of malicious macro defining `reinterpret_cast` (and `static_cast`) as `dynamic_cast` being present somewhere? Oh, I see... `(double *)source` doesn't work either. – AnT stands with Russia Dec 10 '13 at 19:58
  • `reinterpret_cast` is mostly implementation defined, so that is one expected result. – PlasmaHH Dec 10 '13 at 19:58
  • 1
    @PlasmaHH: It is not *that* implementation defined. The only freedom the implementation has here is the actual value of the result. It has no freedom to generate an RTTI-related failure. – AnT stands with Russia Dec 10 '13 at 19:59
  • Can you stop at the line in debugger, do `Alt+8` and copy-paste the assembly it generated for the cast? – AnT stands with Russia Dec 10 '13 at 20:03
  • 2
    Ah, i tried to rebuild whole project with all additional libraries and the problem disappeared. Seems strange, because I never had a code using dynamic_cast, so don't know what caused this. Also I already tried to rebuild that project only (without other dlls) before. Anyway, thanks for all help. – Firielentul Dec 10 '13 at 20:04
  • @Praetorian: Why would a `nullptr` cause a failure in this cast? – AnT stands with Russia Dec 10 '13 at 20:04
  • @AndreyT I don't think it should, but given that a `reinterpret_cast` is throwing some RTTI related exception, I thought it might be worth a shot, even though it's a stretch. – Praetorian Dec 10 '13 at 20:09
  • Just noting that `static_cast(source)` is equivalent (and ,arguably, better style) – M.M Apr 24 '14 at 06:59

2 Answers2

0

Non-reproducible.

Ah, i tried to rebuild whole project with all additional libraries and the problem disappeared. Seems strange, because I never had a code using dynamic_cast, so don't know what caused this. Also I already tried to rebuild that project only (without other dlls) before. Anyway, thanks for all help. -- OP

Community
  • 1
  • 1
Martin Ba
  • 37,187
  • 33
  • 183
  • 337
0

It seems as that you need to recheck dll's order of build in your makefile (if you use such). I guess that the source from the external library you mentioned, comes from external library that is "higher" in the build tree than the library which your code resides. Try to see if your makefile properly works (maybe misses some triggers).

Daniel Heilper
  • 1,182
  • 2
  • 17
  • 34