List Variable in Library Causes run time error, why? - c++

OK folks. I have fixed the error by moving the variable definition, but I do not understand why there is a problem.
Simplified Background: I have an object and I want to track all instances of that object in a list, so I simply created a List<> static member of the class. Below was a simple representation that allowed me to play with it. If I have the line marked as "this line" in the static library. I get a run time error. The object is defined in a header file and is the same header file in both places. If I move "this line" to the code in my final application and it works.... Why? I just don't understand why it is different.
#include "stdafx.h"
#include <list>
using namespace std;
class someobject
{
public:
someobject()
{
// do some stuff.
theStaticList.push_back(this);
}
void func()
{
printf("Made it!!\n");
}
static list<someobject*> theStaticList;
};
list<someobject*> someobject::theStaticList; //*** This line
someobject global;
int main()
{
someobject initial;
initial.func();
global.func();
list<someobject*>::iterator iter;
printf("\n\nLoop the Static List\n");
for (iter = someobject::theStaticList.begin(); iter != someobject::theStaticList.end (); iter++)
(*iter)->func();
return 0;
}

If you put that line in a header file, then include the header into two or more source files, you're defining the list object in each source file where the header gets included.
This violates the one definition rule, so the linker will quite rightly give you an error when you do it.
You want to define the object in one (and only one) source file. For a library, that should be some object file in the library, not the user's source file though (at least as a general rule).

Related

Access global data structure

I'm new to C++ and trying to make a map that all the source files will be able to access. Here is a simplified version of the problematic code. Every header file has a header guard, I just didn't type them here.
// main.cpp
#include "client.hpp"
int main(void){
init();
search();
}
// util.cpp
#include "util.hpp"
std::map<int, STUDENT_TYPE> dataBase;
init(){
dataBase[0] = STUDENT_TYPE(14, 4.0);
// more students....
}
// util.hpp
#include <map>
struct STUDENT_TYPE{
int age;
int grade;
STUDENT_TYPE(int age, int grade) : age(age), grade(grade){}
};
extern std::map<int, STUDENT_TYPE> dataBase;
// client.cpp
#include "client.hpp"
void search(){
std::cout << dataBase[0].grade << std::endl;
}
// client.hpp
#include "util.hpp"
void search();
The problem is that the compiler failed to build at the search function. It gives a big chain of errors. The last error or the cause of all the error is that the constructor of STUDENT_TYPE require 2 fields while given 0. I suspect that client can't access the STUDENT_TYPE struct inside the dataBase. I don't how to fix it or exactly how it happened. I just want a big table of students that all the files in the program can access.
The compiler is telling you exactly what's wrong. Your student type doesn't have a default constructor and it's being used.
Why is it being used?
Because map::operator [] will create a default constructed instance to return if an entry doesn't yet exist for that key. Even if this never happens, the compiler still has to compile that branch and it can't here.
Two ways to fix:
Give your student type a meaningful default.
Don't use map::operator[]. Instead use map::find.
First solution; don't have a global data structure. There is normally no need at at all to have such a thing.
Secondly, understand what header guards do - they prevent the body of a header file being included in the same translation unit. They have no effect if the header file is included in multiple .cpp files.
Thirdly, when you post questions about problems here, post the full text of the error messages you are getting.

Troubles with compiling, static initialization and static libraries

I have recently encountered a behavior in C++ program that I cannot entirely understand. Let me explain the behavior via simple example.
1. First static library
At the very bottom of hierarchy, I have a static library - lets name it FirstLIB. This library includes two pairs of header/source files. The sample.h header file contains MyClass class definition. Corresponding sample.cpp file contains implementation of this class (its methods). The code is presented below:
sample.h
#ifndef __sample_h
#define __sample_h
namespace SampleNamespace
{
class MyClass
{
int counter;
public:
MyClass();
int GetCounter();
void SetCounter(int value);
};
}
#endif
and sample.cpp
#include <iostream>
#include "sample.h"
namespace SampleNamespace
{
MyClass::MyClass(): counter(0)
{
std::cout << "Inside of MyClass constructor!" << std::endl;
}
int MyClass::GetCounter() { return counter; }
void MyClass::SetCounter(int value) { counter = value; }
}
Onwards, the dvcl.h file declares simple API used to manipulate MyClass object and dvcl.cpp implements this API. It's important to notice that dvcl.cpp file contains definition of MyClass object that is used by the methods of this API. The variable is defines as static so it will be visible only inside of this source file.
dvcl.h
#ifndef _dvcl_h
#define _dvcl_h
void DVCL_Initialize(int counter);
int DVCL_GetCounter();
void DVCL_SetCounter(int value);
#endif
dvcl.cpp
#include "dvcl.h"
#include "sample.h"
static SampleNamespace::MyClass myClass;
void DVCL_Initialize(int counter)
{
myClass.SetCounter(counter);
}
int DVCL_GetCounter()
{
return myClass.GetCounter();
}
void DVCL_SetCounter(int value)
{
myClass.SetCounter(value);
}
2. Second static library
Second static library - lets name it SecondLIB - is even simpler than the first one. It only contains one header/source pair. The dvconference_client.h header declares one function, while dvconference_client.cpp implements this function. dvconference_client.cpp also includes dvcl.h header file (which will trigger compilation of dvcl.cpp source). The code can be found below:
dvconference_client.h
#ifndef __external_file
#define __external_file
int DoSomething();
#endif
dvconference.cpp
#include "dvconference_client.h"
#include "dvcl.h"
int DoSomething()
{
return DVCL_GetCounter();
}
3. Main executable
And finally, the main executable MainEXE includes only one main.cpp file. This source includes dvconference_client.h and dvcl.h headers. The code is presented below:
#include <iostream>
#include "dvconference_client.h"
#include "dvcl.h"
int main()
{
std::cout << DoSomething() << std::endl;
std::cout << DVCL_GetCounter() << std::endl;
return 0;
}
4. My doubts and questions:
If I don't call a function that references myClass object (so DoSomething() or one of DVCL_ functions), the MyClass constructor is not invoked. I expected that myClass object will be instantiated by default as dvcl.cpp is compiled. However, it appears that compiler generates needed statements only if it understand that object is actually used in runtime. Is this really true?
If particular header file (in this case dvcl.h) is included in different sources, the corresponding dvcl.cpp is compiled only once. I remember reading something about this, however I'm not sure that this is really true. Is it actually correct that C++ compiler will compile every source file only once, regardless of how many the corresponding header file is included.
myClass object defined in dvcl.cpp is instantiated only once. If I correctly understand the 2nd point and if dvcl.cpp is compiled only once, then there is nothing to question here.
I hope more experienced colleagues can clear my doubts (and I apologize for very long post).
"static SampleNamespace::MyClass myClass; " is both a declaration and definition. So your constructor is invoked and created. Asm-code to instantiate this is generated at compile-time but this is executed at executable-load-time.
For referenec, stages of compilation
source-code --> pre-processing --> compilation --> linking --> loading --> execution
Yes, ".c/.cpp" file are compiled only once. But header are parsed per inclusion.
Yes object is executed only once because corresponding object-file is linked and loaded only once.
First point :
dvcl compilation unit is in a static library. If the code is not used, the compiled object (.o) is not included in resulting executable. As such, static SampleNamespace::MyClass myClass; is never executed. It won't be the same if you were using a dynamic library or explicitely linking the .o file at link time.
Second point :
Use you or not libraries, a source file (.c) or (.cpp) is only compiled (and linked into the executable) once. That's the reason for having .h files that are included in other files and as such processed one time per including file
Third point :
The object is effectively instantiated once, since the .o file is linked only once

Using a static variable of a shared library in more than one functions of a same exe, but different object file

(i have edited my original question to make it more understandable)
here is the prototype for the problem ....
//Txn.h ---this has a static variable, usable by the pgms including it.
class Txn
{
public:
static int i;
static void incr_int();
};
Txn::i=0;
//Txn.cpp
void Txn::incr_int() {i++;}
->produce LibTxn.so
//class1.cpp -> one of the pgm using the static var from Txn.h
#include Txn.h
Txn::incr_int()
-> produce class1.o, with LibTxn.so.
// class2.cpp ->another pgm using the static var from Txn.h
#include Txn.h
cout<<"Txn::i;
-> produce class2.o, by including LibTxn.so
-> .produce class3 (an exe) by using class1.o,class2.o. Since, both class1 and 2 has the statement "Txn::i=0" from "Txn.h", multiple declaration issue happens.
-> .If I remove the statement "Txn::i=0" from Txn.h, then "undefined reference" error appears.
-> .At high lvl, this problem is a kind of having a session variable, which should be assessible from any func in a exe. Those func can be in any obj files used to form the exe. I am fine for any sol, even without static. But I can't change the creation of different .o files (which are using this session var) and combining the .o to produce the exe.
It is hard to figure out exactly what the problem is if you cannot provide the real code, or at least an example which has the same problem as the real code.
However, most likely the root cause of the problem is that you are not only declaring, but also defining your class's static variable in the header file that contains the class definition.
This means that all the translation units (i.e. .cpp files) which include that header will contain a definition for the static variable, and when merging all the corresponding object files, the linker will eventually complain about that symbol being defined multiple times.
If this is the case, what you should do is to take the initialization of the static variable out of the header file which contains your class's definition and put it in one (and only one) .cpp file.
I tried to recreate the problem as you described, but it compiled just fine on my computer, and it is difficult to go further without seeing your code.
In the code below, the header tells (declares) every .cpp file that includes it about Foo::x, but Foo::x lives in (is defined in) Foo.cpp (and Foo.o)
foo.h:
class Foo {
public:
static int x;
};
Foo.cpp:
#include "foo.h"
int Foo::x;
main.cpp:
#include <iostream>
#include "foo.h"
int main(int argc, char *argv[]) {
Foo::x = 42;
std::cout << "Foo::x is " << Foo::x;
}
Yes. it worked by defining the static variable in .cpp.
Special thanks to Andy Prowl and iWerner.

Proper implementation of global configuration

My goal is to have global constants in a C++ game I'm working on (to represent some graphics info and the like). My current implementation is to toss them all in a .h and include them everywhere. This works, except that every time I change a setting, the entire code base must be recompiled.
So, my next idea was to toss them in some configuration txt file and parse them in, that way no code is actually changed when settings change. The parser was simple enough, and I could put the values into the constants, but because the parser was a code block, the constants were no longer global.
Is there a good way to solve this? Perhaps some way to make them global despite being in a block or some way to avoid recompiling everything when changing settings?
The way I used solve this is to put the variables in a separate global namespace, which is in a header file named something like config.h, then include that file everywhere.
// In config.h
#ifndef CONFIG_H
#define CONFIG_H
namespace config
{
extern int some_config_int;
extern std::string some_config_string;
bool load_config_file();
}
#endif
Then in a source file, you define the variable and also set them to a default value. This source file also have the code to load the variables from your configuration file.
// In config.cpp
namespace config
{
int some_config_int = 123;
std::string some_config_string = "foo";
}
bool config::load_config_file()
{
// Code to load and set the configuration variables
}
Now in every source file you need the configuration variables, include config.h and access them like config::some_config_int.
However, there is no "proper" way of solving this, all ways that work are proper in my eyes.
Another way to do this would be to create a singleton class.
#include <fstream>
#include <map>
#include <string>
class ConfigStore
{
public:
static ConfigStore& get()
{
static ConfigStore instance;
return instance;
}
void parseFile(std::ifstream& inStream);
template<typename _T>
_T getValue(std::string key);
private:
ConfigStore(){};
ConfigStore(const ConfigStore&);
ConfigStore& operator=(const ConfigStore&);
std::map<std::string,std::string> storedConfig;
};
Here the configuration is saved in a map, meaning as long as parseFile can read the file and getValue can parse the type there is no need to recompile the config class if you add new keys.
Usage:
std::ifstream input("somefile.txt");
ConfigStore::get().parseFile(input);
std::cout<<ConfigStore::get().getValue<std::string>(std::string("thing"))<<std::endl;
What about creating functions that return your constants that you can specify in a .cxx file? For example:
// foo.h
const int BAR();
// foo.cxx
const int BAR() {
return 10;
};
put only the declarations in head file and put the definitions in a cpp file. then you change the definitions in cpp file will not cause all code recompiled

C++ question... definition doesn't recognize vectors specified in declaration

I'm working on a class assignment that started small, so I had it all in one file. Now it's gotten bigger and I'm trying to separately compile main, functions, and classes (so all the classes are together in one .h and one .cpp) I have one class B, which is the parent of a lot of others and comes first in the file. One of its data members isn't working now that I'm using separate compilation, which is causing dozens of errors.
In .h
class A;
class B {
public:
B (){}
A* myptr;
void whatever();
vector<A*> myAs; //this one is the problem
};
In .cpp
void B::whatever() {
vector<A*> newvector; //no problem!
myptr = &something; //no problem!
for (vector<A*>::iterator iter = myAs.begin(); iter != myAs.end(); ++iter) {
//error!
}
}
I get errors: either "myAs was not declared in this scope" or "class B has no member myAs."
I've included < vector >, forward-declared class A as you see above, and I definitely remembered to include the .h at the top of the .cpp! Is there something about vectors or classes and separate compilation that I don't understand? This is in Xcode, BTW.
It's not just vector. It's std::vector because it is within the namespace called std. That's why the compiler moans. It doesn't know what vector<A*> means. Say std::vector<A*> instead.
Do not add using namespace std; now into the header because of this. It may be OK for the assignment to put it into the .cpp file to save typing if you wish. But it's a really bad idea to put such a line into a header: Because you don't know which files will need your header in future. The situation can quickly get out of hand as the amount of files including your header grows with time. The header should therefor include only the names and headers that it really needs so that it causes as little name conflicts as possible - whereas that using namespace std; line would make all names of std visible directly.