Allow access to std::array's underlying C-array

[d...@soundradix.com]

Following my question on SO, I'd like to propose changing the data() method of std::array to return a reference to the underlying C-array instead of returning a raw pointer.

This would allow backwards compatibility with older functions which accept a reference/pointer to a C-array of a known size.

Currently, if you use an std::array, and have such a function, there is no way AFAIK to call it on the underlying C-array without a reinterpret_cast.

I see no real disadvantage to this change - if you really want, you can always decay the C-array reference to a raw pointer reference.

Or at least, in case it's considered valuable to keep the data() method which returns the raw pointer by value, I suggest adding a c_array() method instead which returns a reference to the C-array.

Dan

[Daniel Krügler]

Exactly this had been suggested in the past, but failed:

http://cplusplus.github.io/LWG/lwg-closed.html#930

If you want it, this requires a proposal. Some previous arguments
against it ("[..] until we have implementation experience with
reference qualifiers") are mood now, but nonetheless the proposal
should try to give a good rationale for it.

Thanks,

- Daniel

[Vicente J. Botet Escriba]

+1 for specific c_array functions or direct access to the data (There is
no invariant in this class that the user can break by having a direct
access to the data)

Vicente

[d...@soundradix.com]

Exactly this had been suggested in the past, but failed:

http://cplusplus.github.io/LWG/lwg-closed.html#930

Thanks for the reference!

I see the resolution for closing the issue as "Not a Defect" says the following:

"There are known other ways to do this, such as small inline conversion functions."

What other ways are there to do this? Specifically, what "small inline conversion functions" exist to get the C array from the std::array?

I assume they just mean a function which reinterpret_casts the raw pointer returned by data() to an array of the right size, or am I missing something?

Thanks,

Dan

[Erich Keane]

The notes on this don't seem to mention what said small inline conversion function might look like.

My quick & dirty solution is something like this:

template<typename T, size_t N>                                            
auto inline array_convert(const std::array<T,N>& array) -> const T(&)[N] {
  return reinterpret_cast<const T(&)[N]>(*array.data());                  

[jgot...@gmail.com]

On Wednesday, March 8, 2017 at 7:04:03 PM UTC-5, Erich Keane wrote:

The notes on this don't seem to mention what said small inline conversion function might look like.

My quick & dirty solution is something like this:

template<typename T, size_t N>                                            
auto inline array_convert(const std::array<T,N>& array) -> const T(&)[N] {
  return reinterpret_cast<const T(&)[N]>(*array.data());                  
}

If that's all we can do, I suggest you refile the issue.  A reinterpret_cast can't be used inside a constexpr function.

Joe Gottman

[Zhihao Yuan]

On Wed, Mar 8, 2017 at 8:27 PM, <jgot...@gmail.com> wrote:
>
>
> If that's all we can do, I suggest you refile the issue. A reinterpret_cast
> can't be used inside a constexpr function.

std::array is an aggregate, meaning its C array data
member has to be public. So

template <typename T, size_t N>

constexpr auto& c_array(std::array<T, N>& a)
{
#if defined(_MSC_VER)
return a._Elems;
#elif defined(_LIBCPP_VERSION)
return a.__elems_;
#elif defined(__GLIBCXX__)
return a._M_elems;
#else
#error "unknown standard library"
#endif
}

Worth standardization, but I may just end up
rewriting my API :/

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/

[Dan Raviv]

Is there any available procedure to request re-opening this LWG issue instead of making a new proposal?

Thanks,

Dan

[Daniel Krügler]

2017-03-09 20:04 GMT+01:00 Dan Raviv <dan....@gmail.com>:
> Is there any available procedure to request re-opening this LWG issue
> instead of making a new proposal?

It is possible to reopen an issue, but there must be very good reasons
for this, e.g. absolutely new insight into that matter or something
like that. I don't see currently such overwhelmingly new information
available. The good news are: It is definitively *not* necessary to
reopen the issue when you write a paper. And I strongly recommend a
proposal, because a proposal has more room for rationale than an
issue. Sometimes an issue is closed as NAD with the explicit remark
that future papers are invited (The lack of such a remark is no
indication that the committee has no interest). Please write such a
paper and *mention* the issue. If you can, disproof the arguments
provided in the issue comments.

Writing a paper is not hard - just do it. If you cannot participate a
meeting by yourself, you should ask for a proxy, but that proxy search
is not relevant at the beginning of a proposal.

> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2ed46a06-a374-4e29-bd2b-be1cfa01b862%40isocpp.org.



--

________________________________
SavedURI :Show URLShow URLSavedURI :
SavedURI :Hide URLHide URLSavedURI :
https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.de.LEt2fN4ilLE.O/m=m_i,t,it/am=OCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=h/d=1/rs=AItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=1395770800154https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.de.LEt2fN4ilLE.O/m=m_i,t,it/am=OCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=h/d=1/rs=AItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=1395770800154
________________________________

[Dan Raviv]

Attached a first draft of a proposal to add a c_array method to std::array which returns a reference to the wrapped C-array.

Comments would be much appreciated. :)

Thanks,

Dan

[jgot...@gmail.com]

I have a couple of minor comments:

1. Instead of using a typedef, define c_array_type by
   
   using c_array_type = T[N];
   
2. Your non-const lvalue ref function needs to be defined as
   
   constexpr c_array_type& c_array() &;
   
   Note the ampersand at the end.
   
   Joe Gottman
   
   
   

[Dan Raviv]

1. I also prefer 'using' over 'typedef', but the standard as well as clang's standard library seem to still use typedefs. No?

2. Indeed, thanks!

Dan

[Daniel Krügler]

2017-03-15 9:16 GMT+01:00 Dan Raviv <dan....@gmail.com>:
> 1. I also prefer 'using' over 'typedef', but the standard as well as clang's
> standard library seem to still use typedefs. No?

What kind of type-alias form an existing real-world library uses, is
irrelevant for a proposal. For specification purposes the Standard
Library now always 'using' instead of 'typedef' (at least for all
newer parts).

- Daniel

[Dan Raviv]

Ok, good to know.

Thanks,

Dan

[Dan Raviv]

Attached a second draft of the proposal with fixes:

1) Use 'using' instead of 'typedef' for defining c_array_type.

2) Added missing lvalue reference qualifiers in c_array methods overloads.

3) Added acknowledgements to contributors on the newsgroup; thanks! :)

Comments would be much appreciated.

Cheers,

Dan

[Dan Raviv]

Attached formal proposal draft.

Not sure who I should list as the audience - as a minor addition proposal to the standard library, should this be addressed to LEWG, LWG or both?

Thanks,

Dan

[Jonathan Coe]

On 30 March 2017 at 14:11, Dan Raviv <dan....@gmail.com> wrote:

Attached formal proposal draft.

Not sure who I should list as the audience - as a minor addition proposal to the standard library, should this be addressed to LEWG, LWG or both?

I think it should go to LEWG then LWG.

best,

Jon

 

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bad4d03f-0dda-4cb3-bc01-af27f7c4d824%40isocpp.org.

[Ville Voutilainen]

On 30 March 2017 at 16:35, Jonathan Coe <jonath...@gmail.com> wrote:
> On 30 March 2017 at 14:11, Dan Raviv <dan....@gmail.com> wrote:
>>
>> Attached formal proposal draft.
>> Not sure who I should list as the audience - as a minor addition proposal
>> to the standard library, should this be addressed to LEWG, LWG or both?
>
>
> I think it should go to LEWG then LWG.

Correct; first audience is LEWG.

[José Rodrigo]

I think data() is a better name, to conformition with std::string when using templates.

roup and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYX4mXkERe6UTKTumxo0nEMgsNqM3MSck%2BXzYJviYrBKw%40mail.gmail.com.

[Jonathan Coe]

On 30 Mar 2017, at 21:57, José Rodrigo <rodrigo...@gmail.com> wrote:

I think data() is a better name, to conformition with std::string when using templates.

I think array already has 'data()' : http://en.cppreference.com/w/cpp/container/array/data

Does this satisfy the requirements of the proposed proposal?

roup and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYX4mXkERe6UTKTumxo0nEMgsNqM3MSck%2BXzYJviYrBKw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJe%2Baq_f_OPTwNZ7GevzVgmeH4Mcf16G0Yi5VyRa87v7Wvm_2w%40mail.gmail.com.

[Dan Raviv]

No, and that's detailed in the proposal.

Cheers,

Dan

On Friday, March 31, 2017 at 12:53:05 AM UTC+3, Jonathan Coe wrote:

On 30 Mar 2017, at 21:57, José Rodrigo <rodrigo...@gmail.com> wrote:

I think data() is a better name, to conformition with std::string when using templates.

I think array already has 'data()' : http://en.cppreference.com/w/cpp/container/array/data

Does this satisfy the requirements of the proposed proposal?

[Dan Raviv]

Attached updated proposal draft, following many helpful comments courtesy of Walter E. Brown.

Thanks,

Dan

[Erich Keane]

Sorry if this was previously discussed, I have been a bit off to the side on this one.  I just read through the proposal, and have a couple of suggestions:
1- Can you tab in the 1-5 list in a stop?  The point 5->"adding a member..." paragraph was confusing for a bit.  Even making the following lines obey the 1st line tab would be helpful.

2- I'm EWG and not LWG, but the wording of just "Returns: elems" REALLY needs fleshing out.  I actually don't see 'elems' in the C++17DIS, so it actually might have been removed. 

Otherwise, I'm a fan of this paper, I'd love to see this functionality.

[Dan Raviv]

Good catch! I didn't notice the latest draft removed the elems data member entirely. I've made a few changes accordingly. Specifically, I've changed the proposed wording, hopefully I've managed to write it correctly.

I've also improved the tabbing as you suggested, hopefully it makes the paper clearer.

Thank you Erich for your support and helpful comments!

The latest draft is attached.

Cheers,

Dan