0

I'm fairly new to c++, but I've reached a point where I want to build my own library for use in other programs. I've run into an organization issue which can be solved with namespaces and passing structs, but I'd like to organize my functions within a class. I have searched, but have not found many clear answers. I would also like to avoid having to use "friend class x" as I have written many of the functions already and plan to write more, and all the referencing could be avoided if I kept it in the same object.

class FileOps
private:
<data to be manipulated>
public:
    // Target Management:
    void setDir(std::string input);
    void setFile(std::string target, std::string extension);
    // File Management:
    void listFiles(std::string manualExtension);
    void setFileList();
    bool fileSeek();
    void deleteFile();
    std::string chooseFile(std::string manualExtension);
    // File Content:
    void displayFileContents();
    std::string randomLine();
    void listManagement();
    // Database Management:
    void typeList();
    void smartBuffer();
    void dataBuffer(std::string dataType);
    searchTable searchQuery;
    std::string searchSimple(std::string searchType);
    void searchDump();
    void globalDataSearch();
    void globalTermSearch();
    void globalDataDump();
    void dataDump(std::string dataTypeSelection);

I could easily fix this issue by turning the private data into a struct, then passing the struct through the arguments, but I'd like to create 1 object per class, then in the implimentation, reference the command something like:

Fileops x;
x.TargetManage::setDir("thisdirectory");
x.FileManage::listFiles();

... etc.

Is this possible? If so, how?

  • 1
    Why would you want a class like this? A namespace which contains a collection of free-standing functions is a much more natural solution to this problem. And the class you propose here contains **far** too many member functions anyway! You should encapsulate the private data in a class of its own and pass references to instances of that class to free-standing functions. – Christian Hackl Jan 21 '17 at 11:14
  • As an aside, it may be better to take the parameters by (constant) reference, instead of by value: `const std::string& parameterName`. This prevents them from being needlessly duplicated, and allows taking a parameter by value to indicate that duplicating it is intended (such as when you want a local copy you can change, without affecting the original). – Justin Time - Reinstate Monica Jan 22 '17 at 04:10
  • @JustinTime: That's pre-C++11 advice. Since C++11, moving can avoid many copies. – MSalters Jan 23 '17 at 12:02
  • @MSalters Moving only avoids copies when the string can be moved. [If you explicitly don't intend to make a copy or modify the string, then `const std::string&` is often more efficient.](http://stackoverflow.com/a/10236790/5386374) I was thinking generally; it's liable that this class will be used with string lvalues as well as rvalues, with lvalues being more common in complex usage, so I figured `const std::string&` would be more efficient overall. – Justin Time - Reinstate Monica Jan 25 '17 at 18:19

1 Answers1

0
#include <iostream>
class FileOps
public:
FileOps() {TargetManage.f = this;}
private:
friend class s1;
int x = 1;
public:
    class s1 {
    public:
        FileOps * f;
        void setDir(std::string input) {std::cout << ++f->x;}
        void setFile(std::string target, std::string extension);
    } TargetManage;
    class {
    public:
        void listFiles(std::string manualExtension);
        void setFileList();
    } FileManage;
...

Fileops x;
x.TargetManage.setDir("thisdirectory");
x.FileManage.listFiles();
  • This was my first guess, but doesn't work. If this were java, it would, but c++ nested classes do not inherit members from parent classes. Thank you for your reply. – LazySpoon Utensil Jan 23 '17 at 04:10
  • You are completely right. I updated the answer to make FileOps's data member available to the (first) nested class. But you might find this approach too convoluted. – Gilles Schreuder Jan 23 '17 at 11:20