Home Help Center

This should work!

catalincatalin Member ✭✭
Hi!

Sorry to bring up something so basic, but I just expected this to work, and it doesn't.

I am implementing a file transfer application. I use mark's suggested ice declarations. Please note the commented out code in the following. I can compile and run the version with code commented out, but not the one where I uncomment the code:

module dacapo {
sequence<byte> FileBlock;

interface FileTransfer {
int getFileSize(string path);
//FileBlock getFile(string path, int pos, int size);
};
};


I implement the server like this:

class FileTransferI : public dacapo::FileTransfer {
public:
virtual int getFileSize(const string &path, const Ice::Current &);
//virtual FileBlock getFile(const string &path, const int &pos,
// const int &size, const Ice::Current &);
};


When I uncomment the code (just to add another operation to my interface) I get the following error message under compilation:

assoro: dacapo6>make server
c++ -I. -I/hom/catalin/hfag/sysInstall/ice120/include -c dacapo.cpp Server.cpp FileTransfer.cpp
Server.cpp: In member function `virtual int ApplicationI::run(int, char**)':
Server.cpp:86: error: cannot allocate an object of type `FileTransferI'
Server.cpp:86: error: because the following virtual functions are abstract:
FileTransfer.h:203: error: virtual dacapo::FileBlock
dacapo::FileTransfer::getFile(const std::string&, int, int, const
Ice::Current& = Current())
make: *** [servero] Error 1
assoro: dacapo6>


This surprises me, because the getFileSize function is just as virtual as getFile, and still the compiler does not complain about it, as it does about the latter.

I guess I am missing something very basic here, can anyone tell me what?

Thanks
Catalin

Comments

  • catalincatalin Member ✭✭
    Hi!

    Before anyone uses to much time on this:

    I get things compiled if I declare the integer parameters to getFile as "int whatever" instead of "int &whatever".

    I anyone cares, why is it OK to pass a string as a pointer and not an integer?

    Thanks,
    Catalin
  • marcmarc FloridaAdministrators, ZeroC Staff Marc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications Engine ZeroC Staff
    Sorry, I don't know what you mean. Why do you think we pass strings as pointer?

    We pass "large" data types (with potentially expensive copy constructor, like strings, structs, vectors, etc.) as C++ const reference, and all "small" ones, like int, float, etc., by value.
  • michimichi Member Michi HenningOrganization: Triodia TechnologiesProject: I have a passing interest in Ice :-) ✭✭✭
    Re: This should work!
    Originally posted by catalin
    Hi!

    I implement the server like this:

    class FileTransferI : public dacapo::FileTransfer {
    public:
    virtual int getFileSize(const string &path, const Ice::Current &);
    //virtual FileBlock getFile(const string &path, const int &pos,
    // const int &size, const Ice::Current &);
    };


    When I uncomment the code (just to add another operation to my interface) I get the following error message under compilation:

    assoro: dacapo6>make server
    c++ -I. -I/hom/catalin/hfag/sysInstall/ice120/include -c dacapo.cpp Server.cpp FileTransfer.cpp
    Server.cpp: In member function `virtual int ApplicationI::run(int, char**)':
    Server.cpp:86: error: cannot allocate an object of type `FileTransferI'
    Server.cpp:86: error: because the following virtual functions are abstract:
    FileTransfer.h:203: error: virtual dacapo::FileBlock
    dacapo::FileTransfer::getFile(const std::string&, int, int, const
    Ice::Current& = Current())
    make: *** [servero] Error 1
    assoro: dacapo6>



    The signature of you implementation of getFile() does not match the signature of getFile() in the skeleton: the skeleton expects two int params, but you have written the signature as expecting two references to const int params. As a result, your implementation does not override the method in the base class, and the compiler correctly refuses to instantiate your servant because it still has a pure virtual function without any implementation.

    When implementing servants, make sure that the signatures of your methods exactly match the signatures of the same methods in the base class or, better, use the --impl switch to the compiler to make it generate implementation stubs for you.

    Cheers,

    Michi.
Sign In or Register to comment.