Building libraries...

When working in C it was common for me to build libraries of useful functions. Generally, to facilitate smart linking each function would be in it's own source page producing a granularity of one function per object.

Am I correct in assuming the minimum object size in C++ is 1 class, in that each class can be in it's own object but that all methods of that class have to be in the same object... so the granularity, within the larger library, is 1 class per object, not one method per object?

A small test confirms that it is possible to separate methods into separate objects.

main.cpp

Code:

#include <iostream>

#include "test.h"

using namespace std;

int main(int argc, char** argv)
{
	test t;
	cout << t.method1() << " " << t.method2() << endl;
}

test.h

Code:

class test
{
	public:
	int method1();
	int method2();
};

test1.cpp

Code:

#include "test.h"

int test::method1()
{
	return 1;
}

test2.cpp

Code:

#include "test.h"

int test::method2()
{
	return 2;
}

Code:

$ g++ -c main.cpp
$ g++ -c test1.cpp
$ g++ -c test2.cpp
$ g++ main.o test1.o test2.o
$ ./a.out
1 2

Notice that the last invocation of g++ is just a wrapper for the linker(ld), it links the separate objects into a single executable.

Ok... thanks for that.

Modern linkers can remove unused symbols without putting them in their own translation units. I've never seen C++ code that followed that old-school method.

Focus more on maintainability, readability, and usability when splitting up your source files.

gg

Originally Posted by CommonTater

Ok... thanks for that.

I know it seems odd to waste enough time to do all that, but that was a thought provoking question.

Originally Posted by User Name:

I know it seems odd to waste enough time to do all that, but that was a thought provoking question.

Your efforts and those of others have been an enormous help to me in all this.... and you gotta know I appreciate it. Sometimes the people on this forum are flat out amazing....

Originally Posted by Codeplug

Modern linkers can remove unused symbols without putting them in their own translation units. I've never seen C++ code that followed that old-school method.

Focus more on maintainability, readability, and usability when splitting up your source files.

gg

As in... work in chapters, not pages... one class, one header, one source... which of course makes good sense. But once again I find myself not wanting to make noobish mistakes I will regret in 6 months.

Back in my C days -- LOL, all of 3 days ago! -- I would archive the most useful stuff in one of several .lib files I've built up... one for windows, one for console, one for, well, whaterer. These have gotten fairly large over time and I've often found myself weeding through them getting rid of stuff I'll most likely never need again; you know kind of like that box in the basement...

Imagine my surprise when, in C++ this is not only encouraged, it's by design! Whoda thunk it?

However it strikes me that C++ works in bigger blobs than C or Pascal, groups of methods rather than single functions leaving me with my question....

Thanks guys!

You could use namespace to organize your classes.

Originally Posted by nimitzhunter

You may want to use namespace to organize your classes.

I gave that some thought and at some point I figure that will become a helpful tool, although at this moment I have no idea how I'd do that... I mean, I think I get the syntax now, but on the more practical level...

Ok right now I have a "todo" list of about 15 projects all loosely related to my current online offering... You know, enhancements, accessories... new weapons for the washing machine, kind of stuff. I can see several ways of going with namespaces...

1) Create namespaces by functions... FileStuff, AudioStuff, VideoStuff, etc.
2) Create a unique namespace for each library file. (Which I organize loosely like #1 anyway)
3) Create my own "signature" namespace that I use for everything.
4) different Namespace for each class.

After your suggestion, I'm kinda leaning on #2 ...

I think #3 would be the easiest. Just decide on a name for your library, and make everything inside a namespace named after the name of your library. #2 is pretty similar to #3, so consider this my option of both of them.

#1 would be my favorite, but instead of by function, organize by purpose. It would also entail a crap load more work...

#4 is pretty much pointless, because it would end up having the same effect as populating the global namespace with a lot of classes, except then it would be populated with a lot of namespaces.

Originally Posted by User Name:

I think #3 would be the easiest. Just decide on a name for your library, and make everything inside a namespace named after the name of your library. #2 is pretty similar to #3, so consider this my option of both of them.

#1 would be my favorite, but instead of by function, organize by purpose. It would also entail a crap load more work...

#4 is pretty much pointless, because it would end up having the same effect as populating the global namespace with a lot of classes, except then it would be populated with a lot of namespaces.

Hmmm... given that I'm likely to end up with several library files with multiple classes (etc) in each... sorted by by some, hopefully sensible, criterion. I'm kinda thinking the 2nd option makes best sense to me... namespace per .lib file.... but #3 does appeal to my vanity