Friday, December 23, 2016

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

scott@slp53.sl.home (Scott Lurndal): Dec 23 10:39PM

>>> mutex lock.
 
>> Not necessarily - atomics are a viable alternative.
 
>Yes, atomics are fine in many situations, but not here, in the OP
 
You stated, as above, "Any access to data which is concurrently
modified needs a mutex lock". To which I replied as shown. I
made no claim about the OP's code.
"Chris M. Thomasson" <invalid@invalid.invalid>: Dec 23 03:19PM -0800

On 12/21/2016 8:49 PM, ruben safir wrote:
>> mention).
 
> That is a VERY cool observation!!!
 
> Thank You
 
Agreed. False sharing is the root of all evil wrt
multi-thread/processing. What good is a slick use of atomics if the
data-structures are not properly padded up to, and allocated in memory
on properly aligned cache lines?
 
False sharing will totally ruin any chance of a possible speed up wrt
atomic's.
Paavo Helde <myfirstname@osa.pri.ee>: Dec 24 01:31AM +0200

On 24.12.2016 0:39, Scott Lurndal wrote:
 
> You stated, as above, "Any access to data which is concurrently
> modified needs a mutex lock". To which I replied as shown. I
> made no claim about the OP's code.
 
Right, I should have worded my claims more carefully!
 
Merry Christmas!
p
Gareth Owen <gwowen@gmail.com>: Dec 23 08:57PM


> Hi,
 
> Merry festivus. I hope everyone has an enjoyable winterval. Sausages.
 
First - the airing of grievances.
 
I gotta lot of problems with you people.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 23 01:04PM -0800

Merry Christmas, Leigh.
 
Best regards,
Rick C. Hodgin
Daniel <danielaparker@gmail.com>: Dec 23 01:06PM -0800

On Friday, December 23, 2016 at 12:07:33 PM UTC-5, Mr Flibble wrote:
> Hi,
 
> Merry festivus. I hope everyone has an enjoyable winterval. Sausages.
 
And a merry festivus to you too, f**king ho, ho, ho.
 
Daniel
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 23 10:03PM

On 23/12/2016 20:57, Gareth Owen wrote:
 
>> Merry festivus. I hope everyone has an enjoyable winterval. Sausages.
 
> First - the airing of grievances.
 
> I gotta lot of problems with you people.
 
You people? Your god doesn't exist mate; try a different religion which
doesn't rely on evolution being false.
 
/Flibble
Gareth Owen <gwowen@gmail.com>: Dec 23 10:26PM


>> I gotta lot of problems with you people.
 
> You people? Your god doesn't exist mate; try a different religion
> which doesn't rely on evolution being false.
 
If you're going to make a cultural allusion, you should probably be
passingly familiar with the source of that cultural allusion.
 
**** https://www.youtube.com/watch?v=0JR6xt9S02o ****
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 23 10:31PM

On 23/12/2016 22:26, Gareth Owen wrote:
>> which doesn't rely on evolution being false.
 
> If you're going to make a cultural allusion, you should probably be
> passingly familiar with the source of that cultural allusion.
 
Cultural allusion? Neither atheism nor evolution are cultural in nature
so I am not sure what you think I was alluding to culturally. Perhaps
you think I was alluding to your culture? I was certainly making an
assumption that you are a follower of an Abrahamic religion (a good bet
usually for someone with such an Anglo-Saxon name).
 
 
> **** https://www.youtube.com/watch?v=0JR6xt9S02o ****
 
Didn't open link.
 
/Flibble
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 23 10:44PM

On 23/12/2016 22:31, Mr Flibble wrote:
> usually for someone with such an Anglo-Saxon name).
 
>> **** https://www.youtube.com/watch?v=0JR6xt9S02o ****
 
> Didn't open link.
 
Ah, Seinfeld. A show that looks good but I have never had the
opportunity to watch. Maybe when I retire I will watch the box set on
repeat to stave off dementia.
 
/Flibble
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 24 12:17AM +0100

On 23.12.2016 23:44, Mr Flibble wrote:
 
> Ah, Seinfeld. A show that looks good but I have never had the
> opportunity to watch. Maybe when I retire I will watch the box set on
> repeat to stave off dementia.
 
Do.
 
Some of the references may be obscure at that time, but Seinfeld was good.
 
Tip: you can avoid the annoying threats about illegal copying, and get
decent subtitles (at least with e.g. the VLC player), by downloading a
technically illegal copy. I.e., buy the set, then download it. I think
it's a shame that the entertainment companies are unable to offer their
products in a properly usable way, that one must use of one's time and
bandwidth to obtain a decent version after buying e.g. a movie, but.
 
Cheers!, & Happy Xmas!,
 
- Alf
woodbrian77@gmail.com: Dec 23 10:55AM -0800

On Monday, December 19, 2016 at 1:58:50 AM UTC-6, David Brown wrote:
> > In my naivety I have always thought all the maths is abstractions,
> > basically about the same kind ...
 
> "God made the integers, all else is the work of man"
 
I agree with the German astronomer Kepler when he
described his mathematical work as "thinking G-d's
thoughts after Him."
 
http://inventors.about.com/od/famousinventors/fl/Johannes-Kepler-Astronomy.htm
 
Johannes Kepler was born on December 27, 1571, in Weil der Stadt, Württemburg,
------------------------------------------------------------
 
Kepler sounds like he was a mensch -- a decent and humble man.
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
Tim Rentsch <txr@alumni.caltech.edu>: Dec 23 12:03PM -0800

>> each partition.
 
> ^^ this. My initial guess that worst case performance is more likely
> is starting to get legs I think.
 
That doesn't matter because the change being discussed is still
within a constant factor and so doesn't affect the order. In
fact any change that differs only by a constant factor doesn't
affect the order - not the average behavior, not the worst case
behavior, not how often worst case behavior occurs relative to
average behavior. All of the changes we have been talking about
affect only constant factors, and hence have no impact on
asymptotic complexity, worst-case or otherwise.
Daniel <danielaparker@gmail.com>: Dec 23 12:08PM -0800

On Monday, December 19, 2016 at 2:58:50 AM UTC-5, David Brown wrote:
 
> "God made the integers, all else is the work of man"
 
Depends where you want to start. You can start with set theory, and derive the
integers as equivalence classes. Mr Fliblle, as you note, starts with sausages.
 
God, of course, is the ultimate undefined concept. Assume there is a god with some
properties, and see what follows.
 
Best regards,
Daniel
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 23 08:25PM

On 23/12/2016 20:03, Tim Rentsch wrote:
> average behavior. All of the changes we have been talking about
> affect only constant factors, and hence have no impact on
> asymptotic complexity, worst-case or otherwise.
 
So how to get the middle element without traversing linked list O(n)
times for each partition? You are basically contradicting yourself.
 
/Flibble
Gareth Owen <gwowen@gmail.com>: Dec 23 08:56PM


> So how to get the middle element without traversing linked list O(n)
> times for each partition?
 
If each interation used to take k*n steps (fixed k) now takes (k+1)*n steps,
**** YOU HAVEN'T CHANGED THE ORDER ****
 
If each interation used to take k*n steps and now takes 1000*k*n steps,
you've slowed the algorithm down egregiously but....
**** YOU STILL HAVEN'T CHANGED THE ORDER ****
 
Maths not a strong suit, is it?
 
> You are basically contradicting yourself.
 
You are wrong. Go read a book.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 23 10:02PM

On 23/12/2016 20:56, Gareth Owen wrote:
>> times for each partition?
 
> If each interation used to take k*n steps (fixed k) now takes (k+1)*n steps,
> **** YOU HAVEN'T CHANGED THE ORDER ****
 
Except overall you are actually taking lg n * n extra steps so it is not
dependent on a constant but on n.
 
/Flibble
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 23 10:14PM

On 23/12/2016 22:02, Mr Flibble wrote:
>> **** YOU HAVEN'T CHANGED THE ORDER ****
 
> Except overall you are actually taking lg n * n extra steps so it is not
> dependent on a constant but on n.
 
But as 2 * O(n * lg n) = O(n * lg n) then yeah, I seemed to have guessed
wrong but like I said elsewhere I have not actually looked at the
quicksort algorithm for linked lists as I would never use quicksort on
linked lists because it is slower than mergesort even if it is the same
algorithmic complexity.
 
/Flibble
Tim Rentsch <txr@alumni.caltech.edu>: Dec 23 12:29PM -0800

> message, unpacks that into 0 to about 4 argument values depending on
> the message, and calls a specified handler function with those
> unpacked arguments.
 
Yes, I read up on those and looked up the definitions in
windowsx.h.
 
> it is of course documented, but the only API level support for
> packing, the only /code/ for that that can be leveraged, is as far as
> I know provided by the macros from <windowsx.h>.
 
If you want to use the supplied support for message cracking, and
that support exists only the form of macros, then I think you're
pretty much stuck with macros. You can make your own macro
definitions prettier, and maybe do something so that you get
better flow for function/method calls, but unless you're willing
to re-implement (some of) the HANDLE_xxx macro functionality, it
seems like using macros is basically inevitable.
 
 
> principle, Don't Repeat Yourself, but also because conceivably the
> class name could in some instance be a template expression with commas
> in it.
 
Yes, I thought something like that might be true. However a
similar comment still applies, as for example (disclaimer: not
compiled):
 
switch( m.message_id ){
#define TAKE( E, M ) WINAPI_DISPATCH( m, E, Main_window, M )
TAKE( WM_COMMAND, on_wm_command );
TAKE( WM_PAINT, on_wm_paint );
TAKE( WM_SIZE, on_wm_size );
#undef TAKE
}
 
This way at least you won't have hidden dependencies in your
macro definitions.
 
> always enclose that argument in parentheses, and unpack it in the
> macro, but that adds some dirtyness again. Another workaround is to
> define a macro symbol as comma, but that's really dirty.)
 
Roger that. I believe the above technique still applies, with a
parenthesized comma needed in only one macro call.
 
 
>> But what is it you are looking for?
 
> I don't know.
 
> Some really out-of-the-box idea, I guess. [...]
 
My sense is there is something to be done here, depending on what
it is you hope to achieve.
 
One idea (which I haven't worked out in any detail) is to re-do
the functionality of whatever HANDLE_xxx macros you need (and I
don't mean as macros necessarily), in such a way that you can
check your implementation against the macros in <windowsx.h>.
That would let you get away from using the HANDLE_xxx macros,
but not have to worry about some sort of version skew/drift.
 
One question I have is, what does the message flow look like,
and/or what would you like it to look like? The idea of bundling
up pointer-to-member-functions (assuming I'm understanding that
right), and passing 'this' as a parameter, is one I find somewhat
repugnant. But I'm hampered by not understanding what message
flow is being used, and what message flow is ultimately desired.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 23 11:06PM +0100

On 23.12.2016 21:29, Tim Rentsch wrote:
> }
 
> This way at least you won't have hidden dependencies in your
> macro definitions.
 
I tried roughly that approach at first. But it turned out to be
difficult to avoid macro expansion of a name like WM_PAINT. Each message
name expands to some hex number, e.g. 0x000F for WM_PAINT, which would
generate a macro invocation like HANDLE_0x000F instead of HANDLE_WM_PAINT.
 
As a language extension Visual C++ supports writing ##WM_PAINT as actual
macro argument, which prevents expansion. However g++ will have none of
that.
 
 
> check your implementation against the macros in <windowsx.h>.
> That would let you get away from using the HANDLE_xxx macros,
> but not have to worry about some sort of version skew/drift.
 
I think I can maybe add a layer on top, like an extensible collection of
message-specific dispatcher, starting with ones that can be expressed in
terms of Microsoft's HANDLE_... macros.
 
 
> right), and passing 'this' as a parameter, is one I find somewhat
> repugnant. But I'm hampered by not understanding what message
> flow is being used, and what message flow is ultimately desired.
 
Oh, the flow.
 
The Windows API's support for windowing – GUI stuff – was a sort of
early 1980's rewrite in C of the GUI ideas from the Xerox PARC Smalltalk
project, I think (but I'd have to google it to be sure of this claim) at
least in large part via Apple's participation in Xerox' technology
transfer program. So it's like a dynamic language OO design, except
everything is down at the nitty gritty C level, and with Microsoft
"let's do the entirely unexpected and unpredictable" twists.
 
Each window object has a single C function that does its message
processing; the first argument is a handle value that identifies the
window object. This function is called its "window procedure" (I think
this may be a terminology transfer from use of Pascal over at Apple). A
call of a window's window procedure with a given message, corresponds to
a call of virtual function on a C++ class type object – or a message in
Smalltalk (I think definitely the "message" terminology here transferred
from the use of Smalltalk at Xerox PARC and at first over at Apple, with
Apple's Smalltalk-based Lisa machine, before the Mac).
 
The window procedure can be invoked directly by Windows, and by the
application code for messages that it retrieves from a message queue.
 
The general problem that the API design doesn't directly support in a
practical way, is to associate a window object with /state/. The design
only supports uninterpreted raw bytes as state, then accessed in an
inefficient way as bytes via OS calls. A C++ class type object is much
more practical as state, then with processing of each message in a
member function, so every C++ /GUI framework/ replaces the window
procedure of each window, with one that forwards each call (message
processing) to a corresponding general window-procedure like member
function on a C++ object, where ideally the message is unpacked, and a
corresponding message-specific member function is called with the args.
 
Cheers!,
 
- Alf
 
PS: I have wrapped this thing earlier and in many different ways, but
it's all been based on re-implementing the message unpacking. I'd rather
use Microsoft's macros, their own code, which in essence /defines/ the
proper unpacking. Except it's so ugly. :)
woodbrian77@gmail.com: Dec 23 12:13PM -0800

I've posted this class here previously and am thinking about
it again.
 
#pragma once
 
#include <exception>
#include <string>
#include <experimental/string_view>
#include <utility> // move
 
namespace cmw {
class failure : public ::std::exception {
::std::string whatStr;
 
public:
explicit failure (char const* w):whatStr(w) {}
explicit failure (::std::string& w):whatStr(::std::move(w)) {}
 
explicit failure (char const* w, int tot) {
if(tot>0)whatStr.reserve(tot);
whatStr=w;
}
 
char const* what () const throw() { return whatStr.c_str(); }
 
failure& operator<< (::std::string const& s)
{
whatStr.append(s);
return *this;
}
 
failure& operator<< (char* s)
{
whatStr.append(s);
return *this;
}
 
failure& operator<< (char const* s);
failure& operator<< (int i);
 
template <class T>
failure& operator<< (T val)
{
using ::std::to_string;
return *this<<to_string(val);
}
};
}
 
I've noticed how the constructors and numerous operator<<
implementations are just wrapping std::string functionality.
One idea to try to get rid of the operator<<'s is to add a
variadic constructor to the class. I think I could use
is_arithmetic or is_numeric or something like that to
figure out if I need to convert an argument to a string.
 
And I run into some trouble with std::string_view
 
failure& operator<< (::std::experimental::string_view const& s)
{
whatStr.append(s.data(),s.size());
return *this;
}
 
I can't just call append() and give a string_view. So is
there a way to figure out if an argument is a string_view?
I'm using clang++ 3.8.1. I've been told in newer compilers it
will be possible to pass a string_view to std::string;;append.
But not sure what to do at this time when I don't have support
for that. Anyway, does this sound like a good change to make
to this class? Thanks in advance.
 
 
Brian
Ebenezer Enterprises - "Oh, come, all ye faithful,
Joyful and triumphant! Oh, come ye, oh, come ye to Bethlehem."
 
http://webEbenezer.net
Daniel <danielaparker@gmail.com>: Dec 23 01:00PM -0800


> ::std::exception
 
The leading :: is annoying
 
> char const* what () const throw() { return whatStr.c_str(); }
 
Here you're overriding a virtual function, so you should write it as
 
const char* what() const noexcept override { return whatStr.c_str(); }
 
> explicit failure (::std::string& w):whatStr(::std::move(w)) {}
 
That will still give you a copy construction. Perhaps you meant
 
explicit failure (std::string&& w):whatStr(std::forward<std::string&&>(w)) {}
 
> if(tot>0)whatStr.reserve(tot);
> whatStr=w;
> }
 
That is going to be less efficient than simply
 
explicit failure (char const* w, int tot)
: whatStr(w,tot)
{
}
> using ::std::to_string;
> return *this<<to_string(val);
> }
 
I don't think appending to whatStr like this is a good idea. For one thing, it
doesn't accommodate internationalization. Use string formats, look them up
based on error codes, and substitute placement values.
 
> whatStr.append(s.data(),s.size());
> return *this;
> }
 
I believe the experimental std:string_view has an explicit conversion operator
to std::string, so you should be able to use static_cast.
 
Daniel
Tim Rentsch <txr@alumni.caltech.edu>: Dec 23 11:53AM -0800


> Dan Sacks asked (in the context of C and C++), >>What's a data
> type?<<. [...]
 
The word type is used to refer to two related but distinct
ideas in computer programming. Historically these ideas
were not distinguished (in Fortran, for example), so a lot
of people still confuse the two meanings. It's important
to understand the difference because, one, what makes sense
for one meaning sometimes doesn't for the other, and two,
the essence of OOP lies in realizing the distinction and
maximizing the gulf between the two different kinds of
"type". Let me try to illustrate.
 
The earliest understanding of "type" has to do with layout,
structure, or representation. If we have a variable of type
'int', the bits that make up the value will be positioned in
a particular way, so that what is stored in memory can be
interpreted as an abstract numeric value. I will refer to
this meaning of "type" as /structure/.
 
The other meaning of "type" has to do with what is expected,
or allowed, for a programmatic entity (eg, a variable or an
expression), when the program is being compiled. In the early
days of computing the only kind of thing that was expected is
what structure the variable or expression would have at runtime,
which explains why people used to think of the two ideas as the
same thing.
 
Let's look at a couple of examples. Consider these two variable
declarations:
 
static int i = 4;
static const int ci = 4;
 
The structure of these two variables is exactly the same: if we
looked at the bits, we would find the same pattern of zeros and
ones in both variables.
 
But what is expected (or allowed) for the two variables is /not/
the same. The variable 'i' is changeable, eg, with an assignment
statement. The variable 'ci' may not be changed via assignment.
Furthermore, even though it may be possible to change 'ci' by means
of some language or extra-linguistic trickery (eg, assembly), the
compiler may assume its value will /not/ change. In this case the
"type" of a variable is more specific than its structure.
 
For another example, consider this printf() call:
 
printf( "%.8x", 127 );
 
A %x conversion specifier expects an argument of type unsigned
int, but we have given for the actual argument a value of type
int. The printf() call still works, because 'int' and 'unsigned
int' are guaranteed to have the same representation for values in
the non-negative range of int. In some sense the "type" expected
is less specific than the structure information of the actual
argument value.
 
In C++ a good example illustrating the distinction between the
two aspects is a parameter of type Base*, where in a particular
call the argument value supplied is of type Derived*. The
structure of the object pointed to at runtime may not be the same
as what the compile-time pointer type nominally implies.
 
A note on terminology: the two kinds of "type" are sometimes
referred to as "dynamic type" or "run-time type", for the
layout/structure/representation aspect, and "compile-time type"
or often just plain "type", for the what-is-expected-or-allowed
aspect. I prefer the terms "structure" and "type", respectively,
for these two distinct aspects, but the important thing is to
understand the distinction (assuming of course that what terms
one uses for the two different aspects is made clear).
 
The essential idea in OOP is to decouple these two aspects as
much as possible. In Smalltalk, every value is an object
pointer, and that's it. What can we do with an object pointer?
Pass it as a value, store it in a variable, or send it a message
(and importantly, any message). All of those are true no matter
what class the object being pointed to belongs. In other words
the type -- ie, what is expected or allowed in terms of language
usage -- is completely decoupled from the class, or structure,
of what the object is at runtime. Obviously some of those things
will be nonsensical (eg, will result in "Message not understood"
popups), but the principle involved is at the heart of OOP and
OOD. (Historical note: in its early usage "object-oriented
programming" was understood to include what is now called design
or "object-oriented design", OOD/A, etc.)
 
A more complete explanation of the difference between "type"
and "structure" may be found in this paper:
 
A Type Declaration and Inference System for Smalltalk
http://dl.acm.org/citation.cfm?id=582168
 
Does my explanation help illuminate what "type" means in its
several aspects?
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)