Hacker News Reader

Comment by Maro | Hacker News Reader

We do use templates in our containers:

https://github.com/scalien/scaliendb/tree/master/src/System/...

Yes, we try to avoid op.overloading, exceptions, and we explicitly don't use the STL, Boost, <any library>. All the code is ours, which is really nice if you're debugging, finding performance problems, etc. It was our experience on previous projects that pulling in outside libraries in a systems level project like a database ends up wasting time (spent in understanding, debugging and optimizing outside code) over just writing what you need. This has proven to be a good call, we fix all bugs, however deep or nasty very quickly.

Thanks for the UnitTest++ tip.

View on HN

The STL is not a third party library anymore and most of it has been part of the standard for several years now. I would be curious to know what problems did you have with the STL, and how long ago? In my experience most people who refused to use the STL did it for the wrong reasons. Even the EASTL (which makes a good case against the standard library implementations) implements the STL interface.

The STL is not a third party library anymore - its part of the langauge just as much as the C++ runtime is.

Folks might accuse you of NIH, but the quality of outside libraries is variable, suitable for a prototype but for shipping code you need control of ALL of it.

C++ Standard Library and Boost are of very high quality. It's quite tough to beat them.

Plus they're open-source, so they're theoretically "yours" in the sense that you can compile and deploy your own. If you find a bug in Boost, you can fix it. We frequently deploy open-source libraries we've patched ourselves -- never Boost that I know of, but at least we know it wouldn't be a problem.

Similarly, you can extend them (or at least make your own code compatible).

Things like move semantics and r-value references in C++1x will make them much tougher to beat. And for the most part they're not particularly hard to understand either. The standard library in particular, despite being a generalized library, is highly customizable and can be optimized for special cases (e.g. with custom character traits or allocators). Because it's a standard, good C++ developers should be able to use it. But if everyone reinvents the wheel developers would have to learn a new container or string interface every time they change jobs.

On major platforms. But on embedded etc its hard to use any library - there are unintended dependencies.

{ embedded programmer }

Sure. You definitely have a point, but in context of the discussion here (ie Maro's code), I see no evidence that he is programming for an embedded system.

Also don't forget licensing issues. It becomes important when you make a living of selling software.

Avoiding all other libraries seems an odd choice to me. Are you including std::string in "STL"? Almost all of the "STL" containers are part of the C++ standard now so not using them doesn't make a lot of sense.

Reply on news.ycombinator.com