Tuesday, October 16, 2018

Digest for comp.lang.c++@googlegroups.com - 16 updates in 3 topics

legalize+jeeves@mail.xmission.com (Richard): Oct 15 11:44PM

[Please do not mail me a copy of your followup]
 
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> spake the secret code
>about the possibility of implementing COW correctly if the standard
>didn't stand actively in the way. As I recall (this was years ago) I
>supplied proof in the form of an actual implementation, to no avail.
 
When I gave a presentation on strings to the Utah C++ Programmer's
meetup in January, 2018[1], I pointed out that many large code bases
have custom strings that better suit their problem domain. For
instance, LLVM/clang has custom string classes such as SmallString,
StringRef and Twine.[2] Personally I found StringRef too easy to misuse
and therefore not following Scott Meyer's advice for interfaces. If
you've got an application that is doing lots of string manipulation
and copy-on-write would provide benefit, then by all means use a CoW
string implemenation and use that throughout your code base.
 
Alf, are you aware of any CoW string implementation that is
maintained?
 
[1] <https://www.meetup.com/Utah-Cpp-Programmers/events/xxrjflyxcbnb/>
[2] <http://llvm.org/docs/ProgrammersManual.html#string-like-containers>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
"Öö Tiib" <ootiib@hot.ee>: Oct 16 06:23AM -0700

On Tuesday, 16 October 2018 01:15:13 UTC+3, Alf P. Steinbach wrote:
> supplied proof in the form of an actual implementation, to no avail.
> Hardcore fans of this or that are usually immune to facts and logic, and
> I've encountered that a great many times so I should have known, but.
 
I do not understand what is "bug" there? The GNU libstdc++
is part of mainline GCC distribution not stand-alone portable
implementation of standard library. Such standard library is not
required to be implemented as source code text files. If parts of
it are text files then those are not required to contain C++ code.
Even if those contain C++-like code then it is not required to be
standard-conforming C++ code.
 
Lot of library features added by C++11 standard are something
outright arcane and magical exactly with all these excuses
expressed. Look at std::initializer_list, std::thread, std::atomic
and so on, it is pure magic not possible to express in standard
C++.
 
Therefore while isocpp.org is full of priggish language lawyers
I do not believe that disappearance of CoW strings was because
of such sanctimonious arguments. In lot of programming languages
string is part of core language.
 
However the non-sanctimonious arguments that I have heard are
also plenty:
1) Majority of strings handled by actual code are shorter than 30
bytes but CoW offers no optimization around that fact.
2) Copy of string with CoW involves thread-safe increment of
reference count and that makes it more expensive than copy with
short string optimization.
3) Efficient usage of CoW strings involves strict const-correctness
but even the talented programmers of major shops do not honor
that everywhere.
4) The immediate availability of size of string is very important for
lot of algorithms (and can make those more efficient than with
zero terminated strings of C) but with CoW it is behind additional
level of indirection.
 
So the major shops voted for making one-pointer CoW string illegal
and now there are all (usually ... 32 byte) non-CoW strings.
 
Programmers who want to be very efficient with text processing
should extensively use std::string_view of C++17. Inconveniences,
complications, dangling references and thread safety are back on
shoulders of programmers with it, but it is very powerful
performance optimization. But in 95% of code the std::string is
efficient enough and non-CoW is bit more robust and scalable
than CoW for that code.
boltar@cylonhq.com: Oct 16 01:54PM

On Tue, 16 Oct 2018 06:23:00 -0700 (PDT)
>expressed. Look at std::initializer_list, std::thread, std::atomic
>and so on, it is pure magic not possible to express in standard
>C++.
 
std::initializer_list is just a clever vararg. You could do it in standard C
never mind C++.
"Öö Tiib" <ootiib@hot.ee>: Oct 16 07:47AM -0700

> >C++.
 
> std::initializer_list is just a clever vararg. You could do it in standard C
> never mind C++.
 
No it is not and no we could not implement it in C. It is core language
feature Expression {1,2,3} just magically makes constexpr instance
of std::initializer_list<int> to poof into existence. The very concept
of constexpr is missing from C and so you have to use preprocessor
metaprogramming to handle things like that in it.
 
My point was that magic is fully allowed by standard so in same way
expression "Hello World!" could make constexpr instance of
std::basic_string<char> (AKA std::string) to poof into existence.
Standard just haven't chosen to do that. There are no such thing
like constexpr std::string in C++. So we have to use explicitly
made std::string_view("Hello World!") in constexpr functions.
"Öö Tiib" <ootiib@hot.ee>: Oct 16 08:14AM -0700

On Tuesday, 16 October 2018 17:47:30 UTC+3, Öö Tiib wrote:
> So we have to use explicitly
> made std::string_view("Hello World!") in constexpr functions.
 
Here I was bit too croaky, we can use "Hello World"sv as shortcut
of it.
boltar@cylonhq.com: Oct 16 03:30PM

On Tue, 16 Oct 2018 07:47:18 -0700 (PDT)
>of std::initializer_list<int> to poof into existence. The very concept
>of constexpr is missing from C and so you have to use preprocessor
>metaprogramming to handle things like that in it.
 
And?
Bonita Montero <Bonita.Montero@gmail.com>: Oct 16 06:06PM +0200

AFAIK C++-strings are not guaranteed to be zero-terminated without
calling c_str(). I.e. when you do s[s.size()] you may be access the
string out of bounds.
jameskuyper@alumni.caltech.edu: Oct 16 09:35AM -0700

On Tuesday, October 16, 2018 at 12:06:35 PM UTC-4, Bonita Montero wrote:
> AFAIK C++-strings are not guaranteed to be zero-terminated without
> calling c_str(). I.e. when you do s[s.size()] you may be access the
> string out of bounds.
 
20.3.2.5p2 guarantees that, if s is an instance of
std::basic_string<charT>, then s[s.size] returns a reference to an
object with a value of charT().
"Öö Tiib" <ootiib@hot.ee>: Oct 16 09:40AM -0700

> >of constexpr is missing from C and so you have to use preprocessor
> >metaprogramming to handle things like that in it.
 
> And?
 
It works with text substitution. So its usage is ugly, hard to debug and
on case when recursive #include is needed (and for list of unknown
length it might be needed) then it is also often slow. There are
no type safety, and no comprehensible diagnostics. Consider:
 
constexpr auto x = {1, 2, "huh"};
 
We did forget to include <initializer_list> so it explicitly tells
that we are required to include it for deducing from brace-enclosed
initializer list. Pure magic and miracles. :D After including we will
get: "error: unable to deduce 'const std::initializer_list<const auto>'
from '{1, 2, "huh"}' note: deduced conflicting types for parameter
'auto' ('int' and 'const char*')".
 
Can you post how your preprocessor implementation of
std::initializer_list looks like and how it behaves in similar
situation?
Bonita Montero <Bonita.Montero@gmail.com>: Oct 16 08:09PM +0200

> 20.3.2.5p2 guarantees that, if s is an instance of
> std::basic_string<charT>, then s[s.size] returns a reference to an
> object with a value of charT().
 
... and also that this charT is 0?
"Öö Tiib" <ootiib@hot.ee>: Oct 16 11:54AM -0700

On Tuesday, 16 October 2018 21:09:18 UTC+3, Bonita Montero wrote:
> > std::basic_string<charT>, then s[s.size] returns a reference to an
> > object with a value of charT().
 
> ... and also that this charT is 0?
 
When charT is char (like it is on case of std::string) then yes.
jameskuyper@alumni.caltech.edu: Oct 16 12:56PM -0700

On Tuesday, October 16, 2018 at 2:09:18 PM UTC-4, Bonita Montero wrote:
> > std::basic_string<charT>, then s[s.size] returns a reference to an
> > object with a value of charT().
 
> ... and also that this charT is 0?
 
charT is the template parameter. The templates must be specialized for
charT == char, char16_t, char32_t, and wchar_t, and for each of those
types charT() works out to a value of 0 with the specified type. If you
want to create your own character class myChar, and provide a traits
class for it (for instance, by specializing std::traits<myChar>),
myChar() can return whatever value you want it to. Note that std::basic_string<myChar> will treat myChar() as the terminating
character for strings, just as '\0' is the terminating character for
std::basic_string<char>.
boltar@cylonhq.com: Oct 16 10:19AM

On Mon, 15 Oct 2018 18:40:01 +0100
>> can't even see the sub-threads.
 
>The likes of Hodgin subsist on inertia such as this; if enough of us use
>the post reporting feature Google might ban him.
 
Not a chance. Google don't give a damn about usenet and haven't since about
2 minutes after they bought up dejanews and fucked it up. Plus while annoying
he's not posted anything defamatory or illegal in any jurisdiction (unless
you count some mad muslim countries that have an issue with christians) and
I very much doubt google give a rats arse about off topic posts on a service
they long ago stopped caring about.
Neil Cerutti <neilc@norwich.edu>: Oct 16 03:28PM

> muslim countries that have an issue with christians) and I very
> much doubt google give a rats arse about off topic posts on a
> service they long ago stopped caring about.
 
I agree. The purchase of dejanews seems to have been an effort to
kill it off.
 
--
Neil Cerutti
Horizon68 <horizon@horizon.com>: Oct 15 03:47PM -0700

Hello...
 
About memory allocators..
 
I think that mingw uses MSVCRT memory allocator that scales well and
that is better than jemalloc and better than hoard, please notice it
here on the following benchmark:
 
https://github.com/andremussche/scalemm
 
But GCC on Linux uses ptmalloc2 memory allocator..
 
I have just took a look at the memory allocator of the GCC C and C++
compiler on Linux that is called ptmalloc2, and on a UMA machine with
four 10-core 2GHz Intel Xeon E7-4850 processors supporting two
hardware threads per core, the benchmark of the following
paper shows that ptmalloc2 is "scaling" decently, so i think
that ptmalloc2 is a decent choice.
 
Please read this paper to notice it:
 
https://arxiv.org/pdf/1503.09006.pdf
 
 
I have used gcc mingw to compile my scalable counting networks that
use a lot the MSVCRT memory allocator, thus they are scalable,
so my scalable reference counting with efficient support of weak
references does too scale very well, and my efficient Threadpool engines
that scale very well do scale very well too.
 
You can download them from my website:
 
https://sites.google.com/site/scalable68/
 
 
 
 
Thank you,
Amine Moulay Ramdane.
Horizon68 <horizon@horizon.com>: Oct 15 03:59PM -0700

On 10/15/2018 3:47 PM, Horizon68 wrote:
 
> About memory allocators..
 
> I think that mingw  uses MSVCRT memory allocator that scales well and
> that is better than jemalloc and better than hoard, please notice it
 
 
I correct: I mean microsoft MSVCRT memory allocator scales better than
jeMalloc and better than hoard.
 
 
 
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)