Monday, September 24, 2018

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

Horizon68 <horizon@horizon.com>: Sep 24 02:13PM -0700

Hello,
 
 
About GCC and ptmalloc2..
 
I have just took a look at the memory manager of the GCC C and C++
compiler 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 correct choice.
 
Please read this paper to notice it:
 
https://arxiv.org/pdf/1503.09006.pdf
 
 
Thank you,
Amine Moulay Ramdane.
Siri Cruise <chine.bleu@yahoo.com>: Sep 23 08:37PM -0700

In article <ln8t3ramf6.fsf@kst-u.example.com>, Keith Thompson <kst-u@mib.org>
wrote:
 
 
> > This would preclude it from being useful in a switch, by itself.
 
> For integer operands, the result is of type std::strong_ordering, and
> the value is one of std::less, std::equal, or std::greater.
 
#define STRONGORDER(x) ((int)copysign(1, x))
 
This will return -1, 0, or 1 for an arithmetic type x.
 
 
#define STRONGORDER2(x, y) ((int)copysign(1, (double)(x)-(double)(y)))
 
The cast is to allow comparison of unsigned in a natural way.
 
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
An almond doesn't lactate. This post / \
Yet another supercilious snowflake for justice. insults Islam. Mohammed
Wouter Verhelst <w@uter.be>: Sep 22 11:08AM +0200

On 9/21/18 9:53 PM, Rick C. Hodgin wrote:
> On 9/21/2018 3:12 PM, Siri Cruise wrote:
>> Doesn't everyone want to program in 1966 Fortran?
 
> People often make fun of Fortran,
 
Yes, but that's not the FORTRAN (sic) from 1966, which has evolved
massively since, not only in the official recommended capitalization.
 
> but it's still a first-tier
> compiler receiving modern optimizations provided for by Intel
> (along with their C++ compiler).
 
And it's a first-tier compiler in the gcc set of compilers, too:
https://gcc.gnu.org/wiki/GFortran
 
 
> I regularly hear speakers on compute-related videos report
> that their scientists say there isn't a better language to
> express the formulas they use for calculation than in Fortran.
 
Yup, it definitely is not a fringe language. When I run this on my
laptop (this looks up how many source packages in Debian build-depend on
the gfortran compiler):
 
wouter@gangtai:~$ grep-dctrl -FBuild-Depends -sPackage gfortran <
/var/lib/apt/lists/ftp.be.debian.org_debian_dists_sid_main_source_Sources|sort
-u|wc -l
 
... then the result is 204. It includes things like BLAS (which itself
is a dependency for LAPACK) and FFTW, which are fairly often-used
scientific libraries (although I haven't got the faintest idea as to how
they would be used). Hilariously, it also includes llvm-toolchain-7
(you'd think they'd bootstrap their own fortran compiler rather than
using the GNU one). It doesn't include indirect build-dependencies
though, so there are more things that somehow require fortran code than
what's in that list; I believe pypi is one of them.
Wouter Verhelst <w@uter.be>: Sep 24 08:19AM +0200

On 9/22/18 11:08 AM, Wouter Verhelst wrote:
> It doesn't include indirect build-dependencies
> though, so there are more things that somehow require fortran code than
> what's in that list; I believe pypi is one of them.
 
That last statement is, of couse, complete nonsense. It should read
"numpy", because pypi is a repository of python packages, not a python
package :-)
 
Sorry for the confusion (but then I'm not really a python programmer)
guinness.tony@gmail.com: Sep 24 01:01AM -0700

On Sunday, 23 September 2018 23:17:49 UTC+1, Keith Thompson wrote:
 
> > This would preclude it from being useful in a switch, by itself.
 
> For integer operands, the result is of type std::strong_ordering, and
> the value is one of std::less, std::equal, or std::greater.
 
std::less and std::greater are class templates in <functional>.
std::equal is a class template in <algorithm>.
 
As I read it, the three-way comparison operator will yield values of
 
std::strong_ordering::less,
std::strong_ordering::equal,
std::strong_ordering::greater
 
However, as you suspect below, these turn out to be individual instances of
std::strong_ordering itself, rendering them ineligible as switch() cases.
 
> would allow its use in switch statements, but in fact it's a class type.
> (It's possible C++20 has some feature that permits its use in a switch
> statement. I haven't checked.)
 
I believe usage is intended to follow this pattern (which compiles (with
-std=c++2a) under the latest experimental version of clang++):
 
#include <compare>
#include <iostream>
 
void test( int const a, int const b )
{
auto const x = a <=> b;
 
if ( std::is_lt( x ) )
{
std::cout << "less" << std::endl;
}
 
if ( std::is_lteq( x ) )
{
std::cout << "less-or-equal" << std::endl;
}
 
if ( std::is_eq( x ) )
{
std::cout << "equal" << std::endl;
}
 
if ( std::is_gteq( x ) )
{
std::cout << "greater-or-equal" << std::endl;
}
 
if ( std::is_gt( x ) )
{
std::cout << "greater" << std::endl;
}
 
if ( std::is_neq( x ) )
{
std::cout << "not-equal" << std::endl;
}
}
 
int main()
{
test( 10, 20 );
test( 10, 10 );
test( 20, 10 );
}
 
> Details are in
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/n4727.pdf
 
Indeed, although the wording surrounding this topic is probably incomplete.
One has to first discover std::is_eq() et al; then discover that they take
arguments of type std::weak_ordering or std::partial_ordering; then note that
std::strong_ordering has conversion operators to std::weak_ordering and to
std::partial_ordering and that the three-way comparison yields a value of type
std::strong_ordering.
 
An example, in the standard, would be welcome.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Sep 24 11:32AM +0100

>> the value is one of std::less, std::equal, or std::greater.
 
> #define STRONGORDER(x) ((int)copysign(1, x))
 
> This will return -1, 0, or 1 for an arithmetic type x.
 
I can't see how that can ever be zero. Also, "arithmetic type" includes
the complex types. I think the phrase "real arithmetic type" is the one
you want.
 
> #define STRONGORDER2(x, y) ((int)copysign(1, (double)(x)-(double)(y)))
 
> The cast is to allow comparison of unsigned in a natural way.
 
Obviously this has the same problem of never being equal to zero, but it
will also run into trouble where unsigned a type has a range that goes
beyond that which 'double' can represent exactly.
 
--
Ben.
Vir Campestris <vir.campestris@invalid.invalid>: Sep 24 09:53PM +0100

On 20/09/2018 11:50, Bart wrote:
> I don't think I've ever considered that aspect, probably few have,
> although many will know that C started off with a ridiculously large
> number of precedences.
 
... which is why I bracket everything. I'm "agnostic" in this - I don't
know the full order of precedences, and I don't believe you do either.
 
Nobody has even satisfactorily explained to me why
 
2 + 3 * 4 isn't 20. The way every kid learning arithmetic assumes it
will be.
 
Except it's always been that way. Or mention the mathematician's a+bc,
which means "a + product of b and c". Which is just premature
optimisation :)
 
Andy
Juha Nieminen <nospam@thanks.invalid>: Sep 24 01:38PM

Why doesn't this compile?
 
//------------------------------------------------------------
template<typename... Types>
class MyClass
{
public:
MyClass(Types&&...) {}
};
 
template<typename... Types>
MyClass<Types...> instantiate(Types... objects)
{
return { objects... };
}
 
int main()
{
auto instance = instantiate(1, 2, 3);
}
//------------------------------------------------------------
 
clang says:
 
test.cc:12:12: error: no matching constructor for initialization
of 'MyClass<int, int, int>'
return { objects... };
^~~~~~~~~~~~~~
 
(Note that I'm not asking "how do I make this compile?" I'm asking *why*
doesn't this compile. And yes, I'm taking the parameters to the
instantiate() function by value on purpose.)
"Öö Tiib" <ootiib@hot.ee>: Sep 24 07:18AM -0700

On Monday, 24 September 2018 16:39:08 UTC+3, Juha Nieminen wrote:
 
> (Note that I'm not asking "how do I make this compile?" I'm asking *why*
> doesn't this compile. And yes, I'm taking the parameters to the
> instantiate() function by value on purpose.)
 
That is interesting question as it is "why lvalue can't be bound to rvalue
reference?" Such are language rules from C++11 and these were discussed
for almost decade. Perhaps it was to guard us from accidentally moving
from lvalues.
 
I understood that you did not want to see example how to make it to
compile but may be someone else is interested so I post it anyway. Just
don't look. ;) That will compile:
 
#include <utility>
 
template<typename... Types>
class MyClass
{
public:
MyClass(Types&&...) {}
};
 
template<typename... Types>
MyClass<Types...> instantiate(Types... objects)
{
return { std::forward<Types>(objects)... };
}
 
int main()
{
auto instance = instantiate(1, 2, 3);
}
Juha Nieminen <nospam@thanks.invalid>: Sep 24 06:49PM

>> MyClass(Types&&...) {}
>>};
 
> The parameters are rvalue references, so they wont bind to lvalues.
 
That doesn't make much sense to me, because this compiles just fine:
 
//--------------------------------------------------------
template<typename... Types>
class MyClass
{
public:
MyClass(Types&&...) {}
};
 
template<typename... Types>
MyClass<Types...> instantiate(Types&&... objects)
{
return { objects... };
}
 
int main()
{
int a = 1, b = 2, c = 3;
auto instance = instantiate(a, b, c);
}
//--------------------------------------------------------
Juha Nieminen <nospam@thanks.invalid>: Sep 24 08:35PM

> { int i = 0;
> instantiate( i ); /* instantiate< int& >( int& ) */
> instantiate( 0 ); /* instantiate< int >( int&& ) */ }
 
I'm still very puzzled.
 
The original problem is that the class constructor takes things by
rvalue-reference (rather than "universal reference", even though
it looks like it does), and the original code attempted to give it
an lvalue, which cannot be given as an rvalue-reference.
 
However, in my second example instantiate(i) causes the parameter
to be given to the function as an lvalue-reference, which is then
given as-is to the class constructor, and it compiles. Which would
mean that an lvalue-reference is ok to be given to a function taking
an rvalue-reference, even though an lvalue is not.
 
Why?
 
And why is
 
template<typename... T>
void foo(T&&...);
 
different from
 
template<typename... T>
class C
{
public:
C(T&&...);
};
 
Both look like an "universal reference" situation, but apparently
the second isn't?
"Öö Tiib" <ootiib@hot.ee>: Sep 24 01:53PM -0700

On Monday, 24 September 2018 23:35:41 UTC+3, Juha Nieminen wrote:
> };
 
> Both look like an "universal reference" situation, but apparently
> the second isn't?
 
One is template of function other is non-template constructor of
template of class.
Vir Campestris <vir.campestris@invalid.invalid>: Sep 24 09:15PM +0100

On 22/09/2018 13:08, Tim Rentsch wrote:
> sequences of one or more bytes, the number, order, and
> encoding of which are either explicitly specified or
> implementation-defined.
.. which neatly leaves in those odd machines that use a BCD
representation for their numbers (a byte holds 0-99).
 
Though I haven't seen one in 30 odd years, and not running C, never mind
C++!
 
Andy
scott@slp53.sl.home (Scott Lurndal): Sep 24 08:29PM

>representation for their numbers (a byte holds 0-99).
 
>Though I haven't seen one in 30 odd years, and not running C, never mind
>C++!
 
I still use one now and again, albeit generally in emulation. It never
had a C compiler, although we looked into it in the 1980's, but since
operands ranged from 1 to 100 units (BCD digits or EBCDIC bytes with the
zone digit ignored) for arithmetic operations, there was no consensus
internally on how that would map to 'int' (7-digit with leading sign or
8 unsigned digits consumed 32-bits of memory, so that was one of the choices
we looked at, but in the end, there was no customer demand for C on
that platform and that was that).
ram@zedat.fu-berlin.de (Stefan Ram): Sep 24 02:17PM

> public:
> MyClass(Types&&...) {}
>};
 
The parameters are rvalue references, so they wont bind to lvalues.
 
To make this comp...
 
>Note that I'm not asking "how do I make this compile?"
 
Ok.
ram@zedat.fu-berlin.de (Stefan Ram): Sep 24 07:06PM

>That doesn't make much sense to me, because this compiles just fine:
>template<typename... Types>
>MyClass<Types...> instantiate(Types&&... objects)
 
The template arguments are deduced through template argument
deduction.
 
template< class T > void instantiate( T && ){}
 
int main()
{ int i = 0;
instantiate( i ); /* instantiate< int& >( int& ) */
instantiate( 0 ); /* instantiate< int >( int&& ) */ }
ram@zedat.fu-berlin.de (Stefan Ram): Sep 24 07:32PM

>instantiate( i ); /* instantiate< int& >( int& ) */
 
There is a special rule for that, introduced to make
»::std::forward« work:
 
If the parameter type is an rvalue reference to a cv-unqualified
template parameter (so-called "forwarding reference"), and the
corresponding function call argument is an lvalue, the type "lvalue
reference to the type of the argument" is used in place of the type
of the argument for deduction.
Real Troll <real.troll@trolls.com>: Sep 23 08:59PM -0400

On 23/09/2018 19:30, Jorgen Grahn wrote:
> offtopic topics in comp.lang.c++. Brian mentioning it as a reason
> was kind of on topic; debating it is not.
 
> /Jorgen
 
Who made you the moderator on these newsgroups? Please refrain from
imposing your authority on anybody here. You are not in charge here;
If you don't like something then use the kill-filter of your
newsreader. If you don't know how to do it then ask for help on the
forums of whatever newsreader you are using.
 
You have no right to decide what is acceptable and what is not.
 
Brian was prepared to kill somebody for $150 so it was right and proper
to tell him this is not OK on these newsgroups. North Koreans do such
things; Some of you may remember that they hired two women to kill one
of theirs at Malaysia Airport. The girls were paid peanuts and now they
are now likely to be hanged in Malaysia. Brian wants to do exactly the
same here.
 
Good bye.
"Öö Tiib" <ootiib@hot.ee>: Sep 23 07:19PM -0700

On Monday, 24 September 2018 03:57:50 UTC+3, Real Troll wrote:
 
> Brian was prepared to kill somebody for $150 so it was right and proper
> to tell him this is not OK on these newsgroups.
 
What evidence do you have that usage or demonstration of Brian's tools
is lethal? I thought it is relatively safe, more so in gun-free
environment.
James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 23 11:25PM -0400

On 09/23/2018 10:19 PM, Öö Tiib wrote:
 
> What evidence do you have that usage or demonstration of Brian's tools
> is lethal? I thought it is relatively safe, more so in gun-free
> environment.
 
The key point in not how dangerous the demonstration was likely to be,
but how dangerous Brian thought it would be. His assessment of the
danger level frightened him enough to make him decide not to attend;
that being the case, his desire to have someone else do the
demonstration for him, someone who would be facing precisely the same
danger, does not reflect well on his character, regardless of how little
validity there might be in his fears.
Also note that he appears to consider the restrictions on guns in that
convention as making it more dangerous, by reason of denying the
participants who obey those rules the opportunity to defend themselves
against participants who chose not to obey them.
jameskuyper@alumni.caltech.edu: Sep 23 09:05PM -0700

On Sunday, September 23, 2018 at 8:57:50 PM UTC-4, Real Troll wrote:
> > was kind of on topic; debating it is not.
 
> > /Jorgen
 
> Who made you the moderator on these newsgroups?
 
No one. If he was the moderator, he would not need to ask this.
 
> Please refrain from
> imposing your authority on anybody here.
 
He has no authority, so it's a good thing he's not trying to assert any. He's asking, without the authority to make it an order, that people act better they need to. Is that too much to ask? Apparently.
woodbrian77@gmail.com: Sep 23 09:24PM -0700

On Sunday, September 23, 2018 at 10:25:32 PM UTC-5, James Kuyper wrote:
> demonstration for him, someone who would be facing precisely the same
> danger, does not reflect well on his character, regardless of how little
> validity there might be in his fears.
 
 
"Blessed are you when people insult you, persecute you and falsely
say all kinds of evil against you because of Me." Matthew 5:11
 
Maybe you are not happy with my embracing Martin Luther
King Jr's belief that hiring should be based not on race, but
on character.
 
 
jameskuyper@alumni.caltech.edu: Sep 24 08:26AM -0700

> On Sunday, September 23, 2018 at 10:25:32 PM UTC-5, James Kuyper wrote:
...
> > demonstration for him, someone who would be facing precisely the same
> > danger, does not reflect well on his character, regardless of how little
> > validity there might be in his fears.
...
> Maybe you are not happy with my embracing Martin Luther
> King Jr's belief that hiring should be based not on race, but
> on character.
 
I said nothing about that matter one way or another, and I have no idea
what could even lead you to make that comment.
In fact, I believe that the most important characteristics to consider
when hiring people are competence and work habits. In particular, a
habit of starting arguments about politics or religion while on the job
should properly be held against you (what you do on your own time in
matters unconnected to your employer is of no legitimate concern for
your employer).
Character is important, but as a highly subjective judgment call, I
suspect some kind of prejudice might be being covered up whenever
character assessment is used to justify rejection of an apparently well-
qualified prospect or acceptance of an apparently poorly-qualified
prospect. Race doesn't belong anywhere in the hiring process.
"Öö Tiib" <ootiib@hot.ee>: Sep 24 09:26AM -0700

> character assessment is used to justify rejection of an apparently well-
> qualified prospect or acceptance of an apparently poorly-qualified
> prospect. Race doesn't belong anywhere in the hiring process.
 
His dim accusation in religious and racial bigotry seemed strangely
groundless, out of context and uncalled for. Does he really consider
being a coward as his religious and racial identification? If not
then it felt like his goal was just somehow to try and damage
reputation of you and/or your employer out of blue.
David Brown <david.brown@hesbynett.no>: Sep 24 07:56AM +0200

On 24/09/18 00:09, Vir Campestris wrote:
 
>> char two=2
>> char four=two+two;
 
> char may be int8_t or uint8_t - that's implementation dependent.
 
The most common implementations of int8_t and uint8_t will be:
 
typedef signed char int8_t;
typedef unsigned char uint8_t;
 
In theory, one of int8_t or uint8_t could be a typedef for plain char,
but there is no advantage in it.
 
Plain char may be signed or unsigned in any given implementation.
 
> IIRC it doesn't even have to be 8 bits - but I don't know any
> architecture where it isn't. <fx cue exceptions>
 
"char" does not have to be 8-bit. In the modern world, there are some
DSP's that have 16-bit or even 32-bit char. On such implementations,
"uint8_t" and "int8_t" do not exist.
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)