Oh, you will have to excuse my energy, you should know by know is "beginner"s energy when everything seems that it can be improved, reworked, redesigned. All this until the person actually starts doing them and the time and energy consumed takes it's toll, so please bare with me
Now, yes, I agree, the current build system is quite simple, but the library might develop into something a little bit more complex as such a more powerful build system comes in handy. Other reasons is that many IDEs (such as kdevelop) have built-in support for automake so importing and working with automake based projects in such IDEs is only fun to do heh. Other advantages are those enlisted in the previous reply (distcheck, automatic release tarballs, etc).
Also (as you have noticed already) I give A LOT of importance on coding style. I do NOT consider conding style more important than the code actuall functionality, I consider them EQUAL. That is I never make something that just works (or at least try to) or make something that just looks nice
I give them both exactly the same importance so I try to make either both of them or none.
About the API, you are right that because I really dont know much about FS specific VP file needs my sugestions might look a little bit offtopic. I agree that the main usage for the library whould be FS and then this tools, packe/unpacker and the tool you said POFCS. I will need to investigate more into this (or maybe someone else can say that already knows it) what are the needs of reading/writting to VP files from this programs ?
About ANSI C++ I always compile my programs with "-Wall -std=c++98 -pedantic"
. Now the <<, >> operators are for formatted input/output of some data types into ASCII encoding. For unformatted (writting/reading chunks of bytes) one has other specific methods in iostreams. Speaking exactly about VP, because we don't store ASCII formatted integers or other binary data then the fact that a iostream interface to VP files provides also access with << and >> is kinda useless
But still there are other advantages (besides that people can reuse their knowledge on iostreams API to use it on VP files). For example one principle I apply in C++ programming is "resource aquisition is initialization", this basically means that if you are aquiring some resource (memory allocation, locking a mutex, opening a file) then you should generally do it by the initialization of an object (make wrappers for your resources if you dont have that). In the iostreams case it means that always open files as ifstream or whatever because in that case when you exit the context of where the ifstream object is defined, then automatically the file is closed and the resource is released. This is actually A LOT MORE important that it sounds at the first glance. To give a specific code example:
in C/C++:
open_vp(filename)
{
FILE *fd = fopen(filename);
if (!fd) return -1;
if (readheader(fd)) {
fclose(fd);
return -1;
}
if (readindex(fd)) {
fclose(fd);
return -1;
}
return 0;
}
This is code duplication and error prone. The way I would do it in C++ is:
open_vp(filename)
{
ifstream fd(filename);
if (!fd || readheader(fd) || readindex(fd)) return -1;
return 0;
}
That's ALL! Because ifstream destructor will be called when exiting the stack context and the file gets closed. In general this principle is very useful and I consider it one of the most important advantages of C++ (if I couldn't do this then I would probably not program at all in C++
).
Anyways, first I have to check out exactly what needs does FS and the tools have on VP files and see if it's really worth it the new API access method.
