Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #70404 > unrolled thread

I'd like to have unusing

Back to article view | Back to comp.lang.c++

Contents

  I'd like to have unusing Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-12 12:49 +0100
    Re: I'd like to have unusing "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-12-12 13:51 +0100
      Re: I'd like to have unusing Öö Tiib <ootiib@hot.ee> - 2019-12-12 05:47 -0800
        Re: I'd like to have unusing "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-12-12 17:58 +0100
          Re: I'd like to have unusing Öö Tiib <ootiib@hot.ee> - 2019-12-12 09:40 -0800
            Re: I'd like to have unusing "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-12-13 09:23 +0100
        Re: I'd like to have unusing "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-12-12 17:58 +0100
      Re: I'd like to have unusing boltar@nowhere.co.uk - 2019-12-12 16:23 +0000
      Re: I'd like to have unusing Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2019-12-25 13:19 -0500
        Re: I'd like to have unusing "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-12-25 20:09 +0100
          Re: I'd like to have unusing Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2019-12-25 16:37 -0500
            Re: I'd like to have unusing "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-12-25 22:56 +0100
              Re: I'd like to have unusing Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2019-12-25 17:06 -0500
                Re: I'd like to have unusing Öö Tiib <ootiib@hot.ee> - 2019-12-25 14:14 -0800
                  Re: I'd like to have unusing Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2019-12-25 17:28 -0500
                    Re: I'd like to have unusing "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-12-26 00:49 +0100
                      Re: I'd like to have unusing Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2019-12-25 19:54 -0500
                        Re: I'd like to have unusing "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-12-26 03:53 +0100
                          Re: I'd like to have unusing Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2019-12-25 22:32 -0500
                        Re: I'd like to have unusing Öö Tiib <ootiib@hot.ee> - 2019-12-26 03:01 -0800
                          Re: I'd like to have unusing Öö Tiib <ootiib@hot.ee> - 2019-12-26 03:20 -0800
                            Re: I'd like to have unusing Richard Damon <Richard@Damon-Family.org> - 2019-12-27 11:24 -0500
                              Re: I'd like to have unusing Öö Tiib <ootiib@hot.ee> - 2019-12-27 09:22 -0800
                                Re: I'd like to have unusing Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2020-01-02 23:47 -0500
                                  Re: I'd like to have unusing Öö Tiib <ootiib@hot.ee> - 2020-01-02 23:46 -0800
                                    Re: I'd like to have unusing Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2020-01-04 23:46 -0500
                                  Re: I'd like to have unusing Richard Damon <Richard@Damon-Family.org> - 2020-01-04 18:43 -0500
                                    Re: I'd like to have unusing Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2020-01-04 23:55 -0500
    Re: I'd like to have unusing Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-12 18:29 +0000
      Re: I'd like to have unusing Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-12 18:34 +0000
        Re: I'd like to have unusing Daniel <danielaparker@gmail.com> - 2019-12-12 11:17 -0800
      Re: I'd like to have unusing Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-12 19:40 +0100
        Re: I'd like to have unusing Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-12 19:56 +0000
          Re: I'd like to have unusing Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-13 06:35 +0100

Page 1 of 2  [1] 2  Next page →

#70404 — I'd like to have unusing

In a header I'm fixed to write the std::-prefixes since I can't use
"using namespacee std" because this would be against the exepectations
of those including the header.
So I had a simple idea: with every "using namespace xxx" an counter for
the namespace xxx would be incremented and at the end of block where the
prefixes where used implicitly there would be a new "unusing"-directive
that derements the counter and when it becomes zero, the implicit
attachment to symbols is disabled.

[toc] | [next] | [standalone]

#70411

On 12.12.2019 12:49, Bonita Montero wrote:
> In a header I'm fixed to write the std::-prefixes since I can't use
> "using namespacee std" because this would be against the exepectations
> of those including the header.
> So I had a simple idea: with every "using namespace xxx" an counter for
> the namespace xxx would be incremented and at the end of block where the
> prefixes where used implicitly there would be a new "unusing"-directive
> that derements the counter and when it becomes zero, the implicit
> attachment to symbols is disabled.


A workaround until you get that feature proposed and adopted, is to use 
a clean /exporting namespace/.

For example, you may want the stuff to be available in namespace `bonitas`.

Then do like this, first defining stuff in the /defining/ namespace 
`bonitas::_`, or whatever, really, just not same as exporting ns:

     // Here a stern admonition to not use namespace bonitas::_.
     // Then:
     namespace bonitas::_ {
         using namespace std; // Oh joy
         void stuff() { feclearexcept(FE_ALL_EXCEPT); }
     }

     namespace bonitas {
         using _::stuff;
     }

Regarding `_` a main difference from the usual `impl` or `detail` 
namespace (e.g. Boost's `detail`) is that `_` here contains stuff meant 
to be used directly by client code, not just implementation details.

However, client code is only meant to use the stuff via the exporting 
namespace(s), here bonitas, which itself is/are clean.

There are countless variations and extensions of the scheme, and there 
is a gotcha about templates that client code is meant to specialize.


- Alf (who's gradually started to adopt this scheme)

[toc] | [prev] | [next] | [standalone]

#70414

On Thursday, 12 December 2019 14:51:17 UTC+2, Alf P. Steinbach  wrote:
> Regarding `_` a main difference from the usual `impl` or `detail` 
> namespace (e.g. Boost's `detail`) is that `_` here contains stuff meant 
> to be used directly by client code, not just implementation details.

Also name `_` conflicts/hides all the libraries that thought no
one else is so clever to use name `_` in interface (like GNU gettext
and several others). 

[toc] | [prev] | [next] | [standalone]

#70424

On 12.12.2019 14:47, Öö Tiib wrote:
> On Thursday, 12 December 2019 14:51:17 UTC+2, Alf P. Steinbach  wrote:
>> Regarding `_` a main difference from the usual `impl` or `detail`
>> namespace (e.g. Boost's `detail`) is that `_` here contains stuff meant
>> to be used directly by client code, not just implementation details.
> 
> Also name `_` conflicts/hides all the libraries that thought no
> one else is so clever to use name `_` in interface (like GNU gettext
> and several others).

If there are such badly designed libraries, it would in my opinion be an 
added bonus if the name made it difficult to use them.

However I fail to see how that happy situation could come about.

Note that `_` is not is not used or necessarily seen by client code, 
i.e. it's not part of interface.

- Alf

[toc] | [prev] | [next] | [standalone]

#70426

On Thursday, 12 December 2019 18:58:26 UTC+2, Alf P. Steinbach  wrote:
> On 12.12.2019 14:47, Öö Tiib wrote:
> > On Thursday, 12 December 2019 14:51:17 UTC+2, Alf P. Steinbach  wrote:
> >> Regarding `_` a main difference from the usual `impl` or `detail`
> >> namespace (e.g. Boost's `detail`) is that `_` here contains stuff meant
> >> to be used directly by client code, not just implementation details.
> > 
> > Also name `_` conflicts/hides all the libraries that thought no
> > one else is so clever to use name `_` in interface (like GNU gettext
> > and several others).
> 
> If there are such badly designed libraries, it would in my opinion be an 
> added bonus if the name made it difficult to use them.
> 
> However I fail to see how that happy situation could come about.
> 
> Note that `_` is not is not used or necessarily seen by client code, 
> i.e. it's not part of interface.

The GNU gettext is relatively popular library for i18n in open source.
It uses `_` everywhere there are texts to localize in code:

    printf(_("Report bugs to <%s>.\n"), PACKAGE_BUGREPORT);

So its usages can be found by searching for `_("`.  

[toc] | [prev] | [next] | [standalone]

#70433

On 12.12.2019 18:40, Öö Tiib wrote:
> On Thursday, 12 December 2019 18:58:26 UTC+2, Alf P. Steinbach  wrote:
>> On 12.12.2019 14:47, Öö Tiib wrote:
>>> On Thursday, 12 December 2019 14:51:17 UTC+2, Alf P. Steinbach  wrote:
>>>> Regarding `_` a main difference from the usual `impl` or `detail`
>>>> namespace (e.g. Boost's `detail`) is that `_` here contains stuff meant
>>>> to be used directly by client code, not just implementation details.
>>>
>>> Also name `_` conflicts/hides all the libraries that thought no
>>> one else is so clever to use name `_` in interface (like GNU gettext
>>> and several others).
>>
>> If there are such badly designed libraries, it would in my opinion be an
>> added bonus if the name made it difficult to use them.
>>
>> However I fail to see how that happy situation could come about.
>>
>> Note that `_` is not is not used or necessarily seen by client code,
>> i.e. it's not part of interface.
> 
> The GNU gettext is relatively popular library for i18n in open source.
> It uses `_` everywhere there are texts to localize in code:
> 
>      printf(_("Report bugs to <%s>.\n"), PACKAGE_BUGREPORT);
> 
> So its usages can be found by searching for `_("`.

Oh, that's ugly.

But I still don't see the conflict, if that's a macro with params.

Example?


- Alf

[toc] | [prev] | [next] | [standalone]

#70425

On 12.12.2019 14:47, Öö Tiib wrote:
> On Thursday, 12 December 2019 14:51:17 UTC+2, Alf P. Steinbach  wrote:
>> Regarding `_` a main difference from the usual `impl` or `detail`
>> namespace (e.g. Boost's `detail`) is that `_` here contains stuff meant
>> to be used directly by client code, not just implementation details.
> 
> Also name `_` conflicts/hides all the libraries that thought no
> one else is so clever to use name `_` in interface (like GNU gettext
> and several others).
> 

[toc] | [prev] | [next] | [standalone]

#70421

On Thu, 12 Dec 2019 13:51:00 +0100
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> wrote:
>Regarding `_` a main difference from the usual `impl` or `detail` 
>namespace (e.g. Boost's `detail`) is that `_` here contains stuff meant 
>to be used directly by client code, not just implementation details.

Or alternatively instead of '_' you could use a proper name which would be
easy to find when grepping through code instead of something that could bring
up 1000s of hits. But that would be sensible programming, not a concept you're
very familiar with.

[toc] | [prev] | [next] | [standalone]

#70648

Alf P. Steinbach wrote:
> On 12.12.2019 12:49, Bonita Montero wrote:
>> In a header I'm fixed to write the std::-prefixes since I can't use
>> "using namespacee std" because this would be against the exepectations
>> of those including the header.
>> So I had a simple idea: with every "using namespace xxx" an counter for
>> the namespace xxx would be incremented and at the end of block where the
>> prefixes where used implicitly there would be a new "unusing"-directive
>> that derements the counter and when it becomes zero, the implicit
>> attachment to symbols is disabled.
> 
> 
> A workaround until you get that feature proposed and adopted, is to use
> a clean /exporting namespace/.
> 
> For example, you may want the stuff to be available in namespace `bonitas`.
> 
> Then do like this, first defining stuff in the /defining/ namespace
> `bonitas::_`, or whatever, really, just not same as exporting ns:
> 
>     // Here a stern admonition to not use namespace bonitas::_.
>     // Then:
>     namespace bonitas::_ {
>         using namespace std; // Oh joy
>         void stuff() { feclearexcept(FE_ALL_EXCEPT); }
>     }
> 
>     namespace bonitas {
>         using _::stuff;
>     }
> 
> Regarding `_` a main difference from the usual `impl` or `detail`
> namespace (e.g. Boost's `detail`) is that `_` here contains stuff meant
> to be used directly by client code, not just implementation details.
I personally don't see anything wrong in defining few things in details
and using one in the outward-facing namespace (it is not unnatural if
public API is a proper subset of "all details"). But if the namespace
`detail' actively jumps at you as intended for implementation-specific
things exclusively, why not be explicit and use something like using_std
namespace:

namespace mylib {
namespace using_std {
using namespace std;
// define stuff heavily using things from std:: , in particular `stuff'
// that is a part of mylib API
}
using using_std::stuff;
}

Using identifiers beginning with _ in application programs is at least
frown upon by the Standard ("shall not be used otherwise [than by
implementation]"), see 5.10-3.2 in n4830.

> 
> However, client code is only meant to use the stuff via the exporting
> namespace(s), here bonitas, which itself is/are clean.
> 
> There are countless variations and extensions of the scheme, and there
> is a gotcha about templates that client code is meant to specialize.
> 
> 
> - Alf (who's gradually started to adopt this scheme)

[toc] | [prev] | [next] | [standalone]

#70650

On 25.12.2019 19:19, Pavel wrote:
> Alf P. Steinbach wrote:
>> On 12.12.2019 12:49, Bonita Montero wrote:
>>> In a header I'm fixed to write the std::-prefixes since I can't use
>>> "using namespacee std" because this would be against the exepectations
>>> of those including the header.
>>> So I had a simple idea: with every "using namespace xxx" an counter for
>>> the namespace xxx would be incremented and at the end of block where the
>>> prefixes where used implicitly there would be a new "unusing"-directive
>>> that derements the counter and when it becomes zero, the implicit
>>> attachment to symbols is disabled.
>>
>>
>> A workaround until you get that feature proposed and adopted, is to use
>> a clean /exporting namespace/.
>>
>> For example, you may want the stuff to be available in namespace `bonitas`.
>>
>> Then do like this, first defining stuff in the /defining/ namespace
>> `bonitas::_`, or whatever, really, just not same as exporting ns:
>>
>>      // Here a stern admonition to not use namespace bonitas::_.
>>      // Then:
>>      namespace bonitas::_ {
>>          using namespace std; // Oh joy
>>          void stuff() { feclearexcept(FE_ALL_EXCEPT); }
>>      }
>>
>>      namespace bonitas {
>>          using _::stuff;
>>      }
>>
>> Regarding `_` a main difference from the usual `impl` or `detail`
>> namespace (e.g. Boost's `detail`) is that `_` here contains stuff meant
>> to be used directly by client code, not just implementation details.
> I personally don't see anything wrong in defining few things in details
> and using one in the outward-facing namespace (it is not unnatural if
> public API is a proper subset of "all details"). But if the namespace
> `detail' actively jumps at you as intended for implementation-specific
> things exclusively, why not be explicit and use something like using_std
> namespace:
> 
> namespace mylib {
> namespace using_std {
> using namespace std;
> // define stuff heavily using things from std:: , in particular `stuff'
> // that is a part of mylib API
> }
> using using_std::stuff;
> }
> 
> Using identifiers beginning with _ in application programs is at least
> frown upon by the Standard ("shall not be used otherwise [than by
> implementation]"), see 5.10-3.2 in n4830.

Identifiers starting with `_` are reserved in the global namespace.

Identifiers starting with `_` followed by uppercase letter are reserved 
everywhere.

I don't recall any rule like the one you imply, so I think you're 
looking at either the C standard or a proposal of some sort.


>> However, client code is only meant to use the stuff via the exporting
>> namespace(s), here bonitas, which itself is/are clean.
>>
>> There are countless variations and extensions of the scheme, and there
>> is a gotcha about templates that client code is meant to specialize.

- Alf

[toc] | [prev] | [next] | [standalone]

#70651

Alf P. Steinbach wrote:
> On 25.12.2019 19:19, Pavel wrote:
>> Alf P. Steinbach wrote:
>>> On 12.12.2019 12:49, Bonita Montero wrote:
>>>> In a header I'm fixed to write the std::-prefixes since I can't use
>>>> "using namespacee std" because this would be against the exepectations
>>>> of those including the header.
>>>> So I had a simple idea: with every "using namespace xxx" an counter for
>>>> the namespace xxx would be incremented and at the end of block where
>>>> the
>>>> prefixes where used implicitly there would be a new "unusing"-directive
>>>> that derements the counter and when it becomes zero, the implicit
>>>> attachment to symbols is disabled.
>>>
>>>
>>> A workaround until you get that feature proposed and adopted, is to use
>>> a clean /exporting namespace/.
>>>
>>> For example, you may want the stuff to be available in namespace
>>> `bonitas`.
>>>
>>> Then do like this, first defining stuff in the /defining/ namespace
>>> `bonitas::_`, or whatever, really, just not same as exporting ns:
>>>
>>>      // Here a stern admonition to not use namespace bonitas::_.
>>>      // Then:
>>>      namespace bonitas::_ {
>>>          using namespace std; // Oh joy
>>>          void stuff() { feclearexcept(FE_ALL_EXCEPT); }
>>>      }
>>>
>>>      namespace bonitas {
>>>          using _::stuff;
>>>      }
>>>
>>> Regarding `_` a main difference from the usual `impl` or `detail`
>>> namespace (e.g. Boost's `detail`) is that `_` here contains stuff meant
>>> to be used directly by client code, not just implementation details.
>> I personally don't see anything wrong in defining few things in details
>> and using one in the outward-facing namespace (it is not unnatural if
>> public API is a proper subset of "all details"). But if the namespace
>> `detail' actively jumps at you as intended for implementation-specific
>> things exclusively, why not be explicit and use something like using_std
>> namespace:
>>
>> namespace mylib {
>> namespace using_std {
>> using namespace std;
>> // define stuff heavily using things from std:: , in particular `stuff'
>> // that is a part of mylib API
>> }
>> using using_std::stuff;
>> }
>>
>> Using identifiers beginning with _ in application programs is at least
>> frown upon by the Standard ("shall not be used otherwise [than by
>> implementation]"), see 5.10-3.2 in n4830.
> 
> Identifiers starting with `_` are reserved in the global namespace.
> 
> Identifiers starting with `_` followed by uppercase letter are reserved
> everywhere.
> 
> I don't recall any rule like the one you imply, so I think you're
> looking at either the C standard or a proposal of some sort.
I referred to n4830 5.10 (you can call it a proposal but I doubt
anything will change in this particular regard):

3 In addition, some identifiers are reserved for use by C++
implementations and shall not be used otherwise; no
diagnostic is required.
(3.1) — Each identifier that contains a double underscore __ or begins
with an underscore followed by an
uppercase letter is reserved to the implementation for any use.
(3.2) — Each identifier that begins with an underscore is reserved to
the implementation for use as a name in
the global namespace.

Approximately same text was in C++ 11 Standard:

17.6.4.3.2 Global names [global.names]
1 Certain sets of names and function signatures are always reserved to
the implementation:
— Each name that contains a double underscore _ _ or begins with an
underscore followed by an uppercase
letter (2.12) is reserved to the implementation for any use.
— Each name that begins with an underscore is reserved to the
implementation for use as a name in the
global namespace.

So, _ is not just reserved for use as a name in the global namespace but
is reserved *for use by by C++ implementation* (n4830) or *to the
implementation* (2011 Standard).

bonitas::_ is neither used by C++ implementation nor a name in the
global namespace so it seems not compliant to either the 2011 Standard
or n4830 on both fronts.

> 
> 
>>> However, client code is only meant to use the stuff via the exporting
>>> namespace(s), here bonitas, which itself is/are clean.
>>>
>>> There are countless variations and extensions of the scheme, and there
>>> is a gotcha about templates that client code is meant to specialize.
> 
> - Alf
> 
> 
> 

[toc] | [prev] | [next] | [standalone]

#70652

On 25.12.2019 22:37, Pavel wrote:
> Alf P. Steinbach wrote:
>> On 25.12.2019 19:19, Pavel wrote:
>>> Alf P. Steinbach wrote:
>>>> On 12.12.2019 12:49, Bonita Montero wrote:
>>>>> In a header I'm fixed to write the std::-prefixes since I can't use
>>>>> "using namespacee std" because this would be against the exepectations
>>>>> of those including the header.
>>>>> So I had a simple idea: with every "using namespace xxx" an counter for
>>>>> the namespace xxx would be incremented and at the end of block where
>>>>> the
>>>>> prefixes where used implicitly there would be a new "unusing"-directive
>>>>> that derements the counter and when it becomes zero, the implicit
>>>>> attachment to symbols is disabled.
>>>>
>>>>
>>>> A workaround until you get that feature proposed and adopted, is to use
>>>> a clean /exporting namespace/.
>>>>
>>>> For example, you may want the stuff to be available in namespace
>>>> `bonitas`.
>>>>
>>>> Then do like this, first defining stuff in the /defining/ namespace
>>>> `bonitas::_`, or whatever, really, just not same as exporting ns:
>>>>
>>>>       // Here a stern admonition to not use namespace bonitas::_.
>>>>       // Then:
>>>>       namespace bonitas::_ {
>>>>           using namespace std; // Oh joy
>>>>           void stuff() { feclearexcept(FE_ALL_EXCEPT); }
>>>>       }
>>>>
>>>>       namespace bonitas {
>>>>           using _::stuff;
>>>>       }
>>>>
>>>> Regarding `_` a main difference from the usual `impl` or `detail`
>>>> namespace (e.g. Boost's `detail`) is that `_` here contains stuff meant
>>>> to be used directly by client code, not just implementation details.
>>> I personally don't see anything wrong in defining few things in details
>>> and using one in the outward-facing namespace (it is not unnatural if
>>> public API is a proper subset of "all details"). But if the namespace
>>> `detail' actively jumps at you as intended for implementation-specific
>>> things exclusively, why not be explicit and use something like using_std
>>> namespace:
>>>
>>> namespace mylib {
>>> namespace using_std {
>>> using namespace std;
>>> // define stuff heavily using things from std:: , in particular `stuff'
>>> // that is a part of mylib API
>>> }
>>> using using_std::stuff;
>>> }
>>>
>>> Using identifiers beginning with _ in application programs is at least
>>> frown upon by the Standard ("shall not be used otherwise [than by
>>> implementation]"), see 5.10-3.2 in n4830.
>>
>> Identifiers starting with `_` are reserved in the global namespace.
>>
>> Identifiers starting with `_` followed by uppercase letter are reserved
>> everywhere.
>>
>> I don't recall any rule like the one you imply, so I think you're
>> looking at either the C standard or a proposal of some sort.
> I referred to n4830 5.10 (you can call it a proposal but I doubt
> anything will change in this particular regard):
> 
> 3 In addition, some identifiers are reserved for use by C++
> implementations and shall not be used otherwise; no
> diagnostic is required.
> (3.1) — Each identifier that contains a double underscore __ or begins
> with an underscore followed by an
> uppercase letter is reserved to the implementation for any use.
> (3.2) — Each identifier that begins with an underscore is reserved to
> the implementation for use as a name in
> the global namespace.
> 
> Approximately same text was in C++ 11 Standard:
> 
> 17.6.4.3.2 Global names [global.names]
> 1 Certain sets of names and function signatures are always reserved to
> the implementation:
> — Each name that contains a double underscore _ _ or begins with an
> underscore followed by an uppercase
> letter (2.12) is reserved to the implementation for any use.
> — Each name that begins with an underscore is reserved to the
> implementation for use as a name in the
> global namespace.
> 
> So, _ is not just reserved for use as a name in the global namespace but
> is reserved *for use by by C++ implementation* (n4830) or *to the
> implementation* (2011 Standard).

That doesn't follow from what you quote.

What you quote now is what I told you.

In addition, what you quote now does not contain the text you quoted out 
of context earlier.


> bonitas::_ is neither used by C++ implementation nor a name in the
> global namespace so it seems not compliant to either the 2011 Standard
> or n4830 on both fronts.

And this does not make sense.


>>>> However, client code is only meant to use the stuff via the exporting
>>>> namespace(s), here bonitas, which itself is/are clean.
>>>>
>>>> There are countless variations and extensions of the scheme, and there
>>>> is a gotcha about templates that client code is meant to specialize.

- Alf

[toc] | [prev] | [next] | [standalone]

#70653

Alf P. Steinbach wrote:
> On 25.12.2019 22:37, Pavel wrote:
>> Alf P. Steinbach wrote:
>>> On 25.12.2019 19:19, Pavel wrote:
>>>> Alf P. Steinbach wrote:
>>>>> On 12.12.2019 12:49, Bonita Montero wrote:
>>>>>> In a header I'm fixed to write the std::-prefixes since I can't use
>>>>>> "using namespacee std" because this would be against the
>>>>>> exepectations
>>>>>> of those including the header.
>>>>>> So I had a simple idea: with every "using namespace xxx" an
>>>>>> counter for
>>>>>> the namespace xxx would be incremented and at the end of block where
>>>>>> the
>>>>>> prefixes where used implicitly there would be a new
>>>>>> "unusing"-directive
>>>>>> that derements the counter and when it becomes zero, the implicit
>>>>>> attachment to symbols is disabled.
>>>>>
>>>>>
>>>>> A workaround until you get that feature proposed and adopted, is to
>>>>> use
>>>>> a clean /exporting namespace/.
>>>>>
>>>>> For example, you may want the stuff to be available in namespace
>>>>> `bonitas`.
>>>>>
>>>>> Then do like this, first defining stuff in the /defining/ namespace
>>>>> `bonitas::_`, or whatever, really, just not same as exporting ns:
>>>>>
>>>>>       // Here a stern admonition to not use namespace bonitas::_.
>>>>>       // Then:
>>>>>       namespace bonitas::_ {
>>>>>           using namespace std; // Oh joy
>>>>>           void stuff() { feclearexcept(FE_ALL_EXCEPT); }
>>>>>       }
>>>>>
>>>>>       namespace bonitas {
>>>>>           using _::stuff;
>>>>>       }
>>>>>
>>>>> Regarding `_` a main difference from the usual `impl` or `detail`
>>>>> namespace (e.g. Boost's `detail`) is that `_` here contains stuff
>>>>> meant
>>>>> to be used directly by client code, not just implementation details.
>>>> I personally don't see anything wrong in defining few things in details
>>>> and using one in the outward-facing namespace (it is not unnatural if
>>>> public API is a proper subset of "all details"). But if the namespace
>>>> `detail' actively jumps at you as intended for implementation-specific
>>>> things exclusively, why not be explicit and use something like
>>>> using_std
>>>> namespace:
>>>>
>>>> namespace mylib {
>>>> namespace using_std {
>>>> using namespace std;
>>>> // define stuff heavily using things from std:: , in particular `stuff'
>>>> // that is a part of mylib API
>>>> }
>>>> using using_std::stuff;
>>>> }
>>>>
>>>> Using identifiers beginning with _ in application programs is at least
>>>> frown upon by the Standard ("shall not be used otherwise [than by
>>>> implementation]"), see 5.10-3.2 in n4830.
>>>
>>> Identifiers starting with `_` are reserved in the global namespace.
>>>
>>> Identifiers starting with `_` followed by uppercase letter are reserved
>>> everywhere.
>>>
>>> I don't recall any rule like the one you imply, so I think you're
>>> looking at either the C standard or a proposal of some sort.
>> I referred to n4830 5.10 (you can call it a proposal but I doubt
>> anything will change in this particular regard):
>>
>> 3 In addition, some identifiers are reserved for use by C++
>> implementations and shall not be used otherwise; no
>> diagnostic is required.
>> (3.1) — Each identifier that contains a double underscore __ or begins
>> with an underscore followed by an
>> uppercase letter is reserved to the implementation for any use.
>> (3.2) — Each identifier that begins with an underscore is reserved to
>> the implementation for use as a name in
>> the global namespace.
>>
>> Approximately same text was in C++ 11 Standard:
>>
>> 17.6.4.3.2 Global names [global.names]
>> 1 Certain sets of names and function signatures are always reserved to
>> the implementation:
>> — Each name that contains a double underscore _ _ or begins with an
>> underscore followed by an uppercase
>> letter (2.12) is reserved to the implementation for any use.
>> — Each name that begins with an underscore is reserved to the
>> implementation for use as a name in the
>> global namespace.
>>
>> So, _ is not just reserved for use as a name in the global namespace but
>> is reserved *for use by by C++ implementation* (n4830) or *to the
>> implementation* (2011 Standard).
> 
> That doesn't follow from what you quote.
It does.
> 
> What you quote now is what I told you.
You have never mentioned that names or identifiers beginning with an
underscore were reserved for use by / to C++ implementation.
> 
> In addition, what you quote now does not contain the text you quoted
3 In addition, some identifiers are reserved for use by C++
implementations and *shall not be used otherwise*; no
diagnostic is required.

"shall not be used otherwise" is the only clause I really quoted "earlier".
> out of context
define the context
> earlier.

> 
> 
>> bonitas::_ is neither used by C++ implementation nor a name in the
>> global namespace so it seems not compliant to either the 2011 Standard
>> or n4830 on both fronts.
> 
> And this does not make sense.
How so?
> 
> 
>>>>> However, client code is only meant to use the stuff via the exporting
>>>>> namespace(s), here bonitas, which itself is/are clean.
>>>>>
>>>>> There are countless variations and extensions of the scheme, and there
>>>>> is a gotcha about templates that client code is meant to specialize.
> 
> - Alf
> 

[toc] | [prev] | [next] | [standalone]

#70654

On Thursday, 26 December 2019 00:06:27 UTC+2, Pavel  wrote:
> Alf P. Steinbach wrote:
> > On 25.12.2019 22:37, Pavel wrote:
> > 
> >> bonitas::_ is neither used by C++ implementation nor a name in the
> >> global namespace so it seems not compliant to either the 2011 Standard
> >> or n4830 on both fronts.
> > 
> > And this does not make sense.
> How so?

I also do not get your logic how it is not compliant.
It is not in global namespace nor contains double underscores
nor starts with underscore followed by capital letter and so
it is compliant. I don't like it ... but it is just matter of taste.

[toc] | [prev] | [next] | [standalone]

#70655

Öö Tiib wrote:
> On Thursday, 26 December 2019 00:06:27 UTC+2, Pavel  wrote:
>> Alf P. Steinbach wrote:
>>> On 25.12.2019 22:37, Pavel wrote:
>>>
>>>> bonitas::_ is neither used by C++ implementation nor a name in the
>>>> global namespace so it seems not compliant to either the 2011 Standard
>>>> or n4830 on both fronts.
>>>
>>> And this does not make sense.
>> How so?
> 
> I also do not get your logic how it is not compliant.
> It is not in global namespace nor contains double underscores
> nor starts with underscore followed by capital letter and so
> it is compliant. I don't like it ... but it is just matter of taste.
> 
I see. My logic is this: from the below:

3 In addition, some identifiers are reserved for use by C++
implementations and shall not be used otherwise; no
diagnostic is required.
(3.1) — Each identifier that contains a double underscore __ or begins
with an underscore followed by an
uppercase letter is reserved to the implementation for any use.
(3.2) — Each identifier that begins with an underscore is reserved to
the implementation for use as a name in
the global namespace.

I make 2 conclusions:

A. some identifiers (in particular those starting with _) shall not be
used by otherwise than by C++ implementation
B. If an identifier starting with _ not followed by an uppercase letter
is used by C++ implementation, it should be used as a name in the global
namespace.

From that it follows that:

- bonitas::_ is not allowed because of A.
- if A. did not exist, it would be still not allowed because of the
clause Alf referred to in his recollection of the Standard, namely:

Identifiers starting with `_` are reserved in the global namespace.

What I am  missing?

[toc] | [prev] | [next] | [standalone]

#70656

On 25.12.2019 23:28, Pavel wrote:
> Öö Tiib wrote:
>> On Thursday, 26 December 2019 00:06:27 UTC+2, Pavel  wrote:
>>> Alf P. Steinbach wrote:
>>>> On 25.12.2019 22:37, Pavel wrote:
>>>>
>>>>> bonitas::_ is neither used by C++ implementation nor a name in the
>>>>> global namespace so it seems not compliant to either the 2011 Standard
>>>>> or n4830 on both fronts.
>>>>
>>>> And this does not make sense.
>>> How so?
>>
>> I also do not get your logic how it is not compliant.
>> It is not in global namespace nor contains double underscores
>> nor starts with underscore followed by capital letter and so
>> it is compliant. I don't like it ... but it is just matter of taste.
>>
> I see. My logic is this: from the below:
> 
> 3 In addition, some identifiers are reserved for use by C++
> implementations and shall not be used otherwise; no
> diagnostic is required.
> (3.1) — Each identifier that contains a double underscore __ or begins
> with an underscore followed by an
> uppercase letter is reserved to the implementation for any use.
> (3.2) — Each identifier that begins with an underscore is reserved to
> the implementation for use as a name in
> the global namespace.
> 
> I make 2 conclusions:
> 
> A. some identifiers (in particular those starting with _) shall not be
> used by otherwise than by C++ implementation

The parenthetical remark does not follow from anything.


> B. If an identifier starting with _ not followed by an uppercase letter
> is used by C++ implementation, it should be used as a name in the global
> namespace.

... or namespace `std`.


>  From that it follows that:
> 
> - bonitas::_ is not allowed because of A.
> - if A. did not exist, it would be still not allowed because of the
> clause Alf referred to in his recollection of the Standard, namely:
> 
> Identifiers starting with `_` are reserved in the global namespace.
> 
> What I am  missing?

Rather, the question is where you get these ideas.


- Alf

[toc] | [prev] | [next] | [standalone]

#70657

Alf P. Steinbach wrote:
> On 25.12.2019 23:28, Pavel wrote:
>> Öö Tiib wrote:
>>> On Thursday, 26 December 2019 00:06:27 UTC+2, Pavel  wrote:
>>>> Alf P. Steinbach wrote:
>>>>> On 25.12.2019 22:37, Pavel wrote:
>>>>>
>>>>>> bonitas::_ is neither used by C++ implementation nor a name in the
>>>>>> global namespace so it seems not compliant to either the 2011
>>>>>> Standard
>>>>>> or n4830 on both fronts.
>>>>>
>>>>> And this does not make sense.
>>>> How so?
>>>
>>> I also do not get your logic how it is not compliant.
>>> It is not in global namespace nor contains double underscores
>>> nor starts with underscore followed by capital letter and so
>>> it is compliant. I don't like it ... but it is just matter of taste.
>>>
>> I see. My logic is this: from the below:
>>
>> 3 In addition, some identifiers are reserved for use by C++
>> implementations and shall not be used otherwise; no
>> diagnostic is required.
>> (3.1) — Each identifier that contains a double underscore __ or begins
>> with an underscore followed by an
>> uppercase letter is reserved to the implementation for any use.
>> (3.2) — Each identifier that begins with an underscore is reserved to
>> the implementation for use as a name in
>> the global namespace.
>>
>> I make 2 conclusions:
>>
>> A. some identifiers (in particular those starting with _) shall not be
>> used by otherwise than by C++ implementation
> 
> The parenthetical remark does not follow from anything.
except it follows from 3.2 cited right above
> 
> 
>> B. If an identifier starting with _ not followed by an uppercase letter
>> is used by C++ implementation, it should be used as a name in the global
>> namespace.
> 
> ... or namespace `std`.
*that* is what does not seem to follow from anything.
> 
> 
>>  From that it follows that:
>>
>> - bonitas::_ is not allowed because of A.
>> - if A. did not exist, it would be still not allowed because of the
>> clause Alf referred to in his recollection of the Standard, namely:
>>
>> Identifiers starting with `_` are reserved in the global namespace.
>>
>> What I am  missing?
> 
> Rather, the question is where you get these ideas.
Oh, the answer to this one is simple: boolean logic applied to A and B
above.
> 
> 
> - Alf

[toc] | [prev] | [next] | [standalone]

#70658

On 26.12.2019 01:54, Pavel wrote:
> Alf P. Steinbach wrote:
>> On 25.12.2019 23:28, Pavel wrote:
>>> Öö Tiib wrote:
>>>> On Thursday, 26 December 2019 00:06:27 UTC+2, Pavel  wrote:
>>>>> Alf P. Steinbach wrote:
>>>>>> On 25.12.2019 22:37, Pavel wrote:
>>>>>>
>>>>>>> bonitas::_ is neither used by C++ implementation nor a name in the
>>>>>>> global namespace so it seems not compliant to either the 2011
>>>>>>> Standard
>>>>>>> or n4830 on both fronts.
>>>>>>
>>>>>> And this does not make sense.
>>>>> How so?
>>>>
>>>> I also do not get your logic how it is not compliant.
>>>> It is not in global namespace nor contains double underscores
>>>> nor starts with underscore followed by capital letter and so
>>>> it is compliant. I don't like it ... but it is just matter of taste.
>>>>
>>> I see. My logic is this: from the below:
>>>
>>> 3 In addition, some identifiers are reserved for use by C++
>>> implementations and shall not be used otherwise; no
>>> diagnostic is required.
>>> (3.1) — Each identifier that contains a double underscore __ or begins
>>> with an underscore followed by an
>>> uppercase letter is reserved to the implementation for any use.
>>> (3.2) — Each identifier that begins with an underscore is reserved to
>>> the implementation for use as a name in
>>> the global namespace.
>>>
>>> I make 2 conclusions:
>>>
>>> A. some identifiers (in particular those starting with _) shall not be
>>> used by otherwise than by C++ implementation
>>
>> The parenthetical remark does not follow from anything.
> except it follows from 3.2 cited right above
>>
>>
>>> B. If an identifier starting with _ not followed by an uppercase letter
>>> is used by C++ implementation, it should be used as a name in the global
>>> namespace.
>>
>> ... or namespace `std`.
> *that* is what does not seem to follow from anything.
>>
>>
>>>   From that it follows that:
>>>
>>> - bonitas::_ is not allowed because of A.
>>> - if A. did not exist, it would be still not allowed because of the
>>> clause Alf referred to in his recollection of the Standard, namely:
>>>
>>> Identifiers starting with `_` are reserved in the global namespace.
>>>
>>> What I am  missing?
>>
>> Rather, the question is where you get these ideas.
> Oh, the answer to this one is simple: boolean logic applied to A and B
> above.

This reminds me strongly of the tortoise's denial arguments in 
Hofstadter's "Gödel, Escher, Bach: An Eternal Golden Braid".

I recommend that book.

- Alf

[toc] | [prev] | [next] | [standalone]

#70659

Alf P. Steinbach wrote:
> On 26.12.2019 01:54, Pavel wrote:
>> Alf P. Steinbach wrote:
>>> On 25.12.2019 23:28, Pavel wrote:
>>>> Öö Tiib wrote:
>>>>> On Thursday, 26 December 2019 00:06:27 UTC+2, Pavel  wrote:
>>>>>> Alf P. Steinbach wrote:
>>>>>>> On 25.12.2019 22:37, Pavel wrote:
>>>>>>>
>>>>>>>> bonitas::_ is neither used by C++ implementation nor a name in the
>>>>>>>> global namespace so it seems not compliant to either the 2011
>>>>>>>> Standard
>>>>>>>> or n4830 on both fronts.
>>>>>>>
>>>>>>> And this does not make sense.
>>>>>> How so?
>>>>>
>>>>> I also do not get your logic how it is not compliant.
>>>>> It is not in global namespace nor contains double underscores
>>>>> nor starts with underscore followed by capital letter and so
>>>>> it is compliant. I don't like it ... but it is just matter of taste.
>>>>>
>>>> I see. My logic is this: from the below:
>>>>
>>>> 3 In addition, some identifiers are reserved for use by C++
>>>> implementations and shall not be used otherwise; no
>>>> diagnostic is required.
>>>> (3.1) — Each identifier that contains a double underscore __ or begins
>>>> with an underscore followed by an
>>>> uppercase letter is reserved to the implementation for any use.
>>>> (3.2) — Each identifier that begins with an underscore is reserved to
>>>> the implementation for use as a name in
>>>> the global namespace.
>>>>
>>>> I make 2 conclusions:
>>>>
>>>> A. some identifiers (in particular those starting with _) shall not be
>>>> used by otherwise than by C++ implementation
>>>
>>> The parenthetical remark does not follow from anything.
>> except it follows from 3.2 cited right above
>>>
>>>
>>>> B. If an identifier starting with _ not followed by an uppercase letter
>>>> is used by C++ implementation, it should be used as a name in the
>>>> global
>>>> namespace.
>>>
>>> ... or namespace `std`.
>> *that* is what does not seem to follow from anything.
>>>
>>>
>>>>   From that it follows that:
>>>>
>>>> - bonitas::_ is not allowed because of A.
>>>> - if A. did not exist, it would be still not allowed because of the
>>>> clause Alf referred to in his recollection of the Standard, namely:
>>>>
>>>> Identifiers starting with `_` are reserved in the global namespace.
>>>>
>>>> What I am  missing?
>>>
>>> Rather, the question is where you get these ideas.
>> Oh, the answer to this one is simple: boolean logic applied to A and B
>> above.
> 
> This reminds me strongly of the tortoise's denial arguments in
> Hofstadter's "Gödel, Escher, Bach: An Eternal Golden Braid".
> 
> I recommend that book.
nice try.
> 
> - Alf

[toc] | [prev] | [next] | [standalone]

#70661

On Thursday, 26 December 2019 02:55:04 UTC+2, Pavel  wrote:
> Alf P. Steinbach wrote:
> > On 25.12.2019 23:28, Pavel wrote:
> >> Öö Tiib wrote:
> >>> On Thursday, 26 December 2019 00:06:27 UTC+2, Pavel  wrote:
> >>>> Alf P. Steinbach wrote:
> >>>>> On 25.12.2019 22:37, Pavel wrote:
> >>>>>
> >>>>>> bonitas::_ is neither used by C++ implementation nor a name in the
> >>>>>> global namespace so it seems not compliant to either the 2011
> >>>>>> Standard
> >>>>>> or n4830 on both fronts.
> >>>>>
> >>>>> And this does not make sense.
> >>>> How so?
> >>>
> >>> I also do not get your logic how it is not compliant.
> >>> It is not in global namespace nor contains double underscores
> >>> nor starts with underscore followed by capital letter and so
> >>> it is compliant. I don't like it ... but it is just matter of taste.
> >>>
> >> I see. My logic is this: from the below:
> >>
> >> 3 In addition, some identifiers are reserved for use by C++
> >> implementations and shall not be used otherwise; no
> >> diagnostic is required.
> >> (3.1) — Each identifier that contains a double underscore __ or begins
> >> with an underscore followed by an
> >> uppercase letter is reserved to the implementation for any use.
> >> (3.2) — Each identifier that begins with an underscore is reserved to
> >> the implementation for use as a name in
> >> the global namespace.

Sometimes I notice hieroglyph fi used instead of fi in normative texts. 
Like "identifier". Perhaps there is saboteur among the language lawyers
that wants to make it harder to search the texts.

> >> I make 2 conclusions:
> >>
> >> A. some identifiers (in particular those starting with _) shall not be
> >> used by otherwise than by C++ implementation
> > 
> > The parenthetical remark does not follow from anything.
> except it follows from 3.2 cited right above

I understand how the sentence may be interpreted like that out of 
context but that interpretation does not make sense in C++. 

Names have scope in C++ (or can lack it on case of macros and keywords).
So "as names in the global namespace" means that it is where the
rule applies. Similarly "for any use" means that such names are 
reserved for any (scoped or scope-less) usage.

Characters of Alice in Wonderland kept constantly misinterpreting
meanings of sentences like that so perhaps it is just limitation
of human languages. Or can you propose better wording?


> > 
> > 
> >> B. If an identifier starting with _ not followed by an uppercase letter
> >> is used by C++ implementation, it should be used as a name in the global
> >> namespace.
> > 
> > ... or namespace `std`.
> *that* is what does not seem to follow from anything.

There standard has chosen to other way of reserving, the menace
of undefined behavior when user touches namespace std in wrong
way:
"The behavior of a C++ program is undefined if it adds declarations
or definitions to namespace std or to a namespace within namespace 
std unless otherwise specified. A program may add a template
specialization for any standard library template to namespace std
only if the declaration depends on a user-defined type and the
specialization meets the standard library requirements for the original
template and is not explicitly prohibited."

> > 
> > 
> >>  From that it follows that:
> >>
> >> - bonitas::_ is not allowed because of A.
> >> - if A. did not exist, it would be still not allowed because of the
> >> clause Alf referred to in his recollection of the Standard, namely:
> >>
> >> Identifiers starting with `_` are reserved in the global namespace.
> >>
> >> What I am  missing?
> > 
> > Rather, the question is where you get these ideas.
> Oh, the answer to this one is simple: boolean logic applied to A and B
> above.

English does not unfortunately translate into boolean logic.
No human language does.

> > 
> > 
> > - Alf

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web