views:

83

answers:

2

I'm extracting files from zip and rar archives into raw buffers. I created the following to wrap minizip and unrarlib:

Archive.hpp - Used to access everything. If I could make all the functions in the other classes inaccessible from the outside, I would. (Actually, I suppose I could friend all the other classes in Archive and use private function callbacks..., but that's soo roundabout.)

#include "ArchiveBase.hpp"
#include "ArchiveDerived.hpp"
class Archive {
  public:
    Archive(string path) {
      /* logic here to determine type */
      switch(type) {
        case RAR:
          archive_ = new ArchiveRar(path);
          break;
        case ZIP:
          archive_ = new ArchiveZip(path);
          break;
        case UNKNOWN_ARCHIVE:
          throw;
          break;
      }
    }
    Archive(Archive& other) {
      archive_ = // how do I copy an abstract class?
    }
    ~Archive() { delete archive_; }
    void passThrough(ArchiveBase::Data& data) { archive_->passThrough(data); }
    Archive& operator = (Archive& other) {
      if (this == &other) return *this;
      ArchiveBase* newArchive = // can't instantiate....
      delete archive_;
      archive_ = newArchive;
      return *this;
    }
  private:
    ArchiveBase* archive_;
}

ArchiveBase.hpp

class ArchiveBase {
  public:
    // Is there any way to put this struct in Archive instead,
    //  so that outside classes instantiating one could use
    //  Archive::Data instead of ArchiveBase::Data?
    struct Data {
      int field;
    };
    virtual void passThrough(Data& data) = 0;
    /* more methods */
}

ArchiveDerived.hpp "Derived" being "Zip" or "Rar"

#include "ArchiveBase.hpp"
class ArchiveDerived : public ArchiveBase {
  public:
    ArchiveDerived(string path);
    void passThrough(ArchiveBase::Data& data);
  private:
    /* fields needed by minizip/unrarlib */
    // example zip:
    unzFile zipFile_;
    // example rar:
    RARHANDLE rarFile_;
}

ArchiveDerived.cpp

#include "ArchiveDerived.hpp"
ArchiveDerived::ArchiveDerived(string path) { //implement }
ArchiveDerived::passThrough(ArchiveBase::Data& data) { //implement }

Somebody had suggested I use this design so that I could do:

Archive archiveFile(pathToZipOrRar);
archiveFile.passThrough(extractParams); // yay polymorphism!
  • How do I write a cctor for Archive?

  • What about op= for Archive?

  • What can I do about "renaming" ArchiveBase::Data to Archive::Data? (Both minizip and unrarlib use such structs for input and output. Data is generic for Zip & Rar and later is used to create the respective library's struct.) Everything else is accessed via Archive, and I'd like to make declaring Data in an outside class this way as well.

I know I could throw away my current class Archive, name ArchiveBase into Archive, and use a global factory function. However, I wanted to avoid using the global function.

+3  A: 

First of all you can't "copy" an abstract class because you can't instantiate one. Instead, what you should do is set up a std::tr1::shared_ptr of that class and pass in a pointer.

Archive(ArchiveBase *_archiveBase)

Use a factory function outside of the Archive class for instantiation.

Archive createArchive(string _path, int _type){
    switch(type) {
    case RAR:
      return Archive( new ArchiveRar(path) );
    case ZIP:
      return Archive( new ArchiveZip(path) );
    case UNKNOWN_ARCHIVE:
      throw exception("Unknown archive format");
      break;
    default:
      throw exception("Improper archive type");
  }

For the = operator, simply holding onto a smart pointer such as this and using the "=" will perform the safe transfer of knowledge between classes. It performs reference counting and will delete the pointer so you don't have to and only when it's safe to do so.

Archive& operator = (Archive& other) {
  m_ArchiveBasePtr = other.m_ArchiveBasePtr;
  return *this;
}

Let the smart pointers worry about deleting, copying, and all that for you.

wheaties
I know I could have created the global factory function and then not have had to deal with the pointer issues in the first place, but I was trying to avoid using a global function. It's why I went through the trouble of naming the base class `ArchiveBase` and making everything access via `Archive` member function calls.
Kache4
Kache4, if you were to read Effective C++ by Scott Meyers you'd find out that in C++ functions such as these are considered "better" and more OO than placing it within the class itself. Your Archive class would only depend upon the ArchieveBase. It would build faster and be easier to maintain, not to mention avoid throwing an exception during construction of a class. Global variables are bad but functions are good when placed within a namespace.
wheaties
Hm... alright then. Is there a convention for what to name the namespace for a factory function like this? I can't name it the same as the base class it's supposed to create.
Kache4
Technically you should place the function in the same namespace as your ArchiveBase and derived classes.
wheaties
I ended up making a static factory function in the base class and making it noncopyable.
Kache4
+2  A: 

Wheaties suggestion works when you can afford shallow copies and an N-1 relationship. It breaks down when ArchiveBase subclasses contain specific 1-on-1 data for each Archive instance, and doesn't share across multiple objects gracefully.

An alternative approach to a global createArchive() function is to add an abstract virtual clone() method to ArchiveBase, and then define it in each subclass (ArchiveZip,ArchiveRar) to appropriately replicate a shallow or deep copy as needed.

You can then call archive_.clone() from Archive's copy constructor or operator= if archive_ is not NULL. (Be sure to delete (free) it afterwards!)

What can I do about "renaming" ArchiveBase::Data to Archive::Data? (Both minizip and unrarlib use such structs for input and output. Data is generic for Zip & Rar and later is used to create the respective library's struct.)

There are several options:

Archive::passThrough() { archive_ -> passThrough( this->getData() ) }
Archive::passThrough() { archive_ -> passThrough( this ) }

Or you could maintain a backward reference in ArchiveBase to the corresponding Archive object, which could then be queried for Data.

Though use care! It's easy to get such duplicated information out of sync. (And you can get into header-file loops.) That's why I favor passing the this pointer around! You can always predeclare "class Archive;" and then use Archive* pointers without including Archive.hpp in the header file. (Though you will still need to include Archive.hpp in the .cpp file.)

Mr.Ree
About the copying: thinking on it now, since I'm wrapping C libraries, I can't be certain they (e.g. `unzFile` and `RARHANDLE`) are going to properly clone themselves. So if I can't make it "properly" copyable, is there a way to make Archive expressly un-copyable? Just use the smart pointers then?
Kache4
About the ArchiveBase::Data: I'm forced to define Data in ArchiveBase because the derived classes need to inherit it. However, I want to interface all of this using `Archive`, so the differences between handling zip and rar are hidden (Archive newArc(path);, where path can be to a zip or a rar). But when declaring `Data`, I'd prefer doing "Archive::Data zipData;" to doing "ArchiveBase::Data zipData". Having said that, I don't understand your solution. Is the Data struct still defined in ArchiveBase? Will I be able to declare them using "Archive::Data thisData;"?
Kache4