Thursday, December 12, 2019

Digest for comp.lang.c++@googlegroups.com - 25 updates in 2 topics

Bonita Montero <Bonita.Montero@gmail.com>: Dec 12 12:49PM +0100

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.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 12 01:51PM +0100

On 12.12.2019 12:49, Bonita Montero wrote:
> 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)
"Öö Tiib" <ootiib@hot.ee>: Dec 12 05:47AM -0800

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).
boltar@nowhere.co.uk: Dec 12 04:23PM

On Thu, 12 Dec 2019 13:51:00 +0100
>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.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 12 05:58PM +0100

On 12.12.2019 14:47, Öö Tiib wrote:
 
> 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
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 12 05:58PM +0100

On 12.12.2019 14:47, Öö Tiib wrote:
"Öö Tiib" <ootiib@hot.ee>: Dec 12 09:40AM -0800

On Thursday, 12 December 2019 18:58:26 UTC+2, Alf P. Steinbach wrote:
 
> 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 `_("`.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 12 06:29PM

On 12/12/2019 11:49, Bonita Montero wrote:
> 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.
 
Worst. Idea. Ever.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 12 06:34PM

On 12/12/2019 18:29, Mr Flibble wrote:
>> that derements the counter and when it becomes zero, the implicit
>> attachment to symbols is disabled.
 
> Worst. Idea. Ever.
 
What would be a good idea tho would be the following feature:
 
namespace neogfx
{
// foo
 
namespace ::std
{
// stuff you want to specialize in std
}
 
// bar
}
 
so we don't have to write:
 
namespace neogfx
{
// foo
}
 
namespace std
{
// stuff you want to specialize in std
}
 
namespace neogfx
{
// bar
}
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
Frederick Gotham <cauldwell.thomas@gmail.com>: Dec 12 03:53AM -0800

I'm working on a large embedded Linux project with about 4 gigs of source code.
 
I'm trying to create one header file that can be included in any sub-project, which will have a function for generating random bytes of data. The only two requirement of using this random number generator will be:
(1) You must include "agnostic_random.hpp" in the source file(s) where it's used
(2) When linking, you must link with "libdl.so"
 
In this header file, I'm taking advantage of the "inline" keyword because of its unique linking characteristics, specifically that I can have a static object inside an inline function and it will only exist once (and it will only be initialised once for the current process).
 
This random number generator must be fully thread-safe.
 
At the moment I've written it to use "RAND_bytes" provided by OpenSSL, but this might change later (e.g. I might use tpm2-tss directly).
 
Please give me a critique of this header file and let me know if I've overlooked anything.
 
#ifndef HPP_INCLUSION_GUARD_AGNOSTIC_RANDOM
#define HPP_INCLUSION_GUARD_AGNOSTIC_RANDOM
 
#ifndef __cplusplus
# error "This is a C++ header file but you've included it in a C source file (or you've used a C compiler on a C++ source file). Don't do that."
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)