opencog / cogutil

Very low-level C++ programming utilities used by several components

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

minimize/avoid using boost in cogutil

linas opened this issue · comments

Boost header files in the cogutils header files are polluting downstream code (atomspace, opencog). We should try hard to avoid using boost. Its low-quality code, buggy, with assorted issues. In most cases, we don't actually need it for anything.

Today, fyi, its opencog/util/Counter.h which is causing the issues - it got included in Handle.h, and thus spread to code everywhere. Surely there is some much simpler, more elegant way of solving this problem, than to use boost.

What problem does it cause?

@linas you keep repeating that we shouldn't use boost, that it is badly written and such. Personally the only issue I remember having was boost.graph, some naming clash that has been fixed years ago.

I mean if some boost implementation is too inefficient, sure let's use something else, but I don't think it's enough to turn down boost. Some things are extremely useful like boost.operators and boost.range, both used in the Counter code for instance. They save a great deal of code and I doubt they are inefficient (not test them though, I just think they are sufficiently simple that one can hardly code them inefficiently.)

It just creates crazy bugs, hard-to-debug scenarios, cryptic error messages. As to efficiency/bugginess, the few times I've dived into boost code, it became clear that it was written by people who weren't good c++ programmers, and kind-of didn't know what they were doing. There's no quality-control in the boost libs, they accept whatever some college student created for some class assignment. Its a hassle; avoid the hassle.

at any rate, we should not be putting boost includes into header files. For the example of Counter, it ended up in Handle.h, and then ended up everywhere in opencog. So I lost time last night trying to figure out why things broke because of this. Header files should be minimal, and only define/export what they promise to define/export, and not other unrelated functions.

I agree about avoiding unnecessary includes (boost or else), for Counter it is impossible to avoid because it relies on boost.operator to define the class. However, if you'd like I can move the definition of HandleCounter out of Handle.h as it seems to be used only in the URE.