Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AlignedStorage and InstanceStorage types #5426

Closed
wants to merge 1 commit into from

Conversation

radcapricorn
Copy link
Contributor

@radcapricorn radcapricorn commented May 24, 2017

These are two untyped storage types that can be used in Phobos
and in user code when there's a need for specific aligned space.
E.g. we could use this as static storage to emplace() objects
instead of allocating them with GC, where functions need to be made @nogc.

@radcapricorn
Copy link
Contributor Author

Not sure why tests would fail on win32. Can anyone offer insight?

std/typecons.d Outdated Show resolved Hide resolved
std/typecons.d Outdated Show resolved Hide resolved
@radcapricorn
Copy link
Contributor Author

Gah... So there is no way of telling at compile time whether invariants are enabled or not?

@MetaLang MetaLang added the @andralex Approval from Andrei is required label Aug 6, 2017
@MetaLang
Copy link
Member

MetaLang commented Aug 6, 2017

@andralex I tagged you because I can't remember if it's all Phobos symbols, or only std.algorithm/std.range that you want to be notified of.

Copy link
Member

@andralex andralex left a comment

Choose a reason for hiding this comment

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

What is the motivating case for this? How is it different from simply placing align(x) on the needed member?

std/typecons.d Show resolved Hide resolved
std/typecons.d Show resolved Hide resolved
std/typecons.d Show resolved Hide resolved
std/typecons.d Show resolved Hide resolved
@radcapricorn
Copy link
Contributor Author

@andralex This need not necessarily be a member, it could be a local, a global, an allocated storage...
I'll be fixing and rebasing this shortly.

@radcapricorn
Copy link
Contributor Author

@thewilsonator unstall please, I'm resuming this :)

std/typecons.d Outdated Show resolved Hide resolved
@thewilsonator
Copy link
Contributor

Please rebase it then ;)

@dlang-bot
Copy link
Contributor

Thanks for your pull request and interest in making D better, @radcapricorn! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

  • My PR is fully covered with tests (you can see the annotated coverage diff directly on GitHub with CodeCov's browser extension
  • My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
  • I have provided a detailed rationale explaining my changes
  • New or modified functions have Ddoc comments (with Params: and Returns:)

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 references

Your 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 locally

If 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 + phobos#5426"

@dlang-bot dlang-bot removed the stalled label Nov 28, 2018
@thewilsonator
Copy link
Contributor

std/typecons.d(9074:8)[warn]: Public declaration 'AlignedStorage' has no documented example.
std/typecons.d(9108:6)[warn]: Trusting a whole scope is a bad idea, `@trusted` should only be attached to the functions individually
std/typecons.d(9119:1)[warn]: A unittest should be annotated with at least @safe or @system
std/typecons.d(9128:1)[warn]: A unittest should be annotated with at least @safe or @system
std/typecons.d(9152:1)[warn]: A unittest should be annotated with at least @safe or @system
std/typecons.d(9171:10)[warn]: Public declaration 'InstanceStorage' has no documented example.
std/typecons.d(9171:33)[warn]: If constraints should have the same indentation as the function
std/typecons.d(9184:1)[warn]: A unittest should be annotated with at least @safe or @system
std/typecons.d(9194:1)[warn]: A unittest should be annotated with at least @safe or @system
std/typecons.d(9210:1)[warn]: A unittest should be annotated with at least @safe or @system
std/typecons.d(9232:1)[warn]: A unittest should be annotated with at least @safe or @system

These are two untyped storage types that can be used in Phobos
and in user code when there's a need for specific aligned space.
E.g. we could use this as static storage to emplace() objects
instead of allocating them with GC, where functions need to be made @nogc.

Added `cent` check, improved coverage.

unittest versioning; typo

Removed invariant test

cent fix

rebase, remove format

Example tests, style fixes
Copy link
Member

@andralex andralex left a comment

Choose a reason for hiding this comment

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

I think some serious convincing is needed on why this belongs in the standard library.

at compile time, an assert will be issued at runtime when a misaligned
AlignedStorage is used.
*/
struct AlignedStorage(size_t Size, size_t Alignment = platformAlignment)
Copy link
Member

Choose a reason for hiding this comment

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

This somewhat sophisticated API is ill-advised. We're looking at an "abstraction that doesn't abstract": a data member that is nominally private, yet trivially made public by means of accessors. There's no need for APIs for length, slicing etc because all they do is morally equivalent with:

struct AlignedStorage(size_t Size, size_t Alignment = platformAlignment)
{
    align(Alignment) void[Size] payload;
}

Everything needed is readily accessible by means of .payload. This also emphasizes the question of why we need to put in the standard library what's essentially a three-line trick.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

...with the exception of an invariant that safeguards against misaligned moves :)

For classes, the size and alignment of storage are the size and alignment
of class instance representation, not those of class reference.
*/
template InstanceStorage(T)
Copy link
Member

Choose a reason for hiding this comment

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

nicely done

static assert(InstanceStorage!Arbitrary.alignof == Arbitrary.alignof);
}

private size_t platformAlignment() @safe @nogc nothrow pure
Copy link
Member

Choose a reason for hiding this comment

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

I think we have something like this in std.experimental.allocator.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes. What would you suggest? Make this package and import in std.experimental.allocator? Or perhaps even public? User code could benefit from that information.

Copy link
Contributor

Choose a reason for hiding this comment

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

Is it public in std.experimental.allocator? If so public, if not package and unify the definitions.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is public.

}

InstanceStorage!SafeClass buf;
auto support = (() @trusted => cast(SafeClass) (buf.ptr))();
Copy link
Contributor

Choose a reason for hiding this comment

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

If this is the intended usage of InstanceStorage it seems to me that it would be better done as a type safe layer over AlignedStorage than simply an alias.

@radcapricorn
Copy link
Contributor Author

As far as convincing goes, there are already places in the standard library that use this kind of storage. Allocators is one, Scoped is the other. There may be more, this is just off the top of my head.

@RazvanN7
Copy link
Collaborator

RazvanN7 commented Oct 22, 2021

@andralex are you convinced about this addition?

@atilaneves What are your thoughts on this?

@radcapricorn you still need to fix some style issues for this to be ready to merge. Also, a changelog entry is required since you are adding new symbols.

@dlang-bot dlang-bot removed the stalled label Oct 22, 2021
@andralex
Copy link
Member

I'm unclear about (a) what the use cases are, and (b) how fit this API is for those. Far as I can tell the main use case is "I want inert storage fit for one object of a given type". If that's the case, all we need is:

union AlignedStorage(T) 
{
    private T unused = void;
}

Maybe we could promote that as an idiom instead of putting it in stdlib because it's an advanced systems use?

For class instances, it seems more difficult so maybe that would be worth finding a good API for. But even in that case, don't all classes have the same alignment (same as a pointer)? So an array of void* sized appropriately would work fine.

@atilaneves
Copy link
Contributor

@andralex are you convinced about this addition?

@atilaneves What are your thoughts on this?

@radcapricorn you still need to fix some style issues for this to be ready to merge. Also, a changelog entry is required since you are adding new symbols.

I don't think enough justification has been given for the inclusion of this in the standard library.

@RazvanN7
Copy link
Collaborator

@andralex @atilaneves The argument given by @radcapricorn is that the invariant safeguards against misaligned moves.

@atilaneves
Copy link
Contributor

@andralex @atilaneves The argument given by @radcapricorn is that the invariant safeguards against misaligned moves.

But why necessarily in the standard library?

@RazvanN7
Copy link
Collaborator

RazvanN7 commented Nov 4, 2021

I am going to close this as @radcapricorn seems to have abandoned it and @atilaneves and @andralex are against adding it to the standard library.

@radcapricorn please reopen if you ever turn back it.

@RazvanN7 RazvanN7 closed this Nov 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@andralex Approval from Andrei is required Atila Neves Enhancement
Projects
None yet
9 participants