Design choice (Debugging library)
Alright, I'm developing a library used for the aide of debugging and testing my programs.
Of it's classes included are:
1) a base class inherited by all other classes in this library
~~~ a flag to turn off and on all the functions in the library
~~~ a method to generate a serial for the application (used in logging)
2) a Benching class (all member functions are static)
~~~ 2 private long values used in calculating the runtime of a function
~~~ a public start function that assigns current time to the 1st long value: must be run first.
~~~ a public stop function that assigns current time to the 2nd long value: can't be run unless start function has been run.
~~~ a public get function that prints the difference between these two long values: can only be called after both start and stop have been called, after which all flags will be reset for running again. The long values will be reset to 0
~~~~ More to be added...maybe.
3) a logging class (again all functions are static)
~~~ Basically all functions are wrappers for printing to various log files, and the console. The wrapper functions add formatting to make the logging more legible and include time stamps
My question is what else can I add to this? I can't think of anything else I could need, but I'm sure there are other things I can add. Bare in mind that I'm implementing the library to be complete platform independant and because of this I've forgone implementing anything to do with memory and the task of searching for leaks. I'd rather not have to use anything platform specific, even with #define catches for the compiler vendor.
Of it's classes included are:
1) a base class inherited by all other classes in this library
~~~ a flag to turn off and on all the functions in the library
~~~ a method to generate a serial for the application (used in logging)
2) a Benching class (all member functions are static)
~~~ 2 private long values used in calculating the runtime of a function
~~~ a public start function that assigns current time to the 1st long value: must be run first.
~~~ a public stop function that assigns current time to the 2nd long value: can't be run unless start function has been run.
~~~ a public get function that prints the difference between these two long values: can only be called after both start and stop have been called, after which all flags will be reset for running again. The long values will be reset to 0
~~~~ More to be added...maybe.
3) a logging class (again all functions are static)
~~~ Basically all functions are wrappers for printing to various log files, and the console. The wrapper functions add formatting to make the logging more legible and include time stamps
My question is what else can I add to this? I can't think of anything else I could need, but I'm sure there are other things I can add. Bare in mind that I'm implementing the library to be complete platform independant and because of this I've forgone implementing anything to do with memory and the task of searching for leaks. I'd rather not have to use anything platform specific, even with #define catches for the compiler vendor.
Hi actually debugging and logging I believe is available in Boost library although they are not in Standard C++. You may want to review them instead of re-inventing the wheel. Of cuz if you find them not suited to your needs, you can sub-class their classes and override accordingly.
I think Boost is quite a complete library for C++ but somehow their implementations are slow into getting acceptance into the Standard C++.
I think Boost is quite a complete library for C++ but somehow their implementations are slow into getting acceptance into the Standard C++.
Well there's multiple problems with using boost. For one, I'm not allowed to use anything I didnt write for class (other than ones they require for certain projects) Secondly, it's being written in C++, C#, Java, Go and Bi0Script. So boost is only available in one of those. I can drop the C++ implementation of it I guess, but that's only one fifth of the project.
Topic archived. No new replies allowed.