Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Multiple includes

Multiple includes

Scheduled Pinned Locked Moved C / C++ / MFC
helpquestionc++visual-studiolinux
27 Posts 8 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S Shy Agam

    It appears I had to declare the static member variables in both the header files, and the source files. The project now compiles successfully. What's the idea behind this repetitive declaration? It's not like a function which is declared in the header, and defined in the source. It's simply a variable... Oo *Confused*

    A Offline
    A Offline
    Aescleal
    wrote on last edited by
    #17

    When you declare a static data member in a class you're telling the compiler: "This class has a static member called ." When you define it outside of a class you're telling the compiler: "You know that variable ? This is where you reserve memory for it and initialise it with ." So it really is identically like a function which is declared in a header and defined in the source. Cheers, Ash PS: It's also identical to the behaviour of global variables - declare in a header, define in source. Which is a big hint why statics are bad, bad, bad...

    T 1 Reply Last reply
    0
    • P Paul Michalik

      Sorry, these hierarchical"replies" suck!

      L Offline
      L Offline
      Lost User
      wrote on last edited by
      #18

      paul_71 wrote:

      these hierarchical"replies" suck!

      Well, they take a bit of getting used to, but sometimes they work better than the other style.

      It's time for a new signature.

      1 Reply Last reply
      0
      • S Shy Agam

        It appears you guys were right. This is a linker issue. Eclipse lets you specify a reference to your other project. Being a devoted Visual Studio for .NET developer, I guess I assumed adding the reference was suffice. However, I've found the specific settings needed for linking the library. For future references to this post: 1. Open the project's settings. 2. Expand "C/C++ Build" and select "Settings". 3. Under "Tool Settings" expand "GCC C++ Linker" and select "Libraries". 4. Add the name of the library on the top box, and the path to its files on the bottom one. (Note that the path to the library should be the project's Debug directory) So now the project gets compiled, and the linker no longer whines about not finding the library. However I get some new linking errors. The new console output is as follows: make all Building target: Maple Invoking: GCC C++ Linker g++ -L"/LibraryPath/Debug" -o"Maple" ./Source/Maple.o -lCursesPlus /LibraryPath/Debug/libCursesPlus.so: undefined reference to `CursesPlus::CursesPlusEngine::initialized' . . . collect2: ld returned 1 exit status make: *** [Maple] Error 1 The vertical three dots hold place for a series of "undefined reference to..." errors, which are similar to the first error, but specify a different member of CursesPlusEngine. And to make it clear: Maple is my main executable project, and libCursesPlus is my library project. --Edit-- All of the above members are defined as private static in their corresponding header files.

        modified on Tuesday, August 31, 2010 4:56 AM

        P Offline
        P Offline
        Paul Michalik
        wrote on last edited by
        #19

        No! You may declare your static class members only once. What you have missed, is the definition (which also has to be unique), and it needs to be provided outside of the class, for non-const and non-trivial objects.

        // in AStuff.h
        class AStuff {
        public:
        void Hello() {
        // ...
        }
        };

        // in A.h
        class A {
        public:
        static AStuff sStaticAMember; // <-declaration
        };

        // in A.cpp
        AStuff A::sStaticAMember; //<-definition (required!)

        The constructor for A::sStaticAMember will be called by the runtime (dynamic initialization) if the instance is used by the program. You do not (really) have the control over when this is going to happen, neither when the destructor is going to be called. This is one of the reason why the poster above damned "statics" ... and basically I have to agree with him. Are you using C# otherwise? If yes, then forget about the comfort of static class objects and their well defined initialization there - and enter one of the many dark zones of c++. I assume you will probably run into the problem of undefined order of initializations of your non-local objects, but we stand ready to help :)

        modified on Tuesday, August 31, 2010 12:56 PM

        S 1 Reply Last reply
        0
        • A Aescleal

          When you declare a static data member in a class you're telling the compiler: "This class has a static member called ." When you define it outside of a class you're telling the compiler: "You know that variable ? This is where you reserve memory for it and initialise it with ." So it really is identically like a function which is declared in a header and defined in the source. Cheers, Ash PS: It's also identical to the behaviour of global variables - declare in a header, define in source. Which is a big hint why statics are bad, bad, bad...

          T Offline
          T Offline
          Tim Craig
          wrote on last edited by
          #20

          Aescleal wrote:

          PS: It's also identical to the behaviour of global variables - declare in a header, define in source. Which is a big hint why statics are bad, bad, bad...

          That's a rather sweeping statement. Parts of the language are there for a reason. There are cases where you absolutely need them. Can you misuse them? Certainly. But just yelling bad, bad, bad, ignores the valid cases.

          Once you agree to clans, tribes, governments...you've opted for socialism. The rest is just details.

          A 1 Reply Last reply
          0
          • T Tim Craig

            Aescleal wrote:

            PS: It's also identical to the behaviour of global variables - declare in a header, define in source. Which is a big hint why statics are bad, bad, bad...

            That's a rather sweeping statement. Parts of the language are there for a reason. There are cases where you absolutely need them. Can you misuse them? Certainly. But just yelling bad, bad, bad, ignores the valid cases.

            Once you agree to clans, tribes, governments...you've opted for socialism. The rest is just details.

            A Offline
            A Offline
            Aescleal
            wrote on last edited by
            #21

            So where would you use a class static instead of just declaring a variable in an anonymous namespace? i.e. where would you use:

            // A.h

            class A
            {
            private:
            static B b;
            };

            // A.cpp

            A::B b( b_init );

            over:

            // A.cpp

            namespace
            {
            B b;
            }

            'Cause I'm not sure I can see any case where that would be of any use. And if you're talking about using public class static data member why not use a global? They've got exactly the same visibility, thread safety issues and initialisation order problems.

            P T 2 Replies Last reply
            0
            • A Aescleal

              So where would you use a class static instead of just declaring a variable in an anonymous namespace? i.e. where would you use:

              // A.h

              class A
              {
              private:
              static B b;
              };

              // A.cpp

              A::B b( b_init );

              over:

              // A.cpp

              namespace
              {
              B b;
              }

              'Cause I'm not sure I can see any case where that would be of any use. And if you're talking about using public class static data member why not use a global? They've got exactly the same visibility, thread safety issues and initialisation order problems.

              P Offline
              P Offline
              Paul Michalik
              wrote on last edited by
              #22

              Aescleal wrote:

              So where would you use a class static instead of just declaring a variable in an anonymous namespace?

              ...Whenever the non-local is associated with a type, think of the "class object" idioms: reflectors, serializers, registrars etc... Especially in generic code, class statics can be looked up parametrically, which can't be achieved with traditional non-locals.

              Aescleal wrote:

              They've got exactly the same visibility, thread safety issues and initialisation order problems

              This remains true and makes c++ non-locals of either kind a dangerous business...

              1 Reply Last reply
              0
              • A Aescleal

                So where would you use a class static instead of just declaring a variable in an anonymous namespace? i.e. where would you use:

                // A.h

                class A
                {
                private:
                static B b;
                };

                // A.cpp

                A::B b( b_init );

                over:

                // A.cpp

                namespace
                {
                B b;
                }

                'Cause I'm not sure I can see any case where that would be of any use. And if you're talking about using public class static data member why not use a global? They've got exactly the same visibility, thread safety issues and initialisation order problems.

                T Offline
                T Offline
                Tim Craig
                wrote on last edited by
                #23

                I suppose the classic example is where you want to keep stats on the class such has how many instances are currently running rampant. Why should I have to go reference another namespace? Like many things in the C world, there's plenty there to shoot yourself in the foot with, you need to exercise proper caution.

                Once you agree to clans, tribes, governments...you've opted for socialism. The rest is just details.

                P 1 Reply Last reply
                0
                • P Paul Michalik

                  No! You may declare your static class members only once. What you have missed, is the definition (which also has to be unique), and it needs to be provided outside of the class, for non-const and non-trivial objects.

                  // in AStuff.h
                  class AStuff {
                  public:
                  void Hello() {
                  // ...
                  }
                  };

                  // in A.h
                  class A {
                  public:
                  static AStuff sStaticAMember; // <-declaration
                  };

                  // in A.cpp
                  AStuff A::sStaticAMember; //<-definition (required!)

                  The constructor for A::sStaticAMember will be called by the runtime (dynamic initialization) if the instance is used by the program. You do not (really) have the control over when this is going to happen, neither when the destructor is going to be called. This is one of the reason why the poster above damned "statics" ... and basically I have to agree with him. Are you using C# otherwise? If yes, then forget about the comfort of static class objects and their well defined initialization there - and enter one of the many dark zones of c++. I assume you will probably run into the problem of undefined order of initializations of your non-local objects, but we stand ready to help :)

                  modified on Tuesday, August 31, 2010 12:56 PM

                  S Offline
                  S Offline
                  Shy Agam
                  wrote on last edited by
                  #24

                  This is all a bit overwhelming for me... I also read some articles regarding the subject, but I still can't <b><i>completely</i></b> get my head around it. I should hit the books for a while and establish a more solid understanding of C++'s principles and design issues. For now, I would add this question though... What is the "danger" in what I did? i.e. declaring a private static member variable inside a class...

                  P 1 Reply Last reply
                  0
                  • T Tim Craig

                    I suppose the classic example is where you want to keep stats on the class such has how many instances are currently running rampant. Why should I have to go reference another namespace? Like many things in the C world, there's plenty there to shoot yourself in the foot with, you need to exercise proper caution.

                    Once you agree to clans, tribes, governments...you've opted for socialism. The rest is just details.

                    P Offline
                    P Offline
                    Paul Michalik
                    wrote on last edited by
                    #25

                    Tim Craig wrote:

                    I suppose the classic example is where you want to keep stats on the class such has how many instances are currently running rampant.

                    Yes, this is a classic one, where a static member must be associated with a class... As an example to the generic argument from above, consider an InstanceCountabe policy:

                    template<class T>
                    class InstanceCountable { :)
                    static int sCounter;
                    protected:
                    InstanceCountable() {
                    InstanceCountable<T>::sCounter++;
                    }
                    ~InstanceCountable() {
                    InstanceCountable<T>::sCounter--;
                    }
                    public:
                    static GetCount() {
                    return InstanceCountable<T>::sCounter;
                    }
                    };

                    template<class T>
                    int InstanceCountable<T>::sCounter(0);

                    // ...and then

                    class A : public InstanceCountable<A> {
                    //...
                    };

                    class B : public InstanceCountable<B> {
                    //...
                    };

                    // etc...

                    int main() {
                    A a1, a2;
                    std::array<B, 10> barr;

                    std::cout <<
                    A::GetCount() << std::endl // prints 2
                    B::GetCount() << std::endl;// prints 10
                    }

                    1 Reply Last reply
                    0
                    • S Shy Agam

                      This is all a bit overwhelming for me... I also read some articles regarding the subject, but I still can't <b><i>completely</i></b> get my head around it. I should hit the books for a while and establish a more solid understanding of C++'s principles and design issues. For now, I would add this question though... What is the "danger" in what I did? i.e. declaring a private static member variable inside a class...

                      P Offline
                      P Offline
                      Paul Michalik
                      wrote on last edited by
                      #26

                      Well, there are several "dangers" in that, but don't panic! It's a perfectly legal c++ construct - which can be used in safe manner if: 1. the functionality of your program does not depend on the time when the global objects are initialized/deinitialized 2. the globals do not depend on the state of each other in an undefined manner 3. you can assure that these global objects are initialized at all - speaking in terms of the holy standard "they are used in the program". With regards to point 3: Under certain circumstances, linkers do not include these globals into the program, if they don't see an explicit usage of them. This behavior collides with many popular idioms such as pluggable factories, reflectors or serializers: Here, the framework relies on dynamic initialization (this is a process which runs before your program starts) of static class objects with non-trivial constructors which perform certain functionality on instantiation - e.g. register a factory method for a type in an another global collection of factory methods.

                      S 1 Reply Last reply
                      0
                      • P Paul Michalik

                        Well, there are several "dangers" in that, but don't panic! It's a perfectly legal c++ construct - which can be used in safe manner if: 1. the functionality of your program does not depend on the time when the global objects are initialized/deinitialized 2. the globals do not depend on the state of each other in an undefined manner 3. you can assure that these global objects are initialized at all - speaking in terms of the holy standard "they are used in the program". With regards to point 3: Under certain circumstances, linkers do not include these globals into the program, if they don't see an explicit usage of them. This behavior collides with many popular idioms such as pluggable factories, reflectors or serializers: Here, the framework relies on dynamic initialization (this is a process which runs before your program starts) of static class objects with non-trivial constructors which perform certain functionality on instantiation - e.g. register a factory method for a type in an another global collection of factory methods.

                        S Offline
                        S Offline
                        Shy Agam
                        wrote on last edited by
                        #27

                        I understand... Thank you Paul, and everyone else for your help and opinions. :) For now, I shell continue and educate myself on the matter... Will "meet" again... (Soon I might add... ;P )

                        1 Reply Last reply
                        0
                        Reply
                        • Reply as topic
                        Log in to reply
                        • Oldest to Newest
                        • Newest to Oldest
                        • Most Votes


                        • Login

                        • Don't have an account? Register

                        • Login or register to search.
                        • First post
                          Last post
                        0
                        • Categories
                        • Recent
                        • Tags
                        • Popular
                        • World
                        • Users
                        • Groups