Saturday, December 27, 2014

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

EQuestionAnswers Inc <equestionanswers@gmail.com>: Dec 27 10:42PM -0800

Hi,
 
This is our website http://www.equestionanswers.com loaded with C,C++, VC++,MFC,COM,DCOM, DLL question and answers, targeted for interviews and self-study. Hope you like this forum.

Thanks and regards,
webmaster
Christian Gollwitzer <auriocus@gmx.de>: Dec 20 09:38AM +0100

Am 02.11.14 08:05, schrieb jacob navia:
 
> using yes = no;
> using no = yes;
 
> and Romeo and Juliette talking in a warm summer night...
 
Actually, this is often erroneously declared in class Woman.
 
;)
 
Christian
Ian Collins <ian-news@hotmail.com>: Dec 22 10:09AM +1300

Mr Flibble wrote:
 
> You are still talking shite mate. My catch-all rethrows. If I wanted to
> support thread cancellation I would throw a cancellation object; pthread
> stack cancellation is UB as far as C++ is concerned so is off-topic.
 
How would you "throw a cancellation object"? That appears to be the
opposite of thread cancellation where the operation is initiated from
another thread.
 
--
Ian Collins
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 21 11:44PM

On Sun, 21 Dec 2014 23:21:06 +0000
Mr Flibble <flibble@i42.co.uk> wrote:
[snip]
> The first sensible thing you've said but alas mostly irrelevent to me
> as I am able to write non-blocking code; shame you can't.
 
Ad hominem: you've lost. Of course I can write non-blocking code. In
one of the languages I use (not C#, python or javascript, which are
quite well advanced on this) I have written assymetrical coroutines
which provide await-type semantics on asynchronous code via an event
loop. That might come with C++17 (probably later) but to break out of
nests of asynchronous callbacks in C++ sometimes you just need blocking
code.
 
And thread cancellation without it is pointless, in my opinion.
 
Chris
Ian Collins <ian-news@hotmail.com>: Dec 22 02:03PM +1300

Mr Flibble wrote:
 
>> So your designs avoid any system calls that can block? I wish I had
>> that luxury...
 
> Such as?
 
I guess that depends on the platform, but on mine (POSIX) most I/O and
process management calls (including the ubiquitous system()) are both
blocking and cancellation points.
 
--
Ian Collins
Richard Damon <Richard@Damon-Family.org>: Dec 21 08:43PM -0500

On 12/21/14 3:07 PM, Chris Vine wrote:
> object. The second provides compile time binding in the class
> definition but with run time virtual method selection. I very much
> prefer the first.
 
I find that it very much depends on the application. I find that I often
have a set of classes representing things in the system, some of which
may have several instances, and these classes have a natural "thread of
execution" to handle them. In this case, having a base class for a
thread-class using a virtual "run" function can make sense.
 
As you say, sometimes you also have operations that aren't naturally
tied to a class that you want to schedule to run.
 
What I find tends to work is to have the actual thread system use a
provided function pointer with a void* parameter, and a void* value, and
the base thread-class use a function that takes pointer to the object
(converted to a void* pointer) and calls the "run" method of the class.
This lets you use which ever method is right for you application.
 
You could also do the reverse, and start from a class interface and make
a generic class that takes a function pointer (and any data to pass to
the function) and the run method just calls that function.
 
In both case "function pointer" could be generalized function like
object like std::function.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 21 08:07PM

On Sun, 21 Dec 2014 18:04:35 +0000
> It is not over design at all mate; basically you are clueless.
 
So you have a program which happens to have, say, 100 functions which
might be executed in their own threads at some point during execution
of the program. You want to have the class representing a thread to
have a separate start method, so you cannot use std::thread just by
itself. One approach is to have a single concrete thread class, where
each function/callable object in question is passed at object
construction time and stored in a std::function or similar object, which
is a data member of the class, and which is executed when start is
called.
 
Another approach is to have a virtual run method of a virtual base
thread class and force the programmer to write 100 derived classes,
each with their own version of the run method representing the function
in question to be executed by it (that is what your virtual 'task'
method did).
 
The first approach provides run time binding to a polymorphic function
object. The second provides compile time binding in the class
definition but with run time virtual method selection. I very much
prefer the first.
 
> As it happens, mate, there is nothing wrong with my code.
 
To adopt your favourite response, you're talking shite, mate. With
the BSDs and linux (and possibly commercial unixes), forced stack
unwinding on cancellation would cause the program to terminate when it
hits your catch-all clause. As I said, that is not a problem in
windows (your platform) because it does not have meaningful/usable
cancellation.
 
Chris
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 21 10:25PM

On Mon, 22 Dec 2014 10:09:08 +1300
 
> How would you "throw a cancellation object"? That appears to be the
> opposite of thread cancellation where the operation is initiated from
> another thread.
 
You cannot do it portably across platforms (and Flibble may well just be
confused), but you can sort-of do what he suggests on POSIX platforms.
The system calls which represent cancellation points are by and large
the same as those that are interruptible by a signal. So you can set a
flag, unblock system calls in the target thread by sending a signal with
pthread_kill(), and get the target thread to inspect its flags on EINTR
and commit suicide by throwing its own exception object which is caught
in the entry-point callable.
 
I don't think this can be done on Flibble's platform though. And if
you cannot interrupt blocking system calls then it is pointless.
 
Chris
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 21 11:07PM

On Sun, 21 Dec 2014 22:53:10 +0000
> cancelled by another thread quite easily as all that happens is a
> flag is set and the thread cancels itself by throwing a cancellation
> object.
 
That's hopeless. One of the reasons you often want to start a thread
is so that you can make blocking calls, so you can program serially
rather than with asynchronous callbacks. In POSIX, it is the blocking
calls which represent cancellation points (other than
pthread_testcancel()).
 
Incidentally, that is the reason why thread cancellation will probably
never become part of the C++ standard, and why boost interruptible
threads never got any further. To be effective they depend on the
behaviour of blocking system calls, which is platform dependent.
 
Chris
"Chris M. Thomasson" <no@spam.invalid>: Dec 21 11:03AM -0800

> threads, and it seems very braindead. I mean third party libraries have
> been giving us working threading for years, and "THAT"was all they came
> up with for the standard?
 
[...]
 
AFAICT, it is not brain-dead. The only little quibble I have is that C++11
gives us a way to wait on lock-based algorithms via condvar, however
there is no stock method to wait on conditions generated by lock/wait-free
algorithms. Luckily, one can build something that works by using what's
there.
 
This can all be done portably now. FWIW, take a look at the following topic:
 
https://groups.google.com/forum/?hl=en#!topic/lock-free/X3fuuXknQF0
 
and:
 
https://groups.google.com/d/topic/lock-free/acjQ3-89abE/discussion
 
 
All of the algorithms there can be portably implemented in C++11.
 
that is VERY nice!
 
:^D
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 20 10:17PM

On Sat, 20 Dec 2014 13:42:16 +0000
> > what std::thread does.
 
> That is like saying "It is horrible 1990's over-OO design to use
> virtual functions." which is of course nonsense.
 
It is of course nonsense. Which is why that is not what I said.
 
> You seem to be ignoring my other reply: my virtual "task()" function
> is actually in my thread class which *contains* a boost::thread
> object.
[snip]
> What we are basically talking about here is the /template method
> pattern/ and there is nothing wrong with it; it certainly is *not*
> "horrible 1990's over-OO design"
 
A virtual function is over-design in this usage. If you want to store a
callable object you can keep a std::function object as member data
rather than force derivation just to achieve the same end. (And we are
talking about C++11 here, as the OP's criticisms of std::thread formed
the subject of the originating post.)
 
Chris
 
PS: As it happens, your particular implementation would not work with
the BSDs or linux (and possibly some of the commercial unixes) if thread
cancellation is in use, but that is a side issue. I think you program
for windows, which does not have meaningful (that is,
deferred/blockable) cancellation.
Ian Collins <ian-news@hotmail.com>: Dec 22 01:54PM +1300

Mr Flibble wrote:
>> else?
 
> In my designs a thread will not be blocked for any significant length of
> time.
 
So your designs avoid any system calls that can block? I wish I had
that luxury...
 
--
Ian Collins
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 21 10:30PM

On Sun, 21 Dec 2014 22:28:26 +0000
> In my designs threads cancel themselves by throwing a custom thread
> cancellation object. Again pthread cancel is off-topic in this ng.
 
You can't do that effectively on windows, your platform, I believe.
 
> remain shite. There is *nothing* wrong with the template method
> pattern and there is nothing wrong having a class that represents a
> thread of execution that performs a specific task.
 
You're talking shite mate. When you wrote your code mobile telephones
probably weighed 5 pounds. You need to get with the beat.
 
Chris
Ian Collins <ian-news@hotmail.com>: Dec 22 09:42AM +1300

Chris Vine wrote:
> pass start a callable object, or you can pass it a runnable object
> which has implemented a virtual run method. I don't see the point of
> that.
 
Maybe it's because people are comfortable with that design?
 
--
Ian Collins
Melzzzzz <mel@zzzzz.com>: Dec 22 03:00AM +0100

On Sun, 21 Dec 2014 20:07:10 +0000
> the BSDs and linux (and possibly commercial unixes), forced stack
> unwinding on cancellation would cause the program to terminate when it
> hits your catch-all clause.
 
Nope. As I see he re throws, it is fine. Program would be terminated
without re throw.
 
As I said, that is not a problem in
> windows (your platform) because it does not have meaningful/usable
> cancellation.
 
For thread cancellation to work one must assure that program is in
sensible state by disabling/enabling cancellation at appropriate points
anyway,
 
"Qu0ll" <Qu0llSixFour@gmail.com>: Dec 24 11:40PM +1100

"Lynn McGuire" wrote in message news:m7d28c$hsq$1@dont-email.me...
 
> 1. "To understand C++, you must first learn C"
 
Definitely not required. You will *never* understand C++ no matter how many
other languages you study first!
 
> 2. "C++ is an Object-Oriented Language"
 
Well, there's some refreshing candidness. (i.e the fact that it is NOT an OO
language).
 
> 3. "For reliable software, you need Garbage Collection"
 
You only need garbage collection if you have garbage.
 
> 4. "For efficiency, you must write low-level code"
 
Define "low-level code" please? Assembler? Poor quality code? I am glad
they're not required for efficiency because I never write either of those.
 
> 5. "C++ is for large, complicated, programs only"
 
Nah, C++ is for large, uncomplicated programs as well as small complicated,
small uncomplicated, and all variations of of medium sizes and levels of
complication and will fail just as spectacularly in all those scenarios!
 
Merry Christmas!
 
--
And loving it,
 
-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llSixFour@gmail.com
[Replace the "SixFour" with numbers to email me]
"Jouko Koski" <joukokoskispam101@netti.fi>: Dec 20 02:03PM +0200

"red floyd" wrote:
 
> snprintf(buffer, sizeof(buffer), "%d", val);
> return buffer;
> }
 
Well, MSVC might not be 100 % conforming to the standard...
 
--
Jouko
ram@zedat.fu-berlin.de (Stefan Ram): Dec 21 01:08PM

>>parentheses and »int(x)« with a scalar value »x«. Is this
>>correct?
>Two possible usages of what?
 
Two possible usages of »int(«:
It can be followed either by »)« or by an expression.
 
(And there are no other possibilities, for example, one
can never have two arguments as in »int( 2, "a" )«.)
JiiPee <no@notvalid.com>: Dec 27 11:45PM

On 27/12/2014 23:34, Öö Tiib wrote:
> std::cout << "xx is:" << x.xx << std::endl;
> return 0;
> }
 
wow. That's it! Thanks. Now I need to google why its like this :). good
to learn ....
never heard about "base"...but I ll google.
JiiPee <no@notvalid.com>: Dec 27 11:47PM

On 27/12/2014 23:45, JiiPee wrote:
 
> wow. That's it! Thanks. Now I need to google why its like this :).
> good to learn ....
> never heard about "base"...but I ll google.
 
sorry, its not about "base", its the trick typedef.... obviously it can
be like base2
JiiPee <no@notvalid.com>: Dec 27 11:56PM

On 27/12/2014 23:34, Öö Tiib wrote:
> public: typedef pair2<T, T> base; T& xx = base::first; }; int main() {
> pair2_derived<int> x; x.first = 42; x.second = 43; std::cout << "xx
> is:" << x.xx << std::endl; return 0; }
 
I need this because I am trying to use std::pair as a base for 2dvector
and 2dsize. Just testing how it would go... so I have to put
first/second to be refered by x/y and height/width.
"Öö Tiib" <ootiib@hot.ee>: Dec 27 04:58PM -0800

On Sunday, December 28, 2014 1:57:13 AM UTC+2, JiiPee wrote:
 
> I need this because I am trying to use std::pair as a base for 2dvector
> and 2dsize. Just testing how it would go... so I have to put
> first/second to be refered by x/y and height/width.
 
So the goal is renaming/aliases? Other question is why you need pair there?
It does not have much of functionality. Just relational operators and
'swap'.
 
The references are bad for renaming/aliasing because these take some memory.
Your derived objects will be bigger. It is better to use short accessory
functions for such aliases. Sort of like:
 
struct Vertex
{
float first() const { return values[0]; }
float second() const { return values[1]; }
float third() const { return values[2]; }
 
float x() const { return values[0]; }
float y() const { return values[1]; }
float z() const { return values[2]; }
 
float operator [] (int i) const { return values[i]; }
float& operator [] (int i) { return values[i]; }
 
float[3] values;
};
 
The short member function calls will be usually optimized out by
compiler.
JiiPee <no@notvalid.com>: Dec 28 01:05AM

On 28/12/2014 00:58, Öö Tiib wrote:
> };
 
> The short member function calls will be usually optimized out by
> compiler.
 
so like get/set functions. I have been thinking about them, but I do not
like x() because its so long. only writing "x" is shorter. I would like
to do: obj.x rather than obj.x() . but ye there is that tradeoff. So to
fix your point I would need to not use pair but rather have x/y inside
the class, T x; .
 
most graphical libraries do x, so I would prefer that here... it is used
so much in the code also so it needs to be as short as possible I think.
JiiPee <no@notvalid.com>: Dec 28 01:11AM

On 28/12/2014 00:58, Öö Tiib wrote:
 
> The references are bad for renaming/aliasing because these take some memory.
> Your derived objects will be bigger. It is better to use short accessory
> functions for such aliases. Sort of like:
 
oh. was thinking/hoping the compiler would optimize that away... why
would the compiler not be able to do that?
Nobody <nobody@nowhere.invalid>: Dec 28 01:03AM

On Sat, 27 Dec 2014 15:19:12 -0600, Paavo Helde wrote:
 
> public derivation leaks out the inner guts of std::vector, which will
> overcomplicate your class' interface and make it hard to maintain its
> class invariants).
 
Another issue is that STL classes typically don't have virtual
destructors.
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)