To STL or NOT to STL?

Compilation and installation of DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
konis
Posts: 28
Joined: Mon, 2015-11-23, 16:05

To STL or NOT to STL?

#1 Post by konis » Tue, 2019-06-25, 17:31

I always wondered whether I have to enable the use of native STL or not in CMake. So I decided to ask the forum:

Are they any known advantages and/or disadvantages for using the native STL functions instead of the DCMTK's ?
This is for developing on macOS and Windows.

Thank you.

Jan Schlamelcher
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 318
Joined: Mon, 2014-03-03, 09:51
Location: Oldenburg, Germany

Re: To STL or NOT to STL?

#2 Post by Jan Schlamelcher » Wed, 2019-06-26, 16:32

There is no simple answer to this question, it is one of those classical "that depends" cases. I'll try to list the pros and cons that I know:

pro ofstd:
- It's more stable, i.e. its point is to work as closely to the same on different compilers, platforms and operating systems as possible. While this is (of course) also true for the C++ STL specification inside the C++ standard, it is - sadly - not always true in reality. Especially old versions of Visual Studio come to mind where the STL implementation was "traditionally" catastrophic.
- It's hand tailored for DCMTK, i.e. ofstd is also not a 100% compatible to the C++ specification, but it is 100% compatible to DCMTK.
- We won't break your code: While the STL also is as stable as can be, a standard may always contain some potential for misunderstandings. If a compiler implements something the wrong way and this get clarified, they have to adjust the implementation to be conformant to the C++ standard, potentially breaking your code. Since we @DCMTK never claimed to be 100% conformant, we have the luxury to weight conformity against the (very reasonable) policy to never break the user experience.

con ofstd / pro STL:
- it's slow and inefficient: we implement things under time constraints in a "functionality first" manner. For example our <map> implementation OFMap is based on a linked list instead of an rbtree as it should be, i.e. instead of O(log N) search and insert you get O(N) and a lot of cache misses.
- there is some conversion overhead if you use the C++ STL in your code. This is not only about lost performance, but also about you having to write some glue code occasionally.
- it's not 100% compatible to the C++ standard. This has two effects: 1. you have to read the documentation carefully even if you know the STL by heart, otherwise you might miss subtle differences. 2. It worsens the issue above.

If I missed anything, feel free to amend everyone!

konis
Posts: 28
Joined: Mon, 2015-11-23, 16:05

Re: To STL or NOT to STL?

#3 Post by konis » Thu, 2019-06-27, 12:50

Jan,

Thank you for your time and insight.

As I see it, there is no tremendous reason to use STL over DCMTK. Personally I'll go for stability instead of speed, especially when dealing with a complex problem like DICOM.

Jan Schlamelcher
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 318
Joined: Mon, 2014-03-03, 09:51
Location: Oldenburg, Germany

Re: To STL or NOT to STL?

#4 Post by Jan Schlamelcher » Thu, 2019-06-27, 13:22

Sure, otherwise there would be no point in us still working on extending it, right ;-). One thing should be clear though: most modern compilers (e.g. Clang and GCC, recent versions of Visual Studio) have a good STL implementation. Also, DCMTK has configure tests, such that, if you enable the STL, only the components that work as expected will actually be enabled with the rest falling back to ofstd anyway. So, while it's right that you are trading performance for stability, you should know that you are trading a lot of performance for just a little bit of stability.

konis
Posts: 28
Joined: Mon, 2015-11-23, 16:05

Re: To STL or NOT to STL?

#5 Post by konis » Thu, 2019-06-27, 13:33

Jan, your efforts are certainly appreciated.
But you opened my appetite for adventure. If there is 'a lot' of performance to be gained I think I will switch it on 8) . We are in the process of dropping support for older macOS and Windows versions so we can assume reasonable support for STL in Xcode v10 and Visual Studio 2017.

Jan Schlamelcher
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 318
Joined: Mon, 2014-03-03, 09:51
Location: Oldenburg, Germany

Re: To STL or NOT to STL?

#6 Post by Jan Schlamelcher » Thu, 2019-06-27, 14:18

I would expect that to work, at least the unit tests succeed. Look at the nightly builds, in particular the ones for
AppleClang 10.0.1 and Visual Studio 2017

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest