220 41 article Path: news.gmane.org!not-for-mail From: stackmachine@hotmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Allowing constexpr char[]'s in asm directives Date: Sun, 11 Nov 2012 08:29:34 -0800 (PST) Lines: 211 Approved: news@gmane.org Message-ID: References: <27482d3f-117d-4913-b1ff-feb6267760f3@isocpp.org> <509DFF12.9060206@gmx.net> <509FC7CE.309@gmx.net> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_143_23834307.1352651374169" X-Trace: ger.gmane.org 1352651375 28569 80.91.229.3 (11 Nov 2012 16:29:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 Nov 2012 16:29:35 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDC7BQ4GSIMRB35E76CAKGQESDSDAKI@isocpp.org Sun Nov 11 17:29:46 2012 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-gh0-f197.google.com ([209.85.160.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TXaPp-0001Hd-5B for gclcip-std-proposals@m.gmane.org; Sun, 11 Nov 2012 17:29:45 +0100 Original-Received: by mail-gh0-f197.google.com with SMTP id f16sf12038942ghb.0 for ; Sun, 11 Nov 2012 08:29:35 -0800 (PST) Original-Received: by 10.236.119.145 with SMTP id n17mr11665778yhh.22.1352651375233; Sun, 11 Nov 2012 08:29:35 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.236.149.73 with SMTP id w49ls8517389yhj.5.gmail; Sun, 11 Nov 2012 08:29:34 -0800 (PST) Original-Received: by 10.236.180.134 with SMTP id j6mr2143485yhm.15.1352651374807; Sun, 11 Nov 2012 08:29:34 -0800 (PST) In-Reply-To: <509FC7CE.309@gmx.net> X-Original-Sender: stackmachine@hotmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:41 Archived-At: ------=_Part_143_23834307.1352651374169 Content-Type: text/plain; charset=ISO-8859-1 Am Sonntag, 11. November 2012 16:44:19 UTC+1 schrieb Jens Maurer: > > On 11/11/2012 04:02 PM, stackm...@hotmail.com wrote: > > > > > > Am Samstag, 10. November 2012 08:16:19 UTC+1 schrieb Jens Maurer: > > > > On 11/10/2012 02:15 AM, stackm...@hotmail.com wrote: > > > Simple feature: Allow the use of compiletime constant strings in > asm directives. That would allow generating asm through template-meta > programs. Wouldn't that be damn awesome? > > > > Could you provide an example program that makes use of such a > > feature in a non-trivial way, including the generation of > > the compile-time constant strings? In which way would the > > portability of that program be improved if the standard > > would prescribe the feature you're proposing? > > > > The program would not neccessarily be more portable but it would allow > (for example) simple abstractions around common patterns, such as loops, > conditions, or function calls. > > Here's a simple example of how this could be used: > > > > typedef function print_int; // assuming that > string literals could be used as template parameters in the future > > Here's the first other extension you'll need. > No. It's a nice-to-have feature, but certainly not required. > > typedef for_from_to<1, 10, call> print_1_to_10; > > > > asm(generate_asm::value::c_str); > > This example doesn't convince me. You've got a C++ compiler in your hand, > yet > you try to print the numbers from 1 to 10 in semi-handcrafting assembly? > It's an example, used to demonstrate possible usage. It is not supposed to be useful. > > ::value might be some compiletime string type, which itself holds a > constexpr char[] ::c_str. > > Please clue me in: How do you do compile-time string concatenation with > the > current constexpr feature set? (Yes, the preprocessor can splice string > literals, but that's not what we're talking about here.) > By using some template magic. template struct string { constexpr char c_str[] = { S..., 0 }; }; template struct concat; template struct concat, string> { typedef string value; }; Possible usage: typedef string<'a', 'b', 'c'> abc; typedef string<'d', 'e', 'f'> def; typedef concat::value abcdef; std::cout << abcdef::c_str; > The current standard doesn't say a lot about "asm" (see section 7.4), > > except that its argument must be a string-literal. And even then, > > the entire asm is conditionally-supported, meaning an implementation > > can simply refuse an "asm" with an error message (and not implement > it). > > > > Instead of only allowing string literals, I propose to allow constant > string expressions. This would only require a change to the grammar AFAIK. > (?) > > I understand your proposal. I have yet to see a non-trivial use that > makes such a change compelling to me. Just because something can be done > and looks easy at the top level, doesn't mean it should be done. There > is always some extra maintenance cost down the road, cf. the current core > issues list. > Note that I'm not proposing an entirely new feature, compilers already contain the logic to evaluate constant expressions. Therefore I only request to lift a restriction that does not seem to have a rationale. I do admit that I don't have a use case for it, I just think it'd be a cool thing to have. -- ------=_Part_143_23834307.1352651374169 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am Sonntag, 11. November 2012 16:44:19 UTC+1 schrieb Jens Maurer:On 11/11/2012 04:02 PM, stackm...@= hotmail.com wrote:
>=20
>=20
> Am Samstag, 10. November 2012 08:16:19 UTC+1 schrieb Jens Maurer:
>=20
>     On 11/10/2012 02:15 AM, stackm...@hotmail.com= <javascript:> wrote:
>     > Simple feature: Allow the use of compiletime co= nstant strings in asm directives. That would allow generating asm through t= emplate-meta programs. Wouldn't that be damn awesome?
>=20
>     Could you provide an example program that makes use = of such a
>     feature in a non-trivial way, including the generati= on of
>     the compile-time constant strings?  In which wa= y would the
>     portability of that program be improved if the stand= ard
>     would prescribe the feature you're proposing?
>=20
> The program would not neccessarily be more portable but it would a= llow (for example) simple abstractions around common patterns, such as loop= s, conditions, or function calls.
> Here's a simple example of how this could be used:
>=20
> typedef function<stdcall, "print_int"> print_int; // assumin= g that string literals could be used as template parameters in the future

Here's the first other extension you'll need.
No. It's a nice-to-have feature, but certainly not re= quired.
 
> typedef for_from_to<1, 10, call<print_int>> print_1_= to_10;
>=20
> asm(generate_asm<x86_64, print_1_to_10>::value::c_str);

This example doesn't convince me.  You've got a C++ compiler in yo= ur hand, yet
you try to print the numbers from 1 to 10 in semi-handcrafting assembly= ?
It's an example, used to demonstrate possible usage.= It is not supposed to be useful.
 
> ::value might be some compiletime string type, whic= h itself holds a constexpr char[] ::c_str.

Please clue me in: How do you do compile-time string concatenation with= the
current constexpr feature set?  (Yes, the preprocessor can splice = string
literals, but that's not what we're talking about here.)
By using some template magic.
template <char...= S>
struct string
{
    constexpr char c_str[] = =3D { S..., 0 };
};

template <typename, typename>
struct= concat;

template <char... S1, char... S2>
struct concat<= ;string<S1...>, string<S2...>>
{
    ty= pedef string<S1..., S2...> value;
};

Possible usage:
typ= edef string<'a', 'b', 'c'> abc;
typedef string<'d', 'e', 'f'>= ; def;
typedef concat<abc, def>::value abcdef;
std::cout <&l= t; abcdef::c_str;

>     except that its argument must be a string-literal. &= nbsp;And even then,
>     the entire asm is conditionally-supported, meaning a= n implementation
>     can simply refuse an "asm" with an error message (an= d not implement it).
>=20
> Instead of only allowing string literals, I propose to allow const= ant string expressions. This would only require a change to the grammar AFA= IK. (?)

I understand your proposal.  I have yet to see a non-trivial use t= hat
makes such a change compelling to me.  Just because something can = be done
and looks easy at the top level, doesn't mean it should be done.  = There
is always some extra maintenance cost down the road, cf. the current co= re
issues list.
Note that I'm not proposing an entirely new feature, = compilers already contain the logic to evaluate constant expressions. There= fore I only request to lift a restriction that does not seem to have a rati= onale.
I do admit that I don't have a use case for it, I just think it'd= be a cool thing to have.
 

--
 
 
 
------=_Part_143_23834307.1352651374169-- .