Wednesday, December 25, 2019

Digest for comp.lang.c++@googlegroups.com - 17 updates in 4 topics

Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Dec 25 01:19PM -0500

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

On 25.12.2019 19:19, Pavel wrote:
 
> 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.
 
 
>> 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
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Dec 25 04:37PM -0500

Alf P. Steinbach wrote:
> 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.
 
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 25 10:56PM +0100

On 25.12.2019 22:37, Pavel wrote:
 
> 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.
 
 
>>>> 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
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Dec 25 05:06PM -0500

Alf P. Steinbach wrote:
>> 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
>> 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?
"Öö Tiib" <ootiib@hot.ee>: Dec 25 02:14PM -0800

On Thursday, 26 December 2019 00:06:27 UTC+2, Pavel wrote:
> >> 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.
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Dec 25 05:28PM -0500

Öö Tiib wrote:
> 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?
woodbrian77@gmail.com: Dec 24 05:52PM -0800

On Saturday, December 21, 2019 at 11:11:38 AM UTC-6, Öö Tiib wrote:
 
> Nonsense, bool was added to C++ by C++98, I used C++ *long* before that.
> <https://en.cppreference.com/w/cpp/language/history>
> I don't know is default answer to every question. Knowledge is rarity.
 
I was reading here
https://www.reddit.com/r/cpp/comments/ef5gdc/managarm_at_the_end_of_2019/
 
The following:
I love the philosophy of "async ONLY".
 
One of my biggest complaints is how frequently processes in
Linux get stuck because of waiting on disk IO. Nothing makes
me madder than being unable to terminate a process for hours
while a filesystem twiddles it's thumbs.
 
--------------------------------------------------------------------
 
That's news to me about Linux processes. Can anyone add to
that? Is killing the process not an option? Is this a Linux
problem that isn't getting fixed so users have to work
around it? Does FreeBSD have similar problems?
 
My middle tier does synchronous reads and writes to the file
system. If I were to work on making one of those async, do
you think it would be easier to start with the writes rather
than the reads? Thank you in advance.
 
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
https://github.com/Ebenezer-group/onwards
"Öö Tiib" <ootiib@hot.ee>: Dec 24 11:53PM -0800


> --------------------------------------------------------------------
 
> That's news to me about Linux processes. Can anyone add to
> that? Is killing the process not an option?
 
As I understand it the process is in "D" state that means
"uninterruptible sleep" that is usually because waiting for I/O.
 
> Is this a Linux
> problem that isn't getting fixed so users have to work
> around it? Does FreeBSD have similar problems?
 
I do not know about FreeBSD. When unsure what processes are stuck
behind I/O one can utter on Linux something like:
 
watch "(ps -eo stat,pid,comm|awk '(NR==1)||(\$1~/D/){print}')"
 
That will give information about processes in "D" state.
 
> system. If I were to work on making one of those async, do
> you think it would be easier to start with the writes rather
> than the reads? Thank you in advance.
 
There are no silver bullets. Few kilobyte files are likely
best to read and write "atomically" as whole file. With bigger
files we need to pick asynchronous or synchronous. Trying to mix
those with same file will add complications, no gains. Choice
what is more optimal depends on how expensive processing is
done during I/O. Synchronous communication seems to be easier
for programmers to reason about so pick that as default.
woodbrian77@gmail.com: Dec 25 08:51AM -0800

On Wednesday, December 25, 2019 at 1:53:34 AM UTC-6, Öö Tiib wrote:
> > than the reads? Thank you in advance.
 
> There are no silver bullets. Few kilobyte files are likely
> best to read and write "atomically" as whole file.
 
I interpret that to be the same as synchronous.
 
> what is more optimal depends on how expensive processing is
> done during I/O. Synchronous communication seems to be easier
> for programmers to reason about so pick that as default.
 
Kind of agree and my files will likely be less than a megabyte
so will stick to synchronous file I/O for now.
"Öö Tiib" <ootiib@hot.ee>: Dec 25 10:54AM -0800

> > for programmers to reason about so pick that as default.
 
> Kind of agree and my files will likely be less than a megabyte
> so will stick to synchronous file I/O for now.
 
Also note that when our file handling involves random access
or even worse random access and sharing between processes (it
sometimes does) then it is very hard to do with usual serial
read/write but quite clean with memory mapping. With memory
mapping our file's size must be multiplies of memory page size
(typically 4096 bytes) and the code will be platform specific
and it can't be done on systems without virtual memory and
some other such constraints but otherwise it will work great. ;)
jak <nospam@please.ty>: Dec 25 10:17AM +0100

Il 24/12/2019 23:10, Mr Flibble ha scritto:
 
> Your egregious Christian propaganda is not welcome here. Also, your god
> doesn't exist.
 
> /Flibble
 
? "your" ?
 
o_O
Bonita Montero <Bonita.Montero@gmail.com>: Dec 25 11:02AM +0100

> Also, your god doesn't exist.
 
You would think different if Bjarne Stroustrup would be the next pope.
Siri Cruise <chine.bleu@yahoo.com>: Dec 25 05:19AM -0800

In article <qtvc4j$elr$1@news.albasani.net>,
 
> > Also, your god doesn't exist.
 
> You would think different if Bjarne Stroustrup would be the next pope.
 
Bah, C++ bug.
 
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
The first law of discordiamism: The more energy This post / \
to make order is nore energy made into entropy. insults Islam. Mohammed
Bonita Montero <Bonita.Montero@gmail.com>: Dec 25 03:10PM +0100

>>> Also, your god doesn't exist.
 
>> You would think different if Bjarne Stroustrup would be the next pope.
 
> Bah, C++ bug.
 
C++ is the by far superior language.
Melzzzzz <Melzzzzz@zzzzz.com>: Dec 25 04:23PM

> Merry Christmas to all C and C++ programmers
 
I am celebrating Christmas on 7th January.
 
--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Bonita Montero <Bonita.Montero@gmail.com>: Dec 25 02:30AM +0100

>> Xeons.
 
> https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf
> Section 3.7.3, Hardware Prefetching for Second-Level Cache.
 
Alignment of prefetches is a totally different topic.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)