0

Why does the compiler (g++) complain about this line of code?

    XalanNode *docElement = static_cast<XalanNode*> (docBuilder_->getDocument()->getDocumentElement());

The error I get from the compiler is:

 error: invalid static_cast from type `amxalanc_1_6::XalanElement*' to type `amxalanc_1_6::XalanNode*'

Without the static_cast, the compiler prints:

error: cannot convert `amxalanc_1_6::XalanElement*' to `amxalanc_1_6::XalanNode*' in initialization

The XalanElement class is defined as:

class XALAN_DOM_EXPORT XalanElement : public XalanNode

The documentation also shows that XalanNode should derive from XalanElement, as you can see here - XalanElement Class Reference.

Within XalanDocument.hpp, the method signature of getDocumentElement() is:

virtual XalanElement* getDocumentElement() const = 0;
snibbets
  • 1,095
  • 10
  • 11
  • 3
    If `XalanElement` is derived from `XalanNode` and `getDocumentElement()` returns a pointer to a `XalanElement`, then you don't even need a cast and the compiler shouldn't error. Double-check the return type of `getDocumentElement`. – Seth Carnegie Sep 28 '12 at 03:46
  • If `XalanElement` derives from `XalanNode`, then why not just make `docElement` a `XalanElement*` instead? I.e., given a simple workaround, is this question just academic? – ildjarn Sep 28 '12 at 04:09
  • I need to pass docElement_ into FormatterTreeWalker.traverseSubtree() which expects XalanNode*. Again, the compiler complains if I pass in a pointer of type XalanNode*. Thanks for the suggestion though. – snibbets Sep 28 '12 at 04:14
  • Again, if `XalanElement` derives from `XalanNode`, then you should be able to pass any `XalanElement*` into a function expecting a `XalanNode*` and it will be cast implicitly without any extra code, muchless errors. Clearly your assertion that `XalanElement` derives _publicly_ from `XalanNode` cannot be true given the compiler errors. Are you getting this from the source code or from the documentation? – ildjarn Sep 28 '12 at 04:40
  • I understand what you are saying. It should work ... but the fact is it ain't. I've now included a link to the documentation in the post. From the definition of XalanElement above (unless this is from the wrong header file, which is unlikely) you can see that it is defined as expected. I'm hoping someone who has used Xalan-C++ has encountered the same problem. – snibbets Sep 28 '12 at 05:06
  • 2
    Have you `#include`d the header that _defines_ `XalanElement`? – CB Bailey Sep 28 '12 at 05:24
  • 1
    Charles Bailey has the most likely solution. You've included something that forward defines both `XalanElement` and `XalanNode`, but that isn't enough to get the cast to work, you need the full definition of them both. – Michael Anderson Sep 28 '12 at 05:31
  • Thanks @CharlesBailey, that was the problem. The compiler must have known about these classes, but they weren't implicitly included in the right order or some such, so I explicitly included them in my file. It's times like this I see why Java was invented. – snibbets Sep 28 '12 at 05:41
  • Thanks also to @MichaelAnderson for the explanation. – snibbets Sep 28 '12 at 05:45

1 Answers1

2

Most of the Xalan headers only use forward declarations for classes that they are not defining even if they are declaring functions that take or return pointers to these classes. (This is common and good practice.)

For your compiler to see the fact that XalanElement is derived from XalanNode you need to explicitly #include the header which defines XalanElement.

CB Bailey
  • 755,051
  • 104
  • 632
  • 656
  • To give a specific example, in this case XalanDocument.hpp contains the forward reference `class XalanElement;`, but does not declare what it is derived from. – snibbets Sep 28 '12 at 07:09