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

Interest in stack_array? #134

Closed
trebconnell opened this issue Oct 8, 2015 · 4 comments
Closed

Interest in stack_array? #134

trebconnell opened this issue Oct 8, 2015 · 4 comments
Labels

Comments

@trebconnell
Copy link
Contributor

I'm interested in writing a preliminary stack_array using _alloca and alloca from windows and linux respectively. Is this worth pursuing or would it be better to wait for a more fleshed out gsl standard?

@gdr-at-ms
Copy link
Member

The tricky part is how to do it without running afoul of the fact that alloca() extends the caller’s activation record (which will be the constructor’s), as opposed to the caller of the caller (i.e. the function declaring the variable of type stack_array). i.e. the desired effect.

From: Treb Connell [mailto:notifications@github.com]
Sent: Thursday, October 8, 2015 1:21 PM
To: Microsoft/GSL GSL@noreply.github.com
Subject: [GSL] Interest in stack_array? (#134)

I'm interested in writing a preliminary stack_array using _alloca and alloca from windows and linux respectively. Is this worth pursuing or would it be better to wait for a more fleshed out gsl standard?


Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fMicrosoft%2fGSL%2fissues%2f134&data=01%7c01%7cgdr%40microsoft.com%7c7fe3943d38944ed0826508d2d01df4d7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=i2VVhW%2b8GKhzl%2bKUwBS3FuqnTrw4MG0KFBJbumqFj0s%3d.

@trebconnell
Copy link
Contributor Author

That's a very good point. I can't think of a good way around that except
to force the compiler to inline the constructor, but there's no good way to
do this.

__forceinline which's the closest thing to that for MSVC won't work
because: "The compiler cannot inline a function if: The function or its
caller is compiled with /Ob0 (the default option for debug builds).",

On Thu, Oct 8, 2015 at 1:25 PM Gabriel Dos Reis notifications@github.com
wrote:

The tricky part is how to do it without running afoul of the fact that
alloca() extends the caller’s activation record (which will be the
constructor’s), as opposed to the caller of the caller (i.e. the function
declaring the variable of type stack_array). i.e. the desired effect.

From: Treb Connell [mailto:notifications@github.com]
Sent: Thursday, October 8, 2015 1:21 PM
To: Microsoft/GSL GSL@noreply.github.com
Subject: [GSL] Interest in stack_array? (#134)

I'm interested in writing a preliminary stack_array using _alloca and
alloca from windows and linux respectively. Is this worth pursuing or would
it be better to wait for a more fleshed out gsl standard?


Reply to this email directly or view it on GitHub<
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fMicrosoft%2fGSL%2fissues%2f134&data=01%7c01%7cgdr%40microsoft.com%7c7fe3943d38944ed0826508d2d01df4d7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=i2VVhW%2b8GKhzl%2bKUwBS3FuqnTrw4MG0KFBJbumqFj0s%3d>.


Reply to this email directly or view it on GitHub
#134 (comment).

@gdr-at-ms
Copy link
Member

I believe GCC also places constraints on functions containing alloca.

-------- Original message --------
From: Treb Connell notifications@github.com
Date: 10/8/2015 1:33 PM (GMT-08:00)
To: Microsoft/GSL GSL@noreply.github.com
Cc: Gabriel Dos Reis gdr@microsoft.com
Subject: Re: [GSL] Interest in stack_array? (#134)

That's a very good point. I can't think of a good way around that except
to force the compiler to inline the constructor, but there's no good way to
do this.

__forceinline which's the closest thing to that for MSVC won't work
because: "The compiler cannot inline a function if: The function or its
caller is compiled with /Ob0 (the default option for debug builds).",

On Thu, Oct 8, 2015 at 1:25 PM Gabriel Dos Reis notifications@github.com
wrote:

The tricky part is how to do it without running afoul of the fact that
alloca() extends the caller's activation record (which will be the
constructor's), as opposed to the caller of the caller (i.e. the function
declaring the variable of type stack_array). i.e. the desired effect.

From: Treb Connell [mailto:notifications@github.com]
Sent: Thursday, October 8, 2015 1:21 PM
To: Microsoft/GSL GSL@noreply.github.com
Subject: [GSL] Interest in stack_array? (#134)

I'm interested in writing a preliminary stack_array using _alloca and
alloca from windows and linux respectively. Is this worth pursuing or would
it be better to wait for a more fleshed out gsl standard?

Reply to this email directly or view it on GitHub<
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fMicrosoft%2fGSL%2fissues%2f134&data=01%7c01%7cgdr%40microsoft.com%7c7fe3943d38944ed0826508d2d01df4d7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=i2VVhW%2b8GKhzl%2bKUwBS3FuqnTrw4MG0KFBJbumqFj0s%3d>.

Reply to this email directly or view it on GitHub
#134 (comment).

Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fMicrosoft%2fGSL%2fissues%2f134%23issuecomment-146677786&data=01%7c01%7cgdr%40microsoft.com%7ccabe0c0e694948cdb32b08d2d01fbac8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kjCSM9uKnbyLxxjulsa3%2f7dmrGS7Ukc9pKs6yHG08sw%3d.

@neilmacintosh
Copy link
Collaborator

So to respond to your original question @trebconnell....yes, you would probably find it more useful to wait for a clearer GSL specification before you spend time trying to implement missing parts of it like stack_array. In the case of stack_array, I think one of the hurdles you will face is the ability to write an implementation that is compatible with compilers of target platforms and their ABI requirements.

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

No branches or pull requests

3 participants