<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    You folks do all the heavy lifting and thus are fully/well versed in
    the syntax and phonetics of the grammar you choose, but to put it
    bluntly if English became a chicken scratch language it never would
    have developed fully [though other languages would challenge that
    fully developed assertion on my part].<br>
    <br>
    <b>__clang_atomic_</b> is clearly readable and discernible, and I
    could care less about saving a few bytes in characters. Most editors
    can also make custom tags that trigger the entire string with a
    simple combination of key-strokes for an action to be performed.<br>
    <br>
    This is one of the reasons I personally have a love/hate
    relationship with Computer Science and another reason Mechanical
    Engineering is my first and more beloved degree.<br>
    <br>
    It's also another reason I was glad to work at NeXT and Apple with
    the knowledge that Objective-C is such a readable programming
    language, unlike the chicken scratch often found in C/C++.<br>
    <br>
    Sincerely,<br>
    <br>
    - Marc J. Driftmeyer<br>
    <br>
    On 04/10/2012 05:08 PM, Chandler Carruth wrote:
    <blockquote
cite="mid:CAGCO0Kjo2Tg8h-zTMah7ZqJjYuKfzXCbxWr4V9LGecANYird9Q@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">On Wed, Apr 11, 2012 at 1:03 AM, Howard
        Hinnant <span dir="ltr"><<a moz-do-not-send="true"
            href="mailto:hhinnant@apple.com">hhinnant@apple.com</a>></span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div class="HOEnZb">
            <div class="h5">On Apr 10, 2012, at 7:59 PM, Howard Hinnant
              wrote:<br>
              <br>
              > On Apr 10, 2012, at 7:24 PM, Chandler Carruth wrote:<br>
              ><br>
              >> I want to call out this point:<br>
              >><br>
              >> On Wed, Apr 11, 2012 at 12:25 AM, Richard Smith
              <<a moz-do-not-send="true"
                href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>>
              wrote:<br>
              >> This approach, including the need to interpose in
              front of <atomic> and <shared_ptr> (and any
              other user of the atomics builtins in libstdc++) and
              detect whether we're about to include a header from
              libstdc++, seems sufficiently fragile that I'm still in
              favour of introducing GNU-compatible builtins.<br>
              >><br>
              >> I think this is setting ourselves up for an
              endless game of catchup. What is worse, our users will
              suffer.<br>
              >><br>
              >> Version skew between libstdc++ and Clang is
              inevitable. As a consequence, the advantages of being
              maximally compatible with libstdc++ are only present when
              we can be largely *forward* compatible. This seems
              impossible if we have to intercept ever header to
              reference a GCC builtin and introduce our wrapper for it.<br>
              >><br>
              >><br>
              >> At a fundamental level, I am not yet comfortable
              with Clang, after defining __GNUC__ and acting as a
              heavily compatible compiler with GCC, going on to define
              builtin functions which share the same name but
              incompatible semantics with GCC builtins. This seems like
              a recipe for a long string of puzzling compilation
              failures, user frustration, and impeded adoption of Clang.<br>
              >><br>
              >> I think we should continue with the long standing
              policy of, when reasonable and tenable, supporting the GCC
              builtins with their names, and allowing users to not care.
              Then, under a *different* naming pattern, and guarded by
              proper __has_feature macros etc, we should provide
              Clang-specific extensions which have the semantics we
              would rather see.<br>
              >><br>
              >> While a realize this isn't ideal, and it requires
              renaming currently supported intrinsics I see few options
              left to us:<br>
              >> 1) We haven't released with these intrinsics<br>
              >> 2) GCC has released with its intrinsics<br>
              >> 3) We failed to discuss our intrinsics
              sufficiently with the GCC folks to get them to implement
              the same set<br>
              >> 4) GCC folks failed to discuss theirs with us
              sufficiently to get us to implement the same set<br>
              >> 5) We need something for Clang v3.1, or it is
              instantly un-usable with GCC 4.7 and later.<br>
              >><br>
              >> I don't like any of this, and it isn't how I
              would wish for things to proceed if I had it to do again,
              but this is where we are. We need to realize that, today,
              I cannot compile any meaningful C++98 code with the
              default C++ standard library on Linux (after a distro
              picks up GCC 4.7) and Clang. I do not think that is an
              acceptable state to release Clang under.<br>
              ><br>
              > Perhaps we need to stake out another namespace for
              clang atomic intrinsics. ¬†Our current prefix is:<br>
              ><br>
              > __atomic_<br>
              ><br>
              > Suggestions:<br>
              ><br>
              > __clang_atomic_<br>
              > __clng_atmc_<br>
              > _ClangAtomic_<br>
              > _CLNGatomic_<br>
              > _CLNG_ATM_<br>
              > _ClngAtm_<br>
              ><br>
              > The final suggestion has the same length as our
              current prefix.<br>
              <br>
              <br>
            </div>
          </div>
          Or even shorter: :-)<br>
          <br>
          __atomx_<br>
        </blockquote>
        <div><br>
        </div>
        <div>I am quite lazy when it comes to typing, but perhaps here
          is not the time to save characters. ;] I would vote:</div>
        <div><br>
        </div>
        <div>__clang_atomic_</div>
        <div><br>
        </div>
        <div>
          or, based on the discussion between David and Richard,
          perhaps:</div>
        <div><br>
        </div>
        <div>__c11_atomic_</div>
        <div><br>
        </div>
        <div>to call out their close correspondance with the c11 spec.</div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a>
</pre>
    </blockquote>
    <br>
    <div class="moz-signature">-- <br>
      Marc J. Driftmeyer<br>
      Email :: <a href="mailto:mjd@reanimality.com">mjd@reanimality.com</a><br>
      Web :: <a href="http://www.reanimality.com">http://www.reanimality.com</a><br>
      Cell :: (509) 435-5212
    </div>
  </body>
</html>