6 ms·
We do use templates in our containers: https://github.com/scalien/scaliendb/tree/master/src/System/Containers https://github.com/scalien/scaliendb/tree/master/
by Maro 16y ago
We do use templates in our containers:
https://github.com/scalien/scaliendb/tree/master/src/System/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.
- JoeAltmaier 16y agoFolks 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.
- agazso 16y agoAlso don't forget licensing issues. It becomes important when you make a living of selling software.
- dkersten 16y agoC++ Standard Library and Boost are of very high quality. It's quite tough to beat them.
- JoeAltmaier 16y agoOn major platforms. But on embedded etc its hard to use any library - there are unintended dependencies. { embedded programmer }
- dkersten 16y agoSure. 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.
- deleted 16y ago[deleted]
- yannickt 16y agoThings 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.
- dkarl 16y agoPlus 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.
- dkersten 16y agoSimilarly, you can extend them (or at least make your own code compatible).
- yannickt 16y agoThe 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.
- dkersten 16y agoThe STL is not a third party library anymore - its part of the langauge just as much as the C++ runtime is.
- sausagefeet 16y agoAvoiding 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.