Tuesday, October 4, 2022

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

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 04 10:53AM -0700

On 10/3/2022 1:49 PM, Chris M. Thomasson wrote:
>> 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...
 
Iirc, a RG can be several contiguous L2 cachelines. So, working with
LL/SC can be a bit tricky. One generally wants to align the memory on a
natural RG boundary, and pad it up to the size of a RG. False sharing a
RG is HORRIBLE! Really bad. Think live lock...
 
Wrt CAS, I tend to focus on a single L2 cacheline. False sharing a L2
cacheline wrt pure RMW CAS, well, its definitely not ideal, but at least
CAS's can complete...
 
Humm...
David LaRue <huey.dll@tampabay.rr.com>: Oct 03 11:52PM

"daniel...@gmail.com" <danielaparker@gmail.com> wrote in
 
> Hello everyone,
 
> Is the C++ code below valid?
 
When asking such a question, you should specify the standard or compilers
that you are interested in using. As you see from the results below, one
compiler says it isn't valid and the other says it is valid. The
difference is likely in the standard that each implements as its
standard. Note that the applicable standard may be controlled by a
setting.

"daniel...@gmail.com" <danielaparker@gmail.com>: Oct 03 06:07PM -0700

On Monday, October 3, 2022 at 7:53:04 PM UTC-4, David LaRue wrote:
> difference is likely in the standard that each implements as its
> standard. Note that the applicable standard may be controlled by a
> setting.
 
I'm interested in responses about whether the posted code is valid
C++ code or not for standards C++ 11 or greater. I'm not interested
in whether it "works" for one compiler or another, only whether it's
valid C++ code according to the standard.
 
Thanks,
Daniel
"daniel...@gmail.com" <danielaparker@gmail.com>: Oct 03 06:42PM -0700

> C++ code or not for standards C++ 11 or greater. I'm not interested
> in whether it "works" for one compiler or another, only whether it's
> valid C++ code according to the standard.
 
Or rather, since I used std:string_view in the example code, for C++ 17
or later :-)
Juha Nieminen <nospam@thanks.invalid>: Oct 04 06:05AM

> When asking such a question, you should specify the standard or compilers
> that you are interested in using.
 
But he did:
 
Bo Persson <bo@bo-persson.se>: Oct 04 01:47PM +0200


> 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.
 
Seems like g++ (v12.2) agrees with VC++, and also points out the problem
that the specialization is defined after its first use.
 
My (non-language-lawyer) interpretation is that since f and its local
foo don't depend on the template parameter T, they should be looked up
immediately, and not at the point of instantiation.
"daniel...@gmail.com" <danielaparker@gmail.com>: Oct 04 05:22AM -0700

On Tuesday, October 4, 2022 at 7:48:09 AM UTC-4, Bo Persson wrote:
 
> My (non-language-lawyer) interpretation is that since f and its local
> foo don't depend on the template parameter T, they should be looked up
> immediately, and not at the point of instantiation.
 
Thanks!
Daniel
Juha Nieminen <nospam@thanks.invalid>: Oct 04 06:02AM


> for (auto dir : vendor_frameworks_dirs)
 
> solved the problem. I have no error.
> Problem closed.
 
"It doesn't complain anymore" does not necessarily mean that the problem
has been solved. It's possible that you are simply masking the problem.
 
You never submitted a minimal complete program so we could analyze
whether there is an actual problem or whether the debugger you are
using is just flawed. Thus, we will never know (unless someone goes
through the trouble of combing through the code you did post).
 
And by the way, you should use 'auto&' in that kind of loop, not 'auto'.
This especially if the elements are large (because you would be
needlessly deep-copying them). You should only use 'auto' if you
explicitly *need* to deep-copy each element into the variable for
whatever reason. (You can also use it if the elements are of an
elementary type like 'int', but even then, theres probably no
benefit.)
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.

No comments: