Skip to content
This repository was archived by the owner on Oct 12, 2022. It is now read-only.

Conversation

WalterBright
Copy link
Member

gotta start somewhere

@WalterBright WalterBright force-pushed the typeinfo branch 2 times, most recently from bffe371 to 8a20d4d Compare January 19, 2016 05:10

module core.stdcpp.exception;

version (DigitalMars) version (_Win32)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Debug code? CRuntime_DigitalMars is predefined, and _Win32 is not.

@rainers
Copy link
Member

rainers commented Jan 19, 2016

No update to MANIFEST? I guess we can nuke it then ;-)

@WalterBright
Copy link
Member Author

No update to MANIFEST? I guess we can nuke it then ;-)

Yeah, I gave up on it. If you want to do a PR to nuke it, I'll pull it.

{
void dtor1(); // consume destructor slot in vtbl[]
void dtor2(); // consume destructor slot in vtbl[]
final const(char)* name();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you declares final method, you add dependence from libstdc++, because this external symbol should be resolved by linker. Is it ok?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's why it is currently not compiled into the library. In the future, it should be compiled into the .a, but not the .so.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds complicated. Then you can use core.stdcpp with static linking, but not with dynamic linking?
But as druntime won't use core.stdcpp internally, how about putting all core.stdcpp modules into a extra library, stdcpp. We can still ship this library with dmd. Then users using core.stdcpp simply add -lstdcpp to their linker flags and users not needing core.stdcpp never get a dependency on libstdc++.


class exception
{
this();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest to add empty bodies or bodies with {assert(0);} to all costructors declarations.
Also we may use @disable attribute for all unavailable methods. It will be better then strange linkage error on constructor using.

@rainers rainers mentioned this pull request Jan 21, 2016
@rainers
Copy link
Member

rainers commented Jan 21, 2016

No update to MANIFEST? I guess we can nuke it then ;-)

Yeah, I gave up on it. If you want to do a PR to nuke it, I'll pull it.

Great! Here it is: #1476

@JakobOvrum
Copy link

I agree that @disable is marginally better than the current linker errors for unsupported operators like constructors.

{
void* pdata;

public:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah half indent has to go

@andralex
Copy link
Member

Auto-merge toggled on

andralex added a commit that referenced this pull request Feb 12, 2016
add core.stdcpp.exception and core.stdcpp.typeinfo
@andralex andralex merged commit 30f8c1a into dlang:master Feb 12, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants