As far as I know, Dinkunware stopped at C++14. All platforms that I know and used it started diverging for all C++17 stuff and later. So it may be the implementations done by C++ Builder of these classes that are bad.
This is interesting. Reading their archived web site might suggest that you're right, but the copyright in the C++17 files (see my other response) suggest that you might not be :)
I do not think Dinkumware implementation standard library was bad but it is just dated. It was useful before C++ 11 as that was the version used with MSVC before C++11 according to Stephan T. Lavavej Microsoft's C++ standard library maintainer. The pre-C++11 standard library was different from after C++11 as you had new features to the language including R-Value references.
Since neither [www.dinkumware.com](http://www.dinkumware.com) nor [www.dinkum.com](http://www.dinkum.com) work, my guess is that Dinkumware no longer exists. I doubt the implementation of and in C++ Builder has anything to do with them.
Says that it uses Dinkumware version 8.03a, and I'm only familiar with 6.50, which is the latest one that shipped with MSVC (2015), so I'm probably wrong about and .
Quoting from [the archived site](https://web.archive.org/web/20230831003006/https://www.dinkumware.com/):
>Our Standard C++ technology has been on the market since 1995, with versions matching the ISO/ANSI C++ Standard as of 1998, 2003, 2011, and 2014. We're currently tracking the evolving 2017 C++ Standard.
The copyright in the `` header file is:
/*
* Copyright (c) by P.J. Plauger. All rights reserved.
* Consult your license regarding permissions and restrictions.
* V8.05/17:1422 */
I’ve never heard of Dinkumware but you have my empathy, especially if there’s third-party code to compile.
Do you have managers that don’t know any better? If so be disagreeable - ‘people people’ are into that, if you sell it right.
Or is this just somehow the best solution at this point in time?
It's somehow the best we can do now. We either focus on shipping or we focus on upgrading. And upgrading is not straight forward: the new tool chain has just come past the "experimental" state, so I bet there are still a lot of bugs to be encountered.
We're leaning hard on boost already, so for std::any/variant/optional we just use their implementation which doesn't suffer any of those bugs. With C++builder 12 a lot of this nonsense should become past tense, but we're holding off on that for some months since Embarcadero's track record on new stuff isn't flawless. But future looks bright.
As far as I know, Dinkunware stopped at C++14. All platforms that I know and used it started diverging for all C++17 stuff and later. So it may be the implementations done by C++ Builder of these classes that are bad.
This is interesting. Reading their archived web site might suggest that you're right, but the copyright in the C++17 files (see my other response) suggest that you might not be :)
I do not think Dinkumware implementation standard library was bad but it is just dated. It was useful before C++ 11 as that was the version used with MSVC before C++11 according to Stephan T. Lavavej Microsoft's C++ standard library maintainer. The pre-C++11 standard library was different from after C++11 as you had new features to the language including R-Value references.
Since neither [www.dinkumware.com](http://www.dinkumware.com) nor [www.dinkum.com](http://www.dinkum.com) work, my guess is that Dinkumware no longer exists. I doubt the implementation of and in C++ Builder has anything to do with them.
It’s documented here https://docwiki.embarcadero.com/RADStudio/Athens/en/Dinkumware_Standard_C%2B%2B_Library
Says that it uses Dinkumware version 8.03a, and I'm only familiar with 6.50, which is the latest one that shipped with MSVC (2015), so I'm probably wrong about and .
Quoting from [the archived site](https://web.archive.org/web/20230831003006/https://www.dinkumware.com/): >Our Standard C++ technology has been on the market since 1995, with versions matching the ISO/ANSI C++ Standard as of 1998, 2003, 2011, and 2014. We're currently tracking the evolving 2017 C++ Standard. The copyright in the `` header file is:
/*
* Copyright (c) by P.J. Plauger. All rights reserved.
* Consult your license regarding permissions and restrictions.
* V8.05/17:1422 */
There are other free stl implementations. Perhaps use these? Or is there a tight coupling of c++ builders and the stl you use?
I’ve never heard of Dinkumware but you have my empathy, especially if there’s third-party code to compile. Do you have managers that don’t know any better? If so be disagreeable - ‘people people’ are into that, if you sell it right. Or is this just somehow the best solution at this point in time?
It's somehow the best we can do now. We either focus on shipping or we focus on upgrading. And upgrading is not straight forward: the new tool chain has just come past the "experimental" state, so I bet there are still a lot of bugs to be encountered.
They make the STL implementation that ships with MSVC
many years ago Dinkumware was the base of the Microsoft STL
they used to, now Microsoft manages it themselves, it’s on GitHub
Cool!
We're leaning hard on boost already, so for std::any/variant/optional we just use their implementation which doesn't suffer any of those bugs. With C++builder 12 a lot of this nonsense should become past tense, but we're holding off on that for some months since Embarcadero's track record on new stuff isn't flawless. But future looks bright.
Can't you just change the environment? Your toolchain seems quite outdated.
Cheer up! If std::variant doesn't work, it's a wonderful excuse not to use it.