Monday, April 15, 2019

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

Bonita Montero <Bonita.Montero@gmail.com>: Apr 08 10:58AM +0200

I'd like to have a templated class with an iterator-class as a template
-parameter. And internally the class should have a vector having the
element-type the iterator "points" to.
I could write vector<decltype(*it)> when it is a iterator-instance.
But I'd like to have something like vector<decltype(*IteratorType)>.
Theoretically the compiler could deduce the type of *IteratorType
by analyzing the operator * of IteratorType. Even there's the issue
that this type would be a refernce this could work by writing
vector<decltype(remove_reference<*IteratorType>::type). But the
standard doesn't allow all this.
So is there a clever way arround this mess?
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 08 11:33AM +0200

On 08.04.2019 10:58, Bonita Montero wrote:
> vector<decltype(remove_reference<*IteratorType>::type). But the
> standard doesn't allow all this.
> So is there a clever way arround this mess?
 
Not so clever: `decltype` + `std::declval` + `std::remove_reference_t`.
 
Clever: `std::iterator_traits`.
 
Cheers!,
 
- Alf
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 08 10:27AM +0200

On 07.04.2019 16:48, Daniel wrote:
> work in all these environments.
 
> I don't suppose you would have any suggested alternatives that would work
> with Visual C++ 140 (2015) or 141 (vs 2017)?
 
Wait, with VS 2017, did you remember to specify the version of the standard?
 
Like, `/std:c++17`?
 
This is a useful set of options for that compiler:
 
/nologo /std:c++17 /Zc:__cplusplus /utf-8 /EHsc /GR /W4 /FI"iso646.h" /D
_CRT_SECURE_NO_WARNINGS /D _STL_SECURE_NO_WARNINGS
 
 
Cheers & hth.,
 
- ALf
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 08 10:13AM +0200

On 07.04.2019 16:48, Daniel wrote:
> work in all these environments.
 
> I don't suppose you would have any suggested alternatives that would work
> with Visual C++ 140 (2015) or 141 (vs 2017)?
 
I sort of wish now that I had not hastily uninstalled VS 2017.
 
I think I still have VS 2012...
 
But, try rewriting with specialization instead of SFINAE, maybe?
 
 
Cheers!,
 
- Alf
Geoff <geoff@invalid.invalid>: Apr 10 03:34PM -0700

On Wed, 10 Apr 2019 23:25:39 +0200, "Alf P. Steinbach"
<alf.p.steinbach+usenet@gmail.com> wrote:
 
...
> if( not is_empty( m_execution_locks_q ) )
WTF????---------------^^^
> {
> Lock moved_lock = move( *popped( m_execution_locks_q ) );
> moved_lock.unlock(); // Another thread runs. Destructor would do it anyway.
 
Sam's analysis is correct. It's throwing at the unlock.
Paavo Helde <myfirstname@osa.pri.ee>: Apr 10 11:44PM +0300

On 10.04.2019 23:09, Alf P. Steinbach wrote:
> * Why is it crashing with Visual C++?
> * Is there a much simpler / efficient / whatever way to do this
> (except using C++20 coroutines)?
 
If you could translate that to C++ and explain what it is what this is
supposed to do I might be tempted to have a look.
 
As for now my only advice is to not turn too much attention to the
process exit code, its informational value is extremely low. A Windows
exception code from a SEH handler or "Stopped working" box would be
better, in my experience.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 10 11:25PM +0200

On 10.04.2019 23:08, Alf P. Steinbach wrote:
 
> - Alf (no change of behavior: works with g++, crashes with MSVC)
 
Sorry, all that editing let the editor do an unnoticed auto-completion,
changing "m" to "m_q_access" in one place.
 
I removed all the chaff and logging and discovered that edit-o.
 
Reduced code:
 
 
#include <iostream>
#include <stdexcept>
#include <thread>
#include <mutex>
#include <queue>
#include <sstream>
#include <string>
 
namespace my
{
template< class Collection >
auto is_empty( const Collection& c )
-> bool
{ return c.empty(); }
 
using std::string;
using std::ostringstream;
using namespace std::string_literals;
 
template< class Type >
inline auto operator<<( string& s, const Type& value )
-> string&
{
ostringstream stream;
stream << value;
s += stream.str();
return s;
}
 
template< class Type >
inline auto operator<<( string&& s, Type const& value )
-> string&&
{ return move( operator<<( s, value ) ); }
 
using std::clog;
using std::endl;
using std::exception;
using std::move;
using std::mutex;
using std::queue;
using std::string;
using std::unique_lock;
 
namespace this_thread = std::this_thread;
 
using Lock = unique_lock<mutex>;
 
mutex output_mutex;
 
class Mutually_exclusive_execution
{
 
mutex m_q_access;
queue<Lock*> m_execution_locks_q;
 
static auto popped( queue<Lock*>& q )
-> Lock*
{
Lock* result = q.front();
q.pop();
return result;
}
 
void yield( const bool do_wait )
{
mutex m;
Lock execution_lock( m );
 
 
{
auto&& _ = Lock( m_q_access );
 
if( not is_empty( m_execution_locks_q ) )
{
Lock moved_lock = move( *popped(
m_execution_locks_q ) );
moved_lock.unlock(); // Another thread runs.
Destructor would do it anyway.
}
if( do_wait )
{
try
{
m_execution_locks_q.emplace( &execution_lock );
}
catch( const exception& x )
{
}
}
}
 
if( do_wait )
{
//(Lock( m )); // Waits until m is unlocked by
another thread.
auto&& _ = Lock( m );
}
}
 
public:
void yield() { yield( true ); }
void goodbye() { yield( false ); }
};
 
} // namespace my
 
namespace app
{
using std::cout;
using std::endl;
using std::thread;
 
namespace this_thread = std::this_thread;
 
void run()
{
my::Mutually_exclusive_execution mee;
const auto f = [&]()
{
for( int i = 0; i < 10; ++i )
{
mee.yield();
{
auto&& _ = my::Lock( my::output_mutex );
cout << "Thread " << this_thread::get_id() << "
iteration " << i << "." << endl;
}
}
mee.goodbye();
};
 
thread t1( f );
thread t2( f );
 
t1.join(); t2.join();
}
} // namespace app
 
#include <stdexcept> // std::exception
#include <stdlib.h> // EXIT_...
using std::exception;
using std::cerr;
using std::cout;
using std::endl;
auto main() -> int
{
try
{
cout << "Starting." << endl;
app::run();
cout << "Finished." << endl;
return EXIT_SUCCESS;
}
catch( const exception& x )
{
cerr << "!" << x.what() << endl;
}
return EXIT_FAILURE;
}
 
 
Cheers!,
 
- Alf
Juha Nieminen <nospam@thanks.invalid>: Apr 11 10:02AM

> $use_cppx( is_empty );
 
You understand that this is a C++ newsgroup, right?
 
> auto main() -> int
> {
...
> return EXIT_FAILURE;
> }
 
All things considered, I think that's actually quite fitting.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 08 01:33AM +0100

> an academic topic because they would require knowing the sizes of at
> least some dimensions at compile time. This happens pretty rarely in
> RL, maybe in some specific applications.
 
Since this is comp.lang.c++, you are right, but multi-dimensional C
arrays in C need not have dimensions known at compile-time. Even when
variable length arrays are not used, C99's variably modified array types
can be used to simplify multi-dimensional array handling.
 
<cut>
--
Ben.
Paavo Helde <myfirstname@osa.pri.ee>: Apr 08 07:34AM +0300

On 8.04.2019 3:33, Ben Bacarisse wrote:
> arrays in C need not have dimensions known at compile-time. Even when
> variable length arrays are not used, C99's variably modified array types
> can be used to simplify multi-dimensional array handling.
 
And in C++ it is pretty easy e.g. to wrap a 1D array/vector into a class
providing element access via a T& operator()(size_t x, size_t y), if the
goal is to simplify multi-dimensional array handling.
 
This approach would share the same drawback with multi-dimensional C
arrays in that the index calculation formally happens at each element
access and care must be taken to write algorithms in such a way that the
compiler would be able to optimize it away. In our code we have decided
to leave the index calculation explicit in the algorithms to see the
memory access pattern better, and to be able to bring parts of the index
calculation out of the loop where possible, for helping the optimizer.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 08 03:57PM +0200

> the problem you're having with the argument. It's about influence,
> specifically the influence that gcc might have had on the committee's
> decisions about the wording.
 
Well, let's formulate it that way, about not the wording itself but
about the influence on the committees decisions that led to the wording.
 
Which is what I meant.
 
That means that it's a fallacy, in context.
 
We're not children.
 
We are able to reason about context and what an argument is meant to
support.
 
If it doesn't support anything then it's just nonsense, so one can
choose: nonsense, or fallacy.
 
 
Cheers!,
 
- Alf
James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 08 08:27AM -0400

On 4/6/19 9:44 AM, Alf P. Steinbach wrote:
> standard, and when optimization (essentially through assuming
> non-aliased pointer results of expressions) was mentioned as a rationale
> for the UB interpretation, ...
 
I mentioned the optimization for the sole purpose of pointing out that
the fact that such code has undefined behavior is not just a pedantic
quibble - there are plausible mechanisms by which such code could
produce unexpected results.
 
I have repeatedly tried, and apparently failed, to make it clear to you
that I never said anything to suggest that such optimizations were the
motivation for this rule. I'm not even sure whether any real-world
compiler actually performs such optimizations.
 
As far as I know, the rule was motivated solely by the belief that
accessing an array outside it's declared length is an inherently
illogical thing to do, which the C standard should discourage in the
only way that it can - by specifying that the behavior of such code is
undefined.
 
You apparently disagree with that belief, which might explain why you
resist so strongly the idea that it was in fact the motivation for this
rule. But that belief does exist, and a majority of the C committee
apparently shares that belief - not only did they approve the wording
that says so, they also approved the DR that clarified that this is in
fact what that wording means.
 
> mindset of compiler developers who want to make their task somewhat
> easier, with less analysis necessary to do optimization, at the cost of
> carving out UB traps all over the place for language users to fall into.
 
The mindset behind this rule, as we keep trying to explain to you, had
nothing to do with the optimization, and everything to do with believing
that such code is inherently illogical. The rule merely enables such
optimizations; enabling them was not the purpose of creating the rule.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 08 08:08PM +0200


> At the time you posted that message, I had already posted my message
> identifying the C committee's resolution of DR#017 confirming the truth
> of that "nonsense"
 
Maybe you had, I don't give a fuck. I hadn't read it.
 
Cheers!,
 
- Alf
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 08 05:14PM +0200

>> about the influence on the committees decisions that led to the wording.
 
> Does that sentence accurately reflect what you were claiming? You
> weren't clear about which decision you were accusing gcc of influencing,
 
I never claimed they influenced a decision.
 
That may be why it's unclear in your mind.
 
 
> but I'd been assuming that you were talking about the committee's
> decision on the DR, not their decision on the writing of the wording
> itself.
 
This looks like an example of false memory.
 
 
 
> 1. Your comments that this is an issue about the interpretation of the
> words, implying that you were under the misapprehension that the other
> interpretation was also consistent with the words.
 
The other interpretation is the only sensible one, e.g. not incompatible
with the standard library's algorithm functions, not adding UB traps.
 
But we got what we got.
 
Apparently to marginally ease the life of compiler writers, at cost.
 
 
> 2. Your comments, nonsensical in context, about whether the gcc
> developers could have been able to read the words of the first standard,
> which was never actually relevant to what he was talking about.
 
I guess I lost your train of thought here.
 
But considering, as noted above, that you apparently started with a
falsehood: anything can be proved from a falsehood.
 
 
> 3. It's marginally more plausible that gcc might have significantly
> influenced the later decision, because they would have had 3 more years
> to accumulate enough influence to do so.
 
No-one would have to influence any decision in order to promote an
interpretation of the wording that resulted from the decision.
 
Assuming that's necessary is, well, nonsensical.
 
A time travel view.
 
 
>> Which is what I meant.
 
> You meant to claim that gcc influenced the committee's decision.
 
WTF?
 
 
> If his
> premise had been correct, presenting his argument would have proved you
> were incorrect on that point.
 
You make me laugh.
 
Thanks. :)
 
 
> Because his premise was inaccurate, the
> corrected version of his argument still served to point out that your
> claim was implausible.
 
Lols.
 
[snip]
 
Cheers!,
 
- Alf
Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 09 03:56AM -0700

>>>>>>>> On 01/04/2019 13:31, Paavo Helde wrote:
>>>>>>>>> On 1.04.2019 14:22, Tiib wrote:
>>>>>>>>>> On Monday, 1 April 2019 11:42:06 UTC+3, Paavo Helde wrote:
 
[..considering .erase() on a vector..]
 
>> std::vector::erase_and_move_assign() then you could argue that
>> identity is no longer lost as that is the intention.
 
> Grudgingly, I have to admit this actually makes sense. Thanks!
 
Looking at the passages in the C++ standard that refer to "object
identity", ISTM that the phrase is basically isomorphic to where
the object is, i.e., its address. I'm not looking to convince
anyone but I thought some people might be interested to hear
another take on the question.
"Chris M. Thomasson " <ahh_f_it@crap.nothing>: Apr 10 01:43PM -0700

On 3/31/2019 2:02 PM, Chris M. Thomasson wrote:
 
> https://groups.google.com/d/topic/comp.lang.c++/DBIG55vCBSA/discussion
 
> Here is my crude C++ code:
 
> https://pastebin.com/raw/1QtPCGhV
 
Have you found the time to give this a go? :^)
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 09 05:05PM +0200

On 09.04.2019 11:23, Tim Rentsch wrote:
> ss( unsigned n, unsigned r ){
> return n ? ss( n-1, r + n*n ) : r;
> }
 
A bit off-topic, but about such code if it /really/ had appeared
anywhere: actually summing the squares is one needless complication and
one introduction of needless inefficiency, and doing that summing via
recursion, even tail recursion, is another such needless complication
and needless possible inefficiency.
 
Instead just `return (n*(n + 1)*(2*n + 1))/6`.
 
That said, I never fully groked the pattern of the formulas of the sums
of k'th powers, so have to google for k>1... :(
 
 
> function call is defined, with no qualifying statement about
> memory being available. Do you agree with all that? If not
> which part(s) do you not agree with?
 
I agree. It's UB with most (all?) implementations because it exceeds
implementation limit on stack space.
 
Now I don't recall exactly what the discussion was about, or what
positions were held by whom, but there are some points I think are relevant.
 
First,
 
C++17 §4.1/2.1:
<<If a program contains no violations of the rules in this International
Standard, a conforming implementation shall, within its resource limits,
accept and correctly execute that program.>>
 
where the word "execute" has attached a (non-normative) note,
 
<<"Correct execution" can include undefined behavior, depending on the
data being processed; see Clause 3 and 4.6.>>
 
This is where the UB in your example would come from: when the code
exceeds the resource limits, the implementation isn't obliged to execute
it correctly. Since the standard places no requirements on what happens
then, for incorrect execution, that's formally UB.
 
Secondly, the standard is imperfect. It has the surface appearance of a
formal document, but it relies on common sense and practicality in a
number of places. For example, if one just defines /not/ blinking the
NumLock light for a millisecond as a "diagnostic", then a compiler can
do that non-blink and then accept any language extensions whatsoever.
 
 
> (My comments here are meant to apply to both C and C++, with the
> same conclusions in the two cases. If you think there are any
> differences between the two please say what those are and why.)
 
Well, at this late point it could help if you would state what the
conclusion you arrived at, is.
 
I'm sorry, I'm getting old, and today had my third kidney stone trying
to take me on. I gave it a bunch of painkillers to chew on, but that had
only marginal effect. Happily it gave up after just half an hour or so,
but possibly deviously, with the intent and actual effect that when I
arrived at the doctor's I was all fine.
 
 
Cheers!,
 
- Alf
Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 09 03:27AM -0700

Tiib <ootiib@hot.ee> writes:
 
My apologies for the long delay in responding. I am snipping
nearly everything in an effort to refocus the discussion.
 
> Can you specifically show how my answers to your questions
> did not address what was asked?
 
Let me try to clarify by starting afresh and simplifying. First
I would like to ask questions about C. The second part will
consider the same questions about C++.
 
 
First question: please consider this program (and remember we
are starting considering the C language):
 
int
main(){
return (((0)));
}
 
Is the semantics for this program (A) well-defined, (B) undefined,
or (C) other? Please answer with "A", "B", or "C".
 
 
Second question: please consider this program, compiled in an
environment where size_t is 64 bits and the program is accepted
with no complaints from the compiler or linker:
 
int
main(){
char a[1000000000];
return 0;
}
 
Does the C standard impose requirements for what status is
returned? Please answer "yes" or "no".
 
 
Third question: please consider this program:
 
#include <stdio.h>
 
unsigned ss( unsigned, unsigned );
 
int
main(){
printf( " result is %u\n", ss( -1, 0 ) );
return 0;
}
 
unsigned
ss( unsigned n, unsigned r ){
return n ? ss( n-1, r + n*n ) : r;
}
 
(a) Does any construct in this program violate a 'shall'
requirement? If so then which construct and which 'shall'?
 
(b) Does any construct in this program encounter any explicit
statement of undefined behavior? If so then which construct
and which explicit undefined behavior?
 
(c) Does every construct in this program have a passage or
passages in the C Standard defining its behavior? If not
then which constructs do not?
 
(d) For those constructs that have passages defining the
behavior, are any definitions only partially defined?
If so then which constructs and which passages define
those constructs?
 
For all of the above subquestions, please answer "yes" or "no"
to the first part, and for any second parts give references
that are specific, explicit, direct, and unambiguous.
 
 
For C++: same questions as above, but consider for
programs in C++ rather than in C. Are there any
differences in the answers between C and C++? If so
then which questions?
 
 
 
>>> I indeed do not understand how what I wrote can be perceived
>>> as some sort of gibberish.
 
I didn't say your writing was gibberish. What I did say is it
didn't answer my questions. Am I right in thinking that English
is not a first language for you? If so, my compliments, I am
terrible with trying to speak other languages. In your writing
though I do sometimes have trouble understanding, largely I
think due to the style of construction, which I find somewhat
long, convoluted, and indirect. It would help if you would
go in the direction of short, simple, and direct. Try limiting
your sentences to ten words or less. Does that make sense?
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 10 04:40PM

> }
 
> Hope all is well here on the board.... I haven't posted in 10 years or so.
 
> Frederick
Const and non const call is resolved by first hidden argument, that is, 'this'.
So if you call Enumerate with non cost object non const version is
called otherwise const...
 
--
press any key to continue or any other to quit...
Bonita Montero <Bonita.Montero@gmail.com>: Apr 09 02:56PM +0200


> std::cout << "test\n";
> }
 
> Yeah, it's really ugly and cringey, but it works...
 
The problem is here that you won't have a capture.
Paavo Helde <myfirstname@osa.pri.ee>: Apr 09 04:18PM +0300

On 9.04.2019 15:56, Bonita Montero wrote:
>> }
 
>> Yeah, it's really ugly and cringey, but it works...
 
> The problem is here that you won't have a capture.
 
Capture is easy to add:
 
#include <iostream>
#include <functional>
#include <memory>
 
int main() {
int x = 1;
std::unique_ptr<void, std::function<void(void*)>> finally
((void*)1, [&x](void*) {
std::cout << "finally x is " << x << "\n"; });
 
std::cout << "test\n";
x = 2;
}
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 09 03:43PM -0400

Is there a Usenet group explicitly devoted to literal C or C++ compiler
development? Specifically in the areas of optimization techniques?
 
TYIA.
 
--
Rick C. Hodgin
Philipp Klaus Krause <pkk@spth.de>: Apr 09 10:54PM +0200

Am 09.04.19 um 21:43 schrieb Rick C. Hodgin:
> Is there a Usenet group explicitly devoted to literal C or C++ compiler
> development?  Specifically in the areas of optimization techniques?
 
> TYIA.
 
Not specific to C/C++ or optimization:
 
comp.compilers
Bart <bc@freeuk.com>: Apr 10 10:21AM +0100

On 10/04/2019 09:59, Juha Nieminen wrote:
> much activity on usenet groups. This might be one of the very few groups
> that have at least a modicum of activity.
 
> Most communities have moved to web-based forums and Discord.
 
Which ones, things like stackoverflow? Those are extremely unfriendly
and officious. Plus they don't tolerate any sort of discussion. You must
ask a precise question, one that hasn't been asked before, and get only
precise, on-topic answers. And every single thing gets voted on.
 
Sod that.
 
Anyway, for general discussion on language design, but also compilers,
there is comp.lang.misc. Although usually dead, it sometimes briefly
comes into life, as it has at the minute. It just needs someone to post
there.
 
It's also unmoderated, unlike comp.compilers, where discussions are
likely to be terminated if the moderator doesn't like them. But it also
is only updated every few days at the whim of the moderator.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 10 12:11PM +0200

On 10.04.2019 11:21, Bart wrote:
> ask a precise question, one that hasn't been asked before, and get only
> precise, on-topic answers. And every single thing gets voted on.
 
> Sod that.
 
 
Lols. AOL. :)
 
[snip]
 
Cheers!,
 
- Alf
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)