Ice 3.2.0 migration: protected class destructors

stephan

Hi!

I wanted to migrate one application to Ice 3.2.0. This application contains a class like this:

class FolderDescTree;
sequence <FolderDescTree> FolderDescTreeSequence;
class FolderDescTree
{
  FolderDescTreeSequence rgChildFolders;
  FolderDesc desc;
};

this special class is used within a Qt application and used with the signal/slot mechanism (producing an AMI result event as introduced in ).

Unfortunately I discovered that the class destructors were made protected in Ice 3.2.0 which breaks the compilation of the Qt moc file.

Is there a chance to make the class destructor public (or to not-define it as it was with Ice < 3.2.0) ?

There seems litte use to define it at all as the implementation is empty...

regards,

Stephan

P.S.: On the other hand, is there another chance to implement a recursive structure but to use a class?

marc

Slice structures cannot be used recursively. In contrast to Slice classes, structs represent simple data aggregations, with no reference semantics.

I don't understand why you require the destructor to be public. Instances of C++ classes generated from Slice classes must not be allocated on the stack. You must also not call delete on such instances. Instead, the smart pointer handles the life cycle of the heap-allocated class instance.

Given this, I don't see how a protected destructor could break any correct Ice for C++ code. The purpose of the destructor is to have the compiler issue an error message if class instances are not properly allocated or destroyed.

stephan

Hi again,

I don't need the destructor in my own code, but in Qt's generated moc code.

The error message is (MSVC2005):

.\generatedfiles\release\moc_ami_myserver_getpublicfoldertreei.cpp(67) : error C2248: 'MyApp::FolderDescTree::__vbaseDtor' : cannot access protected member declared in class 'MyApp::FolderDescTree'
2>        e:\develop\MyApp\interfaces\folder.h(993) : compiler has generated 'MyApp::FolderDescTree::__vbaseDtor' here
2>        e:\develop\MyApp\interfaces\folder.h(959) : see declaration of 'MyApp::FolderDescTree'

and the corresponding moc code looks like this:

int AMI_MyServer_getPublicFolderTreeI::qt_metacall(QMetaObject::Call _c, int _id, void **_a)
{
    _id = QAmiObject::qt_metacall(_c, _id, _a);
    if (_id < 0)
        return _id;
    if (_c == QMetaObject::InvokeMetaMethod) {
        switch (_id) {
        [COLOR="Red"]case 0: response((*reinterpret_cast< const MyApp::FolderDescTree(*)>(_a[1]))); break;[/COLOR]
        }
        _id -= 1;
    }
    return _id;
}

I marked line 67 in red which was mentioned in the compiler error output.

the original definition was:

signals:
  void response(const MyApp::FolderDescTree tree);

which follows what you introduced in the mentioned connection articles for integrating ui applications with Qt using AMI.

do you have a suggestion or an idea how to circumvent these problems?

Regards,

Stephan

marc

OK, I better let the author of the article answer

stephan

Sorry, I didn't see the wood for the trees. The solution is simple:

signals:
  void response(const MyApp::FolderDescTree[COLOR="Blue"]Ptr[/COLOR] tree);

and everything works well again.

too easy

Thanks for the smart pointer comment!

stephan