Updated the STL branch #2211
Updated the STL branch #2211
Conversation
|
Thanks for your pull request and interest in making D better, @TurkeyMan! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please see CONTRIBUTING.md for more information. If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment. Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. Testing this PR locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub fetch digger
dub run digger -- build "master + druntime#2211" |
TurkeyMan
requested review from
andralex,
WalterBright and
wilzbach
as code owners
TurkeyMan
force-pushed
the
stdcpp
branch
2 times, most recently
from
29a8b66
to
ee8a696
Compare
|
Totally depends on: |
|
This is awesome that you get some time to work on this. |
src/core/stdcpp/string.d
Outdated
| module core.stdcpp.string; | ||
|
|
||
| /** | ||
| * Because of broken name mangling of extern C++, this file is only available |
There was a problem hiding this comment.
I guess this is no longer relevant, or is it?
| /////////////////////////////////////////////////////////////////////////////// | ||
| // std::string declaration. | ||
| // | ||
| // Current caveats : |
There was a problem hiding this comment.
This may be revisited as well.
| /////////////////////////////////////////////////////////////////////////////// | ||
| // std::vector declaration. | ||
| // | ||
| // Current caveats : |
|
Yeah, I've been working on the mangling the C++ compatibility in DMD for weeks! PR's welcome! :P |
|
There's crap loads of methods missing from those classes still. And basically every ptr+len method should get an additional |
TurkeyMan
force-pushed
the
stdcpp
branch
2 times, most recently
from
01f84bb
to
3f1a3e3
Compare
I've been there. Did you manage to get all the tests here pass? |
|
I didn't know they existed! You're hiding them in your fork ;) |
src/core/stdcpp/vector.d
Outdated
|
|
||
| // D helpers | ||
| alias as_array this; | ||
| extern(D) T[] as_array() { return data()[0 .. size()]; } |
There was a problem hiding this comment.
no way! this is C++, lower_snake_case.
| /** | ||
| * D header file for interaction with C++ std::string. | ||
| * | ||
| * Copyright: Copyright Guillaume Chatelet 2014 - 2015. |
There was a problem hiding this comment.
If possible maybe assign the copyright to the D Language Foundation.
CC @gchatelet
There was a problem hiding this comment.
Sure, I respected the style that was in place back then but feel free to change it to whatever is needed.
src/core/stdcpp/string.d
Outdated
|
|
||
| // D helpers | ||
| alias as_array this; | ||
| extern(D) T[] as_array() { return data()[0 .. size()]; } |
There was a problem hiding this comment.
I'm not mixing naming standards within a single class!
|
BTW not sure whether you are aware of it, there's also an existing PR for std.pair: #1802 |
|
Yeah I think this is C++... |
|
I think we should restrict ourselves to the strict requirement for compatibility for the moment. Until someone depends on it, there's no point in beautifying it. |
|
'beautifying' what? |
|
Blocked by https://issues.dlang.org/show_bug.cgi?id=16479 (unless you want to merge this without tests ;) ) |
|
I don't think the different C++ standard library implementations vary much, but it might be an ongoing effort to actually get things to work (by which I mean "not have bugs" - I'm sure that |
|
The implementations don't vary at all from the front-end perspective... that's the definition of 'standard' ;) I'm not sure druntime should depend on dpp, I think it's too important to have a controversial dependency like that. |
|
I'm not even sure this should live in Druntime TBH. It will bring its own set of maintenance issues, and I'm not sure tying those to the release schedule / requirements of druntime makes sense. We do have the C binding here, but they are used by the runtime. |
|
Well... it's already there. dub... sigh |
|
Yeah, where does it end? Since D can interface with Objective-C, does that mean we add bindings to the whole Apple SDK as well (rhetorical question). |
|
The C bindings that druntime has are the bindings for the OS, and IMHO, it makes a lot of sense for them to be there. Binding random third party libraries (be they C or otherwise) on the other hand, really doesn't make sense. Those should be in 3rd party packages. As for C++'s standard library, I don't know. In principle it would be nice to have all of that tightly integrated enough that you can trivially use C++ from D, but I don't know if it makes the most sense for them to be in druntime once you start considering some of the practical issues - especially since we have not taken the approach of outright building a C++ compiler into the D compiler. |
What issue are you trying to address, and how does that help with calling into the C++ library? |
Except it is. And different system will have different implementations and/or version, which will make it all the harder to test and maintain. Over the short lifespan of |
|
@TurkeyMan The front-end (i.e. the interface) might not change, but the layouts might. That's also important to declare properly. And that's ignoring that there's more than one C++ version, and the interface to the standard library most definitely does change between them. Which version of Then there's the fact that the headers look differently depending on preprocessor defines. Should we have version blocks for all of those despite the combinatorial explosion? And again, for which version (the headers change as compilers get updated)? I'm not even getting close to suggesting that dpp be part of the runtime, I'm just saying that trying to put the C++ stdlib in druntime has many, many issues. This isn't to say it shouldn't be done. But if it is, it will be lacking. |
|
I appreciate every point you make. I never said it was simple, but I also think you might be slightly over-complicating it though. All D compilers have an implied complementary C++ compiler; the D compilers For GDC, that's easy, since a version of GDC is married to a version of GCC. For any GDC build, DMD is curious; on Windows, just support what's current, ie, what MS is currently supporting, since that's what DMD tracks. Posix DMD is the only question mark... what C++ compiler is DMD most likely to be used in conjunction with? (What C++ compilers are guaranteed ABI compatible with DMD? is it DMC?), and choose that compiler. This is the only case where I can see an awkward STL version situation potentially emerging, and hopefully the number of versions remains low. Obviously the unit tests would prove So, since If |
|
When the complimentary compilers are gcc and clang, passing For all I know the mangling changes and you'd get linker errors. I'm not sure, but I also wouldn't be surprised. |
|
Oh, and keeping the D declarations of C++ standard library classes up-to-date with the corresponding compiler would be painful. |
|
Right, and we may want to support There are some practical truth's that help us:
But necessary, fortunately it's very easy to unit-test! |
|
Clang recently (6.0.0) switched from GNU++98 to GNU++14. I’m not a C++ expert but this might have changed the ABI because I don’t think the small string optimization is allowed anymore. |
|
That change will probably have also enabled RVO by default, which is awesome, because it will match D now ;) |
|
Another problem is that on macOS using Clang bundled with Xcode, it's difficult to know which upstream version Apple's fork corresponds to. |
|
Fortunately, apple's distro is so closed and proprietary, that matching what they're up to should be even simpler than MSVC. It all just seems like a big effort in unit-testing. |
Technically it's a mixed environment. Most of the Unix/Posix environment and the kernel is open source, then they build closed and proprietary code on top of that. Here's the source code for Apple's fork of Clang [1]. [1] https://opensource.apple.com/source/clang/clang-800.0.42.1/ |
Not necessary once dpp can handle C++ well ;) As for everything else, you make good points. I'm still wary that this might fail in mysterious and subtle ways. The only way to properly test this will be to use all possible compilers with all versions of Maybe there should be a |
We're not writing a C++ compiler; I don't think there's intent to adopt C++'s I suspect moments where our interesting subset of the ABI are broken are rare thought, and a broad range of recent C++ does occasionally break the user-facing API/ABI, but if we are just linking to the core allocation functions, and we must maintain a matching struct (rarely if ever changes), then we should have a pretty good chance of doing a fairly robust job. Most of the trivia functions should be implemented in D for inlining's sake, and since we have different/superior semantics anyway. |
TurkeyMan
force-pushed
the
stdcpp
branch
2 times, most recently
from
10c9bfb
to
34b05dc
Compare
|
Do you want to keep this open, given that we've been merging smaller-sized PRs over the past months ? |
|
Yes, I'd like to keep it open until all of its contents have been merged, its much easier to find an open PR than a closed one.. |
|
@thewilsonator what is the status on this? Can we close this? |
Resurrected @gchatelet's STL branch