Friday, March 3, 2017

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

legalize+jeeves@mail.xmission.com (Richard): Mar 03 12:58AM

[Please do not mail me a copy of your followup]
 
Ian Collins <ian-news@hotmail.com> spake the secret code
 
>I had a look based on your recommendation. It looks like a decent tool,
>but it appears to be inextricably coupled to cmake which is awkward if
>you have an existing projects that use a different build process.
 
Yes, that is the biggest shortcoming for CLion at the moment. It does
well on refactoring, however:
<https://github.com/LegalizeAdulthood/refactor-test-suite/blob/master/SummaryResults.md>
I haven't rerun the tests on the latest build (it's been over a year
since I ran the test suite), so their support is certainly better now.
 
That alone could be the deciding factor for some people; automated
high quality refactoring tools can make the difference between code
that gets incrementally messier and code that gets incrementally
cleaner over time.
 
CMake continues to gain traction for builds over time and it isn't
hard to convert a reasonably sized code base to CMake. (I've done it
a couple of times now for ~1M LOC code bases.) YMMV.
--
"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>
legalize+jeeves@mail.xmission.com (Richard): Mar 03 01:00AM

[Please do not mail me a copy of your followup]
 
Vir Campestris <vir.campestris@invalid.invalid> spake the secret code
 
>>[idiot says something on the internet]
>Are you suggesting that the downloads on JetBrains' web site have
>malware in them?
 
No, he's just being a retard. The JetBrains distributions do not have
malware.
--
"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>
Ian Collins <ian-news@hotmail.com>: Mar 03 02:06PM +1300

On 03/ 3/17 01:58 PM, Richard wrote:
> <https://github.com/LegalizeAdulthood/refactor-test-suite/blob/master/SummaryResults.md>
> I haven't rerun the tests on the latest build (it's been over a year
> since I ran the test suite), so their support is certainly better now.
 
How easy would it be to apply your refactoring test suite to another IDE
(my experience with NetBeans is it works slightly better than VS2015)?
 
> high quality refactoring tools can make the difference between code
> that gets incrementally messier and code that gets incrementally
> cleaner over time.
 
I agree, that was one of the reasons I tried it.
 
> CMake continues to gain traction for builds over time and it isn't
> hard to convert a reasonably sized code base to CMake. (I've done it
> a couple of times now for ~1M LOC code bases.) YMMV.
 
We use ninja+premake, so converting wouldn't be too hard (but time
consuming) if there weren't any adverse impacts on build time...
 
--
Ian
Moai <penultimategrill@gmail.com>: Mar 03 04:11AM -0500

On 2017-03-02 12:30, Richard wrote:
>> How can you even use CLion if you can't compile it?
 
> There's this new thing called the internet that allows you to obtain
> executable files.
 
Oh... so you meant you can't use it, unless you specifically use the
exact software and hardware platforms it was compiled for.
It's unusable unless those conditions are met.
Manfred <noname@invalid.add>: Mar 03 04:57PM +0100

On 3/2/2017 2:03 AM, Richard wrote:
>> too), and its standard conformance is much better than Microsoft's.
> Sorry, this hasn't been true for a while now. Update your information
> on VC.
 
A couple of examples:
issue 1 (MFC):
Look at the current implementation of MFC CArray::SetSize
 
A library that copies C++ objects via memcpy is IMHO not the best
available out there. (BTW this has been there since the beginning of
time, but it is to be noted that this behaviour is now specified in the
official documentation)
 
issue 2 (std::thread):
adapted from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68784
[code]
#include <iostream>
#include <unordered_map>
#include <thread>
#include <mutex>
 
// note the ht argument explicitly passed by reference
void thread_add(std::unordered_map<int, int>& ht, int from, int to)
{
for (int i = from; i <= to; ++i)
{
static std::mutex mtx;
std::unique_lock<std::mutex> lck(mtx);
ht.insert(std::unordered_map<int, int>::value_type(i, 0));
}
}
 
int main()
{
std::unordered_map<int, int> ht;
std::thread t[2];
 
t[0] = std::thread(thread_add, ht, 0, 9); // should be std::ref(ht)
t[1] = std::thread(thread_add, ht, 10, 19); // same here
 
t[0].join();
t[1].join();
 
std::cout << "size: " << ht.size() << std::endl;
}
[/code]
 
Note that this code contains an error: in order to pass arguments to
std::thread by reference the standard /requires/ usage of std::ref.
gcc correctly issues a compilation error, compiles and runs OK with
std::ref in place.
VS2015 compiles cleanly /without/ std::ref, and at runtime it silently
reports the /incorrect/ result:
size: 0
 
IMHO this kind of issues /do/ matter if you are a newbie (actually they
do matter if you are an experienced programmer as well, but in this case
they probably only cost you time, and do not affect your results)
Cholo Lennon <chololennon@hotmail.com>: Mar 03 01:31PM -0300

On 03/03/2017 12:57 PM, Manfred wrote:
> available out there. (BTW this has been there since the beginning of
> time, but it is to be noted that this behaviour is now specified in the
> official documentation)
 
Well, you can't use MFC as an example! MFC is an ancient library (almost
deprecated) that is not maintained by the same group that develops the
compiler or the C++ library.
 
 
> IMHO this kind of issues /do/ matter if you are a newbie (actually they
> do matter if you are an experienced programmer as well, but in this case
> they probably only cost you time, and do not affect your results)
 
All compilers have bugs, just check https://gcc.gnu.org/bugzilla/
 
 
--
Cholo Lennon
Bs.As.
ARG
legalize+jeeves@mail.xmission.com (Richard): Mar 03 05:51PM

[Please do not mail me a copy of your followup]
 
Manfred <noname@invalid.add> spake the secret code
 
>A couple of examples:
>issue 1 (MFC):
>Look at the current implementation of MFC CArray::SetSize
 
Since when is MFC part of the C++ standard?
 
>VS2015 compiles cleanly /without/ std::ref, and at runtime it silently
>reports the /incorrect/ result:
>size: 0
 
Since when is the standard requiring that you emit an error in this
case?
 
I'm not saying the behavior of emitting an error isn't desirable.
 
Your claim was that the compiler wasn't standards compliant and you
dredge up two examples that aren't covered by the standard.
--
"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>
legalize+jeeves@mail.xmission.com (Richard): Mar 03 05:53PM

[Please do not mail me a copy of your followup]
 
penultimategrill@gmail.com spake the secret code
 
>Oh... so you meant you can't use it, unless you specifically use the
>exact software and hardware platforms it was compiled for.
>It's unusable unless those conditions are met.
 
You are intentionally trying to make a problem where none exists.
 
Have you even tried it? Did you even google "CLion requirements"?
<https://www.jetbrains.com/help/clion/2016.3/requirements-for-clion.html>
 
No, you didn't. You're just armchair posturing about something you
don't know anything about.
--
"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>
legalize+jeeves@mail.xmission.com (Richard): Mar 03 05:56PM

[Please do not mail me a copy of your followup]
 
Ian Collins <ian-news@hotmail.com> spake the secret code
>> since I ran the test suite), so their support is certainly better now.
 
>How easy would it be to apply your refactoring test suite to another IDE
>(my experience with NetBeans is it works slightly better than VS2015)?
 
I run the tests by hand, which is why I don't slavishly rerun all the
tests for every new build. I haven't found a reliable way (except
for clang-tidy which is batch oriented anyway) to run the tests in an
automated way.
 
So, difficulty level is easy, but tedium/annoyance level is high.
 
I encourage proponents of other IDEs to run the test suite and make a
pull request with the results (hint hint :). Even partial results for
Rename, Extract Function/Method are useful since that is what you do
most of the time.
 
>> a couple of times now for ~1M LOC code bases.) YMMV.
 
>We use ninja+premake, so converting wouldn't be too hard (but time
>consuming) if there weren't any adverse impacts on build time...
 
CMake supports ninja as a project generator.
--
"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>
Manfred <noname@invalid.add>: Mar 03 08:43PM +0100

On 3/3/2017 6:51 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
 
> Manfred <noname@invalid.add> spake the secret code
> <o9c3pj$1gq0$1@gioia.aioe.org> thusly:
 
<snip>
>> issue 1 (MFC):
>> Look at the current implementation of MFC CArray::SetSize
 
> Since when is MFC part of the C++ standard?
This example is obviously primarily about quality of library code
(shipped with VC).
Nevertheless it easy to see that copying objects of class type via
memcpy is in general a standard violation - you can't copy objects
without invoking copy constructors, right?
 
>> size: 0
 
> Since when is the standard requiring that you emit an error in this
> case?
If you read n4296@30.3.1.2 (thread constructors) you see that the
function arguments are rvalue references (on purpose).
If you read n4296@4.1 (lvalue to rvalue conversion) you see that (clause
2.4) the rvalue references passed to the thread constructor are
/prvalues/ for temporaries (thus _not_ lvalues)
If you read n4296@8.5.3 (References) you see that /only/ const
references (clause 5.2) can be bound to prvalues. Therefore the prvaules
above /cannot/ be bound to the non-const reference arg of 'thread_add'
in the example
 
(Moreover, if you read n4296@3.10 (lvalues and rvalues) clause 2, an
explicit note explains non direct binding of rvalue references to lvalue
references)
 
It is clear that a conforming compiler /must/ abort compilation and emit
an error for the code in the example.
 
But even if the above standardese is not straightforward (by the way, if
you look at it, it is fundamental application of rvalue/lvalue
semantics), the simple result "size: 0" should trigger a bell singing
that the compiler is not doing what the code says.
 
 
> I'm not saying the behavior of emitting an error isn't desirable.
No, it's just /mandatory/
(compiler warnings are either desirable or not, errors are either
mandatory or forbidden)
 
 
> Your claim was that the compiler wasn't standards compliant and you
> dredge up two examples that aren't covered by the standard.
 
I think I answered to that.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 03 08:51PM +0100

On 3/3/2017 8:43 PM, Manfred wrote:
> references)
 
> It is clear that a conforming compiler /must/ abort compilation and emit
> an error for the code in the example.
 
I haven't checked up on your references, but I think you're probably
mistaken about how thread constructor arguments are handled.
 
They're not passed directly to the thread function, which would indeed
prevent an rvalue from being bound to a formal reference argument.
 
They're stored, and then the stored copies are forwarded.
 
[snip]
 
 
Cheers!, & please correct if I gut-feeled my way wrong here,
 
- Alf
Manfred <noname@invalid.add>: Mar 03 09:54PM +0100

On 3/3/2017 8:51 PM, Alf P. Steinbach wrote:
> mistaken about how thread constructor arguments are handled.
 
> They're not passed directly to the thread function, which would indeed
> prevent an rvalue from being bound to a formal reference argument.
For brevity, I may have considered std::thread to be a transparent call
to the task function - which is how it is designed by the way, but this
does not change the validity of the conclusion above - see below.
 
 
> They're stored, and then the stored copies are forwarded.
If you read n4296@30.3.1.2 (thread constructors) clause 5, the arguments
are forwarded via DECAY_COPY(std::forward(args)), which still produces a
rvalue (technically a temporary explicitly meant to "closely model
by-value argument passing") (20.10.7.6 - template struct decay)
 
(The actual implementation involves bind() template function calls as
well, which makes the error messages quite unreadable, but this is
outside of the standard wording)
Paavo Helde <myfirstname@osa.pri.ee>: Mar 03 11:13PM +0200

On 3.03.2017 21:43, Manfred wrote:
> Nevertheless it easy to see that copying objects of class type via
> memcpy is in general a standard violation - you can't copy objects
> without invoking copy constructors, right?
 
The standard defines "trivially copyable class" types which can be
copied by memcpy(). Basically these are classes whose compiler-generated
copy constructors and assignments are equivalent to memcpy(). So MFC is
entitled to use memcpy() for such classes.
 
Moreover, since MFC is tightly coupled to a single C++ implementation it
can use things which are undefined behavior by the standard, but which
are defined by the implementation. Most prominent examples are checks
for this==NULL.
 
Anyway, I still lack to see your point. If you had said that the
standard-conformance related bugs in VC++ are there in order to keep the
MFC library compiling, this would at least have been an on-topic claim,
though not necessarily one which I would agree with. VC++ has gradually
become much more standard-conformant over the years and I am sure they
have broken things in MFC during that process.
Manfred <invalid@invalid.add>: Mar 03 11:32PM +0100

On 03/03/2017 10:13 PM, Paavo Helde wrote:
>>>> issue 1 (MFC):
>>>> Look at the current implementation of MFC CArray::SetSize
 
>>> Since when is MFC part of the C++ standard?
<snip>
 
 
> The standard defines "trivially copyable class" types which can be
> copied by memcpy(). Basically these are classes whose compiler-generated
> copy constructors and assignments are equivalent to memcpy().
Absolutely true.
 
> So MFC is entitled to use memcpy() for such classes.
The fact is that CArray is provided for the benefit of the user (same as
std::vector), the elements of CArray are user-defined classes, so this
is not an internal-only issue of MFC.
(as I wrote upstream, they have subsequently added a kind of disclaimer
in the documentation that only some types of classes are compatible with
CArray)
The more relevant argument would be to forget about CArray and friends
entirely (obvious advice is use std), but since they are still shipping
them, the inexperienced user may inadvertently use them and get into
trouble.
 
> can use things which are undefined behavior by the standard, but which
> are defined by the implementation. Most prominent examples are checks
> for this==NULL.
This is indeed an internal-only issue of MFC (which I don't mind of)
 
> standard-conformance related bugs in VC++ are there in order to keep the
> MFC library compiling, this would at least have been an on-topic claim,
> though not necessarily one which I would agree with.
As said my point is not about this, it is about how the library handles
user-defined objects.
 
> VC++ has gradually
> become much more standard-conformant over the years
I absolutely agree.
My point is that, for what is worth, in my experience I have got many
more standard compliance issues with MSVC than with gcc (with which I
substantially encountered none). Again, I agree that MSVC has improved a
lot, but, as far as I see it, still it is not the best.
This is specifically for standard compliance. The IDE in general, the
debugger and user friendliness are quite good to me.
OTOH, being the OP a newbie, I think that correctness of the language
implementation is a priority.
Ian Collins <ian-news@hotmail.com>: Mar 04 12:08PM +1300

On 03/ 4/17 11:32 AM, Manfred wrote:
> debugger and user friendliness are quite good to me.
> OTOH, being the OP a newbie, I think that correctness of the language
> implementation is a priority.
 
As a novice, the OP is very unlikely to encounter standard compliance
issues with MSVC++, or gcc.
 
Most compliance issues are obscure or "advanced" issues. The current
large code base I'm working in builds with clang++, g++ and MSVC++ and
we don't have any compliance work-arounds for any of the compilers.
 
--
Ian
woodbrian77@gmail.com: Mar 03 10:24AM -0800

On Wednesday, March 1, 2017 at 9:46:13 PM UTC-6, Jorgen Grahn wrote:
 
> I don't know your project, but if you don't /have/ to see it as
> separate parts, I recommend having just /one/ Makefile (one invocation
> of make, no $(MAKE)) covering all of the code.
 
I cloned your project on a TrueOS/FreeBSD system and tried
running make:
 
make: "/usr/home/brian/tcp/Makefile" line 73: Need an operator
make: "/usr/home/brian/tcp/Makefile" line 83: warning: duplicate script for target "%.o" ignored
make: "/usr/home/brian/tcp/Makefile" line 80: warning: using previous script for "%.o" defined here
make: "/usr/home/brian/tcp/Makefile" line 84: warning: duplicate script for target "%.o" ignored
make: "/usr/home/brian/tcp/Makefile" line 80: warning: using previous script for "%.o" defined here
make: Fatal errors encountered -- cannot continue
make: stopped in /usr/home/brian/tcp
 
------------------------------------------------------------
 
I want something that works on FreeBSD, Linux, Windows, etc.
I'm thinking about trying SCons. http://scons.org/
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 03 05:05AM +0100

On 3/2/2017 7:05 PM, Mr Flibble wrote:
 
> int main() // 10 characters (including whitespace)
> auto main() -> int // 18 characters (including whitespace)
 
> Less characters can be grokked quicker by the brain.
 
No doubt that is true in some situations.
 
And I agree that the most frequently used things should be shortest, as
a rule.
 
But `main` is not so much used that a few characters is a problem: in a
million function program there's only 1 `main`.
 
 
> Secondly we can consider rationale:
 
> The trailing return type syntax was invented to solve a problem related
> to templates
 
This is probably true. Wikipedia uses the example of letting the return
type be the promoted type of arguments. Andrei Alexendrescu wrote ¹an
article investigating how to do that properly for C++03, and it was
messy indeed – but then, C++03 didn't have `decltype`.
 
 
> and very few people think ALL functions should use it;
 
This is probably also true, just as very few people in the world, less
than 10%, think there is no supernatural deity or deities.
 
As religion to a large degree proves, the majority can't be counted on
to have an opinion that coincides with rational thinking for any given
question, until they've been convinced by non-rational arguments. In
particular, I believe, until they've been convinced that the rational
position is what people in their social group think. Then they're likely
to adopt the rational position, but not because it's rational.
 
At that point their opinion should /also/ be ignored. ;-)
 
 
> certainly not main() which is IDIOMATICALLY DEFINED.
 
Now this is rubbish, I'm sorry to tell you.
 
I think you mean that using the old syntax for declaring `main` is an
idiom, on account having been used exclusively for 40 years or so.
 
But an idiom in programming is a common way to do something, chosen from
/other possible ways/, and due to its frequent use probably a good
enough choice for most any situation. For example, the erase + remove
idiom in C++, as opposed to other ways of doing that, or the copy + swap
idiom for copy assignment operator implementation in C++, as opposed to
other ways of doing that. What other ways were there for the `main`
function syntax?
 
 
> You deliberately try to frustrate and irritate
 
And this telepathic insight into my motivations for whatever I do, is
also rubbish.
 
Don't trust your feelings, Leigh.
 
 
> by obtusely writing legal but obfuscated C++
 
And this is just not true as fact: it's probably your impression, and so
it's probably a true, heartfelt statement from you, but it's not true as
fact.
 
 
>; why do you do this?
 
Disregarding the inferred nefarious motivations for using trailing
return type, there remains the question of why you evidently perceive
code with trailing return type syntax to be "legal but obfuscated C++".
 
I think you, who have this perception, is the only one who can answer that.
 
 
Cheers!,
 
- Alf
 
Links:
¹ <url: http://www.drdobbs.com/generic-min-and-max-redivivus/184403774>
"Öö Tiib" <ootiib@hot.ee>: Mar 03 09:37AM -0800

On Friday, 3 March 2017 06:05:23 UTC+2, Alf P. Steinbach wrote:
> position is what people in their social group think. Then they're likely
> to adopt the rational position, but not because it's rational.
 
> At that point their opinion should /also/ be ignored. ;-)
 
What a long way of saying that argumentum ad populum is a red herring
logical fallacy. :D It indeed would be fallacy if we could consider
coding style as something that can be logically proven to be better
or worse than other coding style.
 
However IMHO it can't. Source code is way of communication. Goodness
of its style is in most part in how appealing (or repulsive) it is for
other engineers who have to read it.
scott@slp53.sl.home (Scott Lurndal): Mar 03 04:05PM

> they are potentially concurrent.
 
>#include <csignal>
 
>volatile std::sig_atomic_t gSignalStatus;
 
sig_atomic_t is volatile, so the additional volatile
keyword is redundant.
 
 
> - they are performed by different threads, or
 
> - they are unsequenced, and at least one is
> performed by a signal handler. (p19.2) «
 
The two assignments you
highlight will not be considered potentially concurrent
(unless, perhaps, they're autovectorized into a simd load and sum
instruction).
joseluis@solidsands.nl: Mar 03 06:06AM -0800

This is an example from the C++14 Standard (ISO/IEC 14882:2014), Section 5.1.2, Paragraph 12. which I modified in 2 ways:
 
- First, both functions f have "int" as the first argument, so variable x is NOT odr-used in any case.
- Second, I removed (commented) the capture-default in the lambda g2.
 
Is this code Standard-compliant? Both clang and gcc compile successfully. However, in the original example lambda g2 had a capture default, so variable x was implicitly captured because there was a dependent expression (and it could be also odr-used). Note that in the aforementioned paragraph of the Standard there are 2 conditions to implicitly capture variable x (odr-use OR dependent expression). Now, without capture-default nor odr-use:
 
- Shouldn't this be a compile-time error (assume g2 calls with both kinds of arguments) since there is a dependent expression and no capture-default? (so variable x needs to be captured but it cannot be)
- Or does the condition of the dependent expression to implicitly capture a variable only apply when there is a capture-default? That would mean that, with no odr-use (i.e., without const int&) the program will work in the same way regardless of the capture-default. Therefore, wouldn't the second condition of the dependent expression be useless?
 
void f( int, const int (&)[2] = {}) { } // #1
 
void f( int, const int (&)[1]) { } // #2
 
// void f(const int&, const int (&)[1]) { } // #2_original
 
void test() {
 
const int x = 17;
 
auto g = [](auto a) {
 
f(x); // OK: calls #1, does not capture x
 
};
 
auto g2 = [ /* = */ ](auto a) {
 
int selector[ sizeof(a) == 1 ? 1 : 2 ]{};
 
f(x, selector); // OK: is a dependent expression, so captures x ???
 
};
 
}
SG <s.gesemann@gmail.com>: Mar 02 11:46PM -0800

Juha Nieminen wrote:
> you disable them either explicitly (with =delete) or implicitly
> (by implementing one but not the other, or implementing a copy or
> assignment operator, or a destructor.)
 
This *is* a "rule-of-zero" implementation of a copy-on-write wrapper.
What you are looking at are conversion constructors, not copy/move
constructors. Otherwise they would take a cow<T> instead of a T as
parameter. :-)
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 03 08:55AM +0100

On 3/3/2017 8:46 AM, SG wrote:
>> SG wrote:
>>> cow(T const& x) : ptr(std::make_shared<T>(x)) {}
>>> cow(T && x) : ptr(std::make_shared<T>(std::forward<T>(x))) {}
 
Just a note: `T` is not a deduced type here, it's specified in the class
template instantiation. So `T&&` is not a forwarding reference (a.k.a.
universal reference), it's just a good old rvalue reference. Hence the
`std::forward` reduces to a `std::move`, I believe, and anyway I'd write
`std::move` there in order to not mislead myself and others – I find
the magic of `std::forward` a bit impenetrable.
 
 
Cheers!,
 
- Alf
ram@zedat.fu-berlin.de (Stefan Ram): Mar 03 12:20AM

The operations »signal = 2« and »signal = 3« below are both
performed by a signal handler. So according to 1.10.1p19.2,
they are potentially concurrent.
 
#include <csignal>
 
volatile std::sig_atomic_t gSignalStatus;
 
void signal_handler( int signal )
{ gSignalStatus =( signal = 2 )+( signal = 3 ); }
 
int main() { ::std::signal( SIGINT, signal_handler); }

»Two actions are potentially concurrent if
 
- they are performed by different threads, or
 
- they are unsequenced, and at least one is
performed by a signal handler. (p19.2) «
 
1.10.1p19
 
So, now, the evaluation of »( signal = 2 )+( signal = 3 )«
does /not/ have undefined behavior?
 
»If a side effect on a memory location is unsequenced
relative to either another side effect on the same
memory location or a value computation using the value
of any object in the same memory location, and they are
not potentially concurrent, the behavior is undefined.«
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
1.9p15
 
Is this a defect? I think the intention of 1.10.1p19.2 must
be that at least on of the actions is performed by a signal
handler, but not both by the same signal handler?
 
(And then, the standard also did not define »action« at all.)
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)