Monday, October 3, 2022

Digest for comp.lang.c++@googlegroups.com - 15 updates in 5 topics

"daniel...@gmail.com" <danielaparker@gmail.com>: Oct 03 02:09PM -0700

Hello everyone,
 
Is the C++ code below valid?
 
#include <iostream>
#include <string_view>
#include <string>
 
template <class T, class Enable = void>
class Foo
{};
 
template <class T>
class Foo<T,typename std::enable_if<std::is_same<T,std::string>::value>::type>
{
public:

void f(std::string s)
{
Foo<std::string_view> foo; // (*)
foo.f(s);
}
};
 
template <class T>
class Foo<T, typename std::enable_if<std::is_same<T, std::string_view>::value>::type>
{
public:

void f(std::string_view s)
{
std::cout << s << "\n";
}
};
 
int main()
{
Foo<std::string> foo;
foo.f("Hello World");
}
 
LLVM (clang-cl) says "yes", and outputs "Hello World".
 
Visual Studio 2022 (v143) says "no", "'f': is not a member of 'Foo<std::basic_string_view<char,std::char_traits<char>>,void>", 17
at line (*)
 
Both compiled with C++17.
 
Thanks,
Daniel
Bonita Montero <Bonita.Montero@gmail.com>: Oct 03 04:14AM +0200

Am 02.10.2022 um 21:46 schrieb Chris M. Thomasson:
 
> Using LL/SC can be tricky. You really need to isolate the reservation
> granule...
 
In essence, you're doing the same thing with CAS, but it's easier
to use since it eliminates the need for DWCAS for lock-free stacks.
 
>> But atomic increments, decrements, ands, ors or whatever
>> ebulated with LL/SC is sometimes slower.
 
> How many times do you spin on a SC failure before you get, pissed off?
 
With atomic non-CAS operations you never spin.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 02 07:43PM -0700

On 10/2/2022 7:14 PM, Bonita Montero wrote:
>> granule...
 
> In essence, you're doing the same thing with CAS, but it's easier
> to use since it eliminates the need for DWCAS for lock-free stacks.
 
Iirc, there was a paper on LL/SC and the ABA problem. I am not sure if
every implementation of LL/SC can get around it. Iirc, a LL/SC that will
make a SC fail if anything reads and/or writes from/to the RG should
definitely get around ABA. However, from experience, I would choose
something like cmpxchg8b over LL/SC any day.
 
 
 
>> How many times do you spin on a SC failure before you get, pissed off?
 
> With atomic non-CAS operations you never spin.
 
I was referring to SC failing. Why did it fail? Spuriously? From a read
into the reservation granule? If a CAS fails, we know it is because the
actual values were different. The compare part failed. There is a way to
attack CAS. Have a racing heard of threads setting the shared value to
random values. The a poor thread trying to do a CAS to update a
data-structure or something, just might fail a lot of times.
 
So, when a CAS fails, well, it's different than when a SC fails...
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 02 07:48PM -0700

On 10/2/2022 7:43 PM, Chris M. Thomasson wrote:
> random values. The a poor thread trying to do a CAS to update a
> data-structure or something, just might fail a lot of times.
 
> So, when a CAS fails, well, it's different than when a SC fails...
 
Iirc, the "weak" CAS in C++ allows for spurious failures.
Bonita Montero <Bonita.Montero@gmail.com>: Oct 03 04:53AM +0200

Am 03.10.2022 um 04:43 schrieb Chris M. Thomasson:
 
>> In essence, you're doing the same thing with CAS, but it's easier
>> to use since it eliminates the need for DWCAS for lock-free stacks.
 
> Iirc, there was a paper on LL/SC and the ABA problem. ...
 
There's no ABA-problem with LL/SC'd stacks since you can detect if
the word has changed to the same value.
 
> I was referring to SC failing. Why did it fail? Spuriously? ..
 
Only when the cacheline holding the word has been touched
by another thread.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 02 07:58PM -0700

On 10/2/2022 7:53 PM, Bonita Montero wrote:
 
>> Iirc, there was a paper on LL/SC and the ABA problem. ...
 
> There's no ABA-problem with LL/SC'd stacks since you can detect if
> the word has changed to the same value.
 
Iirc, it depended on how the LL/SC was implemented, how sensitive it was
to alterations in the reservation granule.
 
 
>> I was referring to SC failing. Why did it fail? Spuriously? ..
 
> Only when the cacheline holding the word has been touched
> by another thread.
 
This would be the weak form of CAS wrt C++. A "true" RMW CAS will fail
only when the condition (the compare part) fails. A bus lock might need
to be used under heavy conditions. Scott knows about that.
Bonita Montero <Bonita.Montero@gmail.com>: Oct 03 08:27AM +0200

Am 03.10.2022 um 04:58 schrieb Chris M. Thomasson:
 
>> the word has changed to the same value.
 
> Iirc, it depended on how the LL/SC was implemented, how
> sensitive it was to alterations in the reservation granule.
 
It may fail only if the cacheline has been evicted for other
reasons than that the SC'd word changed.
scott@slp53.sl.home (Scott Lurndal): Oct 03 02:01PM

>> handled by the CPU, but rather by the point of coherency (LLC
>> or PCI-Express/CXL endpoint).
 
>I don't think so.
 
The processors that we build implement it exactly as I say.
 
>IMHO, a typical implementation is that CPU acquires the ownership
>of location and refuses all attempts by other agents to take it back
>until both parts of CAS are completed and committed to L1$.
 
That hasn't been my experience (in the past with Intel/AMD x86_64
where we extended the coherency protocol from HT/QPI over a high
speed fabric (IB/10Ge), and currently with custom high-end ARM64
processors that my CPOE sells).
 
Note that I said at the "point of coherency". That may very
well be the L1 cache for some processors, the L2/LLC for others
(depending on cache inclusivity etc.).
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 03 01:49PM -0700

On 10/2/2022 11:27 PM, Bonita Montero wrote:
>> sensitive it was to alterations in the reservation granule.
 
> It may fail only if the cacheline has been evicted for other
> reasons than that the SC'd word changed.
 
Reading/writing to the reservation granule (RG) can cause an issue.
Iirc, the RG can be bigger than a l2 cacheline...
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 03 01:49PM -0700

On 10/3/2022 7:01 AM, Scott Lurndal wrote:
 
> Note that I said at the "point of coherency". That may very
> well be the L1 cache for some processors, the L2/LLC for others
> (depending on cache inclusivity etc.).
 
Correct.
Jivanmukta <jivanmukta@poczta.onet.pl>: Oct 03 04:53PM +0200

W dniu 28.09.2022 o 13:53, Jivanmukta pisze:
> ...
> for (auto dir = vendor_frameworks_dirs.begin(); dir !=
> vendor_frameworks_dirs.end(); ++dir)
 
Changing for-loop to:
 
for (auto dir : vendor_frameworks_dirs)
 
solved the problem. I have no error.
Problem closed.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Oct 03 02:32AM -0700


> Given C++ supports function signature overloads,
 
What C++ supports is function name overloading (and also operator
overloading). "Function signature overloads" is a meaningless
phrase.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Oct 03 02:38AM -0700


> Replacing the comma at the end of each line by a semicolon (and
> possibly surrounding the whole thing with curly braces) yields
> equivalent code.
 
In C++ that rule does not hold, because of the possibility of an
overloaded operator,(). Indeed in this case it appears that
there is an operator,() overload, and that is what makes this
statement work; changing the statement to be a series of
semicolon-terminated statements wouldn't work at all.
Juha Nieminen <nospam@thanks.invalid>: Oct 03 10:48AM


> What C++ supports is function name overloading (and also operator
> overloading). "Function signature overloads" is a meaningless
> phrase.
 
"Function signature overload" would imply that two functions with the
same signature (ie. not only the same name, but the same amount of
parameters, each being of the exact same type, and the same visibility
scope) could be someone "overloaded". Which is of course not possible.
 
(Technically speaking you could try that with inline functions, but
having more than one different implemenation for a particular inline
function signature is quite explicitly UB in the standard.)
David Brown <david.brown@hesbynett.no>: Oct 03 11:58AM +0200

On 02/10/2022 22:05, Manfred wrote:
> On 10/2/2022 4:20 PM, David Brown wrote:
 
<snip>
 
 
> I am pretty confident that the construct that you suggest as "the right
> way" was not the intention of the language designers - think e.g. IO
> manipulators.
 
(As an aside, I think the IO manipulators are a terrible concept - modal
settings for an IO stream to change the format is just /wrong/.)
 
IO manipulators are not affected by evaluation order beyond the general
rule of evaluating a subexpression before it is used.
 
Consider :
 
cout << hex << f();
 
This is treated as "(cout << hex) << f();". It doesn't matter if the
"(cout << hex)" is evaluated before "f()", in regard to the output -
both are evaluated before the output of "f()" is actually sent to the
stream.
 
 
Certainly a lot of people have viewed the iostreams syntax as implying
that "cout << f1() << f2()" evaluated "f1()" before "f2()". And
certainly that is a reasonable request for a language (though it is also
reasonable to say the order should not be specified). The issue is that
no matter what you might prefer, or what the iostreams designers might
have intended, the language (prior to C++17) did not guarantee such an
evaluation order. So if your code relied on the order of side-effects
of "f1()" and "f2()", then prior to C++17 you had to order it yourself
(such as by using temporaries, or sticking to a compiler that guaranteed
and documented the evaluation order).
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)