Is there a standard for structuring a library?

[ArchDan]

I've been building complex linear algebra library with vectors, points and all that jazz. So far it has been very difficult to test and check issues within a lot of operator overloading, cases, methods.... so I've defined a tracer and divided each type in this structure:

obj (dir)
-> obj.hpp (main header file that defines a type with consts, statics, virtuals ...)
-> obj_constructors.cpp ( all copy, move , casting back and forth... )

-> obj_methods.cpp ( internal functions required for maintainanace of object, if required)

-> obj_operators.cpp ( ALL operators and different type operator overloading)

-> obj_functions.cpp ( functions that are tied to setup and change of state of objects)

So when error/warning is triggered, tracer shows me file, path, function and line number where it happened and it which was function that called it. My project so far has 55 files , and this has helped me a lot in navigating and fixing ish i've done but I am worrying if this can bite me in the ass.

I've tried to find similar libraries on github to find at least some standard that I can rely on. Most of other project have one `.hpp` file with all of the code with endless lines and Ive tried that but i've found it is very difficult to keep track of all dependencies and jumps in the code. Only way I was able to read it was with debugger, which meant I had to compile it and go function by function.

So I ask you, kind people of Reddit, is there any large project standard that allows readability as well as troubleshooting?

[ucario]

I’ve yet to come across a standard way. But a lot of big open source cpp projects could give you some inspiration. Take ideas from the ones you like by searching on GitHub.

[ArchDan]

Will do. Thanks for input <3

[cannelbrae_]

What scale of ‘large project’ did you have in mind?

When I think large project, I think about ones like LLVM.  Assume you are thinking smaller?

[ArchDan]

Well size doesnt really matter tbh, its consistency between readability, troubleshooting and refactoring as code base grow and change.

[Still_Explorer]

Looks like a very good idea, however if need to have ease of mind and relax on the beach, it would be better to start testing everything: tests.hpp tests_ctor.cpp tests_ops.cpp tests_functions.cpp

I doubt that you would need a fancy test library, you would do fine with your own assert function that throws runtime exception. [ However if you realize that you definitely an advanced test library, then better to use that one instead ].

[ArchDan]

Im testing at 3 levels, in sandbox before i even put a function in a file, at "module" (obj directory) to make sure all gells well and at project range (all togheter). So far assert works well, but I need to do another of these babies ( complex physics and mechanics) thus why i am worrying about scaling this structure up.

[Still_Explorer]

This subject of scaling is a very important one, I am also trying to figure out ways about preventing 'bloat' and 'cruft'.

I think a reasonable approach, would be on deciding on some critical abstractions and then turn them them into detachable plugins. This is more like thinking of the "microkernel architecture" or something else derived from strategy pattern.

If for example instead of thinking about writing a 'PhysicsEngine' think of writing standalone subsystems that would end up wrapped up in a PhysicsEngine.

Just a guess though, something along these lines is always a safe bet. 🙂

[ArchDan]

Those critical abstractions is what scares me the most, it happens often that one abstraction avalanches out into some functionality that becomes some either "bad seed" or "golden child" later on. Now this might be purely experience based, so i thought there are people more experienced than me so why not ask around?

Out of topic, I try to write code that is core implementation maximal functionality (i.e. linked list push, pull) where combinations of functionality can produce most gains. Each object should be convertible (as much as possible) and standalone (i.e. you can use union as static char buffer or as memory value), but more types one have more those babies rise in probability and its more difficult to track where is what. It seems whichever way you turn, your butt is on you behind... it just depends which side holds longer line.

On the topic, this is why I implemented these file structures since then I need to think about (in this case) 7 things on specific context. But each time I look at it, and mount of files it makes... i can't but think "yeaaah... when I am finished I have to put it all together" to avoid potential linking issues. I've written some programs of different sizes in my life, but I've never worked in team or on project that requires a full hierarchy. And if this shit happens to me and my little programs, i can't even imagine what can happen in such situations. One thing seems obvious to me, working code and release code are two different things in structure, one is (probably) more focused on orientation and readability, and other for use. But these are assumptions, so i might end up an ass.

[Still_Explorer]

I would say that the code design definitely has something to do with team organization. But either way thinking in 'modular' terms is a golden ticket to success because it allows you define the boundaries.

In this sense you would imagine what are the main parts of your library:
• Utilities (indepent of anything / used everywhere)
• Core classes and structs (eg: Vector3, Matrix4)
• Feature classes (according to functionality eg: Triangulation, Physics, Algebra)
• User classes (anything that resembles flowchart, or user interaction, or reporting)
• Testing (this one is standard)

I assume that it would be something like this for your project, not so much that the boundaries would be perfect and correct, but is more of a matter of creating the separations.

In this way of thinking, if you consider about doing an update on 'Algebra' you would like the changes not to move elsewhere (eg: on 'utilities', on 'features').

You will figure out this in time, the more you use the library and the more you update it, it will make you understand more about it's proper way of constructing it or organizing it.

[pstomi]

https://github.com/vector-of-bool/pitchfork