Header circular dependency

[Kercyn]

Καλημέρα σας.

Έχω μεταξύ άλλων αυτές τις γραμμές στο αρχείο Managers.hpp.

extern std::unique_ptr<MErrorManager> ErrorManager;
extern std::unique_ptr<MPhysFSManager> PhysFSManager;

Στο MPhysFSManager.hpp υπάρχει αυτό:

#include "Managers.hpp"

class MPhysFSManager final : public MManager
{
    public:
        /* other stuff */

        template <typename T>
        T read(BPhysFSFilePtr & handle, std::vector<T> & buffer, PHYSFS_uint32 objSize, PHYSFS_uint32 objCount) const
        {
            BPhysFSFilePtr handle(path);

            PHYSFS_sint64 fileSize = fileLength(handle);

            std::vector<T> buffer(fileSize);
            PHYSFS_uint32 objSize;

            PHYSFS_sint64 length_read = PHYSFS_read(handle, buffer.data(), 1, fileSize);

            if (length_read != fileSize)
            {
                ErrorManager->ThrowError(__FILE__, __func__, __LINE__, "length_read != fileSize (" + path + ")");
            }
            else if (length_read == -1)
            {
                ErrorManager->ThrowError(__FILE__, __func__, __LINE__, "length_read == -1 (" + path + ")");
            }
        }

    private:
};

Όπως βλέπετε έτσι όπως το έχω κάνει δε μου κάνει compile. Δε μπορώ να χρησιμοποιήσω forward declaration στο Managers.hpp ούτε να παραλείψω κάποιο include και να το βάλω στο cpp file. Η λύση που είδα γι' αυτό είναι να έχω το include που δημιουργεί το πρόβλημα σε ξεχωριστό header (δηλαδή να έχω ένα header μόνο για το MPhysFSManager). Αυτή η λύση δε μου αρέσει ιδιαίτερα και δεν ξέρω για πόσα άλλα headers θα χρειαστεί να κάνω το ίδιο.

 

Βλέπω εδώ ότι μπορώ να χωρίσω το definition από το declaration σε ένα template function και να βάλω το definition μέσα στο cpp file. Θα ήταν κάτι τέτοιο η καλύτερη λύση; Τι άλλες εναλλακτικές υπάρχουν για να λυθεί αυτό το πρόβλημα;

 

Ευχαριστώ.

 

ΥΓ. Μη δίνετε σημασία στα διπλα definitions μέσα στη read.

Επεξ/σία 21 Δεκεμβρίου 2015 από Kercyn

[AlexHello]

Αν forward decl. και shared_ptr που δουλεύουν με incomplete types ειναι κάτι που θες να αποφύγεις, θα ακολουθούσα την μεθοδο στο link που παρεθεσες

[Kercyn]

shared_ptr δεν έχω λόγω να βάλω και forward declaration και να ήθελα δε μπορώ να κάνω στο Managers.hpp. Αυτή τη στιγμή έχω κάνει αυτό που λέει στο link αλλά είπα να ρωτήσω κι εδώ μήπως υπάρχει κάποια άλλη λύση.

[παπι]

Σιγουρα θες template;

[Kercyn]

Η αλήθεια είναι ότι δεν είμαι σίγουρος με την έννοια ότι έχω δοκιμάσει και χωρίς template και μου κάνει, απλώς επειδή το δεύτερο argument του PHYSFS_read παίρνει void *, είπα να το κάνω με template αρχικά. Μπορεί στη συνέχεια να δω ότι δεν είναι απαραίτητο και να βάλω κάποιον άλλο τύπο αντί για vector<T>. Απλώς επειδή αυτό το πρόβλημα μπορεί να παρουσιαστεί σε κάποια άλλη κλάση που "σίγουρα" θα χρειάζεται template καλό θα ήταν να δω τι γίνεται από τώρα.

[παπι]

Το πρόβλημα δεν είναι τόσο το template αλλά ότι γραφείς σε header. Πχ έχεις κάτι extern, που κάνουν extern αυτα; Γιατί να κανείς extern αντί να φτιαξεις μια singletone;

[Kercyn]

Στο project μου χρησιμοποιώ managers οι οποίοι διαχειρίζονται διάφορα πράγματα (resource management, rendering, error handling κλπ κλπ). Επειδή αυτοί οι managers χρειάζονται σε πάρα πολλά σημεία και έχω φτιάξει ένα header που τους δηλώνει extern. Στο αντίστοιχο cpp είναι τα declarations μαζί με κάτι συναρτήσεις InitializeManagers κλπ. Τα χρησιμοποιώ ως globals ουσιαστικά.

 

Την singleton την είχα απορρίψει ως λύση γιατί όταν είχα κάνει εκείνο το σχεδιασμό διάβαζα ότι υπάρχουν πολλά drawbacks στα singletons και επειδή δε μπορούσα να πω τεκμηριωμένα ότι ναι, θα το κάνω singleton γι' αυτόν και γι' αυτόν το λόγω το άφησα. Τώρα που τα ξαναδιαβάζω βλέπω ότι, πρακτικά, δε με απασχολούν τα drawback που γράφουν πολλοί στο SO και αλλού. Ακόμα όμως είμαι διστακτικός στο να χρησιμοποιήσω static classes γιατί δεν ξέρω τι προβλήματα μπορούν να προκληθούν στη συνέχεια από έναν τέτοιο σχεδιασμό. Λες θα ήταν καλύτερα να τα κάνω static classes και να βγάλω τα externs;

[παπι]

Το έχεις σε github να δω;

[Kercyn]

https://bitbucket.org/Kercyn/pipantas-game-engine/src/750f6c332581fb02471a6135651e4834beaf5507/PipantasGameEngine/PipantasGameEngine/?at=UI_tests

 

Managers είναι αυτά που έχουν Μ πριν απ' το class name.

[παπι]

Μαλιστα, ειδα την πηγη του προβληματος

 

Εκει στο managers.cpp αυτο θα μπορουσε να γινει ενα object, που ουσιαστικα θα ειναι η πλατφορμα σου.

 

δες εδω https://github.com/AnonymoPapaki/Finance-Chart/blob/master/ChartHostApplication/Main.cppειναι ο client. Μακαροναδα ακομα, αλλα βλεπεις τι θελω να πω. Το "framework" το μονο που κανει export ειναι το fchart_factory το οποιο βγαζει μονο μια κλαση η οποια ειναι και το "framework".

 

Φυσικα εμενα ειναι server-client. Αλλα αν δεν ηταν, τοτε θα στοχευα σε μια τετοια main

int main(){
Application app;
app.run();
return 0;
}

[AlexHello]

Κατ' εμε η ουσία των managers ειναι οτι υπάρχει μόνο ένας για κάθε τύπο. Οποτε singleton θα ήταν ιδανικό.. Singletons με μπόλικα threads βέβαια δεν ειναι η καλύτερη ιδέα..

[Kercyn]

Σκεφτόμουν χτες static class vs singleton και είπα να τα κάνω singletons τελικά. Θα υπάρχει μόνο ένα thread έτσι κι αλλιώς. Σας ευχαριστώ και τους δύο.