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

Make array CTFE-able #1213

Closed
wants to merge 4 commits into from
Closed

Make array CTFE-able #1213

wants to merge 4 commits into from

Conversation

monarchdodra
Copy link
Collaborator

From the conversation over at: http://forum.dlang.org/thread/uhvwbttbxxqzgculaacb@forum.dlang.org?page=3#post-ki84nc:2429ns:241:40digitalmars.com

All it actually took was changing the underlying uninitializedArray implementation to actually make it work.

Note that the final result in regards to Type support will depend on if/when we pull my Emplace + Array improvements get pulled:

In any case, it's nothing that can be fixed dirrectly inside array.


I also took this opportunity to improve and fix arrayAllocImpl:

  1. minimallyInitializedArray was only minimally intialized when 1 level deep. It now correctly works for any level of deepness.
  2. If the array is going to be initialized with T.init anyways, then we call new T[] directly, instead of doing the redundant malloc + ret[] = T.init;

@dnadlinger
Copy link
Member

Could you open a Bugzilla issue for the minimallyInitializedArray issue so it appears in the changelog? Thanks!

@monarchdodra
Copy link
Collaborator Author

Could you open a Bugzilla issue for the minimallyInitializedArray issue so it appears in the changelog? Thanks!

Absolutly. I'll do it first thing tomorrow morning.

@monarchdodra
Copy link
Collaborator Author

Bug report:

http://d.puremagic.com/issues/show_bug.cgi?id=9803

I'll tie the unittest to the report tomorrow.

@monarchdodra
Copy link
Collaborator Author

That should do it?

also improve arrayAllocImpl, and bugfix + unittest
"greatly" Simplifies implementation, while increasing efficiency. Also makes function @safe when initialization occurs.
@monarchdodra
Copy link
Collaborator Author

I ended up modifying the implementation some more, which should make it both simpler and more robust. Basically, if initialization is needed, then we just call new, instead of being fancy and doing it (potentially slower) by hand. An added perk is that if initialization does occur, then minimallyInitializedArray is actually safe.

I wrote NElementEncodingType right under nDimensions. I don't think we had anything equivalent before...?

@andralex
Copy link
Member

OK so now should we close this?

@dnadlinger
Copy link
Member

AFAIR it contains additional bug fixes.

static assert(nDimensions!(uint[]) == 1);
static assert(nDimensions!(float[][]) == 2);
}

// Returns the element type of the nDimension array T.
private template NElementEncodingType(T, size_t N)
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 it's easy to do this without an explicit N.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Well, it would be easy if the N was always the total depth. But in this case, it represents a user defined depth-terminator, eg. if one wants to allocate an array whose elements are arrays themselves. For example, when one calls:

minimallyArray!(int[][][])(5, 5);

Then we use NElementEncodingType!(int[][][], 2) to know that the "ElementType" is int[] (and not int). So we can't do without that information.

@monarchdodra
Copy link
Collaborator Author

This needs more review, given the recent changes, so I'm closing for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants