Vectors using Structures

Started by
9 comments, last by smitty1276 16 years, 2 months ago
I am getting errors while tryin to define a vector using struct my code and errors are posted below, if anyone can help me please do: #include"irrXML.h" #include<fstream> #include<vector> #pragma comment("irrlicht.lib",lib) #include <string> using namespace std; struct db { string model; string msg; string cap; }; typedef std::vector<struct db*>test; db* hdb = new db; using namespace irr; using namespace io; ofstream fileout; // we use STL strings to store data in this example int main() { // create the reader using one of the factory functions fileout.open("example.txt"); IrrXMLReader* xml = createIrrXMLReader("config.xml"); // strings for storing the data we want to get out of the file std::string modelFile; std::string messageText; std::string caption; // parse the file until end reached while(xml && xml->read()) { switch(xml->getNodeType()) { case EXN_TEXT: // in this xml file, the only text which occurs is the messageText hdb->msg = xml->getNodeData(); break; case EXN_ELEMENT: { if (!strcmp("model", xml->getNodeName())) hdb->model = xml->getAttributeValue("file"); else if (!strcmp("messageText", xml->getNodeName())) hdb->cap = xml->getAttributeValue("caption"); } break; } test.push_back(hdb); } // delete the xml parser after usage delete xml; fileout<<test.model<<"/n"; fileout<<test.cap<<"\n"; fileout<<test.msg<<"\n"; fileout.close(); } Errors: Compiler: Default compiler Building Makefile: "F:\Syncro\Makefile.win" Executing make... make.exe -f "F:\Syncro\Makefile.win" all g++.exe -c testert.cpp -o testert.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include" -I"F:/irrlicht-1.4/irrlicht-1.4/include" testert.cpp: In function `int main()': testert.cpp:58: error: expected primary-expression before '.' token testert.cpp:63: error: expected primary-expression before '.' token testert.cpp:64: error: expected primary-expression before '.' token testert.cpp:65: error: expected primary-expression before '.' token make.exe: *** [testert.o] Error 1 Execution terminated [Edited by - Daystar on February 8, 2008 8:32:41 PM]
Advertisement
test is not a vector of db*'s, it is a typedef for a vector of db*'s (you never actually create a vector anywhere in your code).
I would store actual instances of db structs into vector container, instead of pointers.

People well aware of 3 characteristics of OOP; encapsulation, inheritance, and polymorphism. But, easily forget what "Object Oriented" means. Try to use real objects (instances) and to avoid using pointers in C++.
Quote:Original post by Driv3MeFar
test is not a vector of db*'s, it is a typedef for a vector of db*'s (you never actually create a vector anywhere in your code).


So you would define it as typedef struct db
Quote:Original post by Daystar
Quote:Original post by Driv3MeFar
test is not a vector of db*'s, it is a typedef for a vector of db*'s (you never actually create a vector anywhere in your code).


So you would define it as typedef struct db


No... you say:

std::vector<struct db*> test;

test.push_back(x);
// etc...

EDIT:

Do you know how to declare variables in C/C++? It's just

<typename> <identifier>;

So...

int x;
float y;
string z;

Those just declare variables of the given type and name... and int named x, a float named y, a string named z. If you want a vector of db* named test, it's the exact same thing...

vector<db*> test;
Quote:Original post by songho
I would store actual instances of db structs into vector container, instead of pointers.

People well aware of 3 characteristics of OOP; encapsulation, inheritance, and polymorphism. But, easily forget what "Object Oriented" means. Try to use real objects (instances) and to avoid using pointers in C++.
Why on earth would he want to avoid using pointers? There are profound consequences to allocating on the stack vs the heap, copying objects, etc.


Quote:Original post by smitty1276
Quote:Original post by songho
I would store actual instances of db structs into vector container, instead of pointers.

People well aware of 3 characteristics of OOP; encapsulation, inheritance, and polymorphism. But, easily forget what "Object Oriented" means. Try to use real objects (instances) and to avoid using pointers in C++.
Why on earth would he want to avoid using pointers? There are profound consequences to allocating on the stack vs the heap, copying objects, etc.


Generally when someone says "avoid using pointers" in the context of C++ it means you should try to use the standard library containers etc to avoid having to manually manage pointers, not to allocate everything on the stack and to avoid introducing unnecessary indirection. For example he should probably be using a std::vector<db> rather then a std::vector<db*>, unless I'm misunderstanding what the codes meant to do.
Quote:Original post by Julian90
Generally when someone says "avoid using pointers" in the context of C++ it means you should try to use the standard library containers etc to avoid having to manually manage pointers ... For example he should probably be using a std::vector<db> rather then a std::vector<db*>
I'm not sure I follow what your saying there. The first point doesn't necessarily imply the second, and the second doesn't seem to be related to the first, since the first concerns management of pointers and the second dismisses pointers entirely.

In any case, allocating objects on the stack and then copying them into a container is inefficient, at best, and could cause undesirable behavior in some cases if you aren't careful (for example, a destructor will be invoked if the original object goes out of scope, right?).

It depends on what you're doing, and in some situations it may be good advice to say that you should "avoid pointers". But making the blanket statement that you should "avoid pointers" in C++ is decidedly bad advice. The best advice is this: learn to use pointers--as well as the rest of the language--and know what is right for your needs in a given situation.
Could you please edit your original post to include [source]<code goes here>[/source] tags. Also, you'll need to copy and re-paste the original code because it loses the indentation when you don't use source tags. Then I'll take a look,
Thanks.
"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms
Quote:Original post by smitty1276
Quote:Original post by Julian90
Generally when someone says "avoid using pointers" in the context of C++ it means you should try to use the standard library containers etc to avoid having to manually manage pointers ... For example he should probably be using a std::vector<db> rather then a std::vector<db*>
I'm not sure I follow what your saying there. The first point doesn't necessarily imply the second, and the second doesn't seem to be related to the first, since the first concerns management of pointers and the second dismisses pointers entirely.

In any case, allocating objects on the stack and then copying them into a container is inefficient, at best, and could cause undesirable behavior in some cases if you aren't careful (for example, a destructor will be invoked if the original object goes out of scope, right?).

It depends on what you're doing, and in some situations it may be good advice to say that you should "avoid pointers". But making the blanket statement that you should "avoid pointers" in C++ is decidedly bad advice. The best advice is this: learn to use pointers--as well as the rest of the language--and know what is right for your needs in a given situation.

Actually, "try to avoid using pointers in C++" is a good advice.
That's why C++ introduces "references" over pointers. If you don't like the word, "avoid" then, I can rephrase that:
Use pointers when you have to.

Please read more in C++ FAQ

And, a container class (vector, list, etc) should store objects in the container if possible. Otherwise, it is not object-oriented and it is pointer-oriented programming. (The last sentence is a joke.)

This topic is closed to new replies.

Advertisement