Friday, December 19, 2014

Digest for comp.lang.c++@googlegroups.com - 20 updates in 4 topics

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 18 11:35PM

On 18/12/2014 22:48, me wrote:
> also causes me grief (particularly in managing lists of threads or thread
> pools). I understand the "why" but that doesn't mean I have to like it
> or a gree with it.
 
I gave you a solution in my other reply mate; stop fucking moaning and
talking shite.
 
/Flibble
"Öö Tiib" <ootiib@hot.ee>: Dec 18 04:43PM -0800

On Friday, 19 December 2014 00:11:12 UTC+2, me wrote:
 
> Well, here's you're answer. I've religiously stayed away from anything
> boost. The times I've had to use it I encountered poor documentation and
> too frequently changing interface semantics.
 
Sometimes I've been impressed and sometimes disappointed by some external
code used but I've never felt anything religious about anything.
 
Perhaps one of most impressive things from boost is Boost.ASIO, it is hard
to find decent alternative to it and it uses Boost.Thread quite intuitively
and tidily for my taste. It can work stable for months.
 
> Other third party platforms
> accomplished more with less effort. commoncpp and trolltech-qt had much
> better features.
 
Qt has also impressed me with some features (but it does not have anything
like Boost.ASIO). However it has lately started to behave odd with that
QML of it. If I leave it running (and communicating) for a night then
it now crashes somewhere within some of its "qgraphicsitems"s,
"qanimation"s and "qeventloops". Also its latest QtCreator crashes too
frequently ... feels that Qt has changed its owners too often and so is
currently going down.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 19 01:16AM

On Thu, 18 Dec 2014 13:35:09 -0600
> spawn a new thread or what?), and all STL containers are based on
> value copying. Use some pointers or smartpointers instead for holding
> the thread objects in a container.
 
That's not right. std::thread has a move constructor and move
assignment operator, suitable for C++11 containers. The problem is
that the OP doesn't understand move semantics - he noticed that the
copy constructor and copy assignment operator are deleted, but failed
to consider moving into the container.
 
Nor does he seem to have any programming experience or he would not
need to ask why thread objects should not be copiable (it is
semantically meaningless for threads).
 
> functor copying and keep data in shared use one can define a simple
> template (probably boost has it already defined by some other name)
> which can be used for all such threads:
 
The idea of inheriting from a thread object and giving a thread object
a virtual run method to assist that is totally bizarre. What
polymorphic behaviour could a run method reasonably offer? A thread
object is a classical concrete type.
 
Presumably the original poster only has some (fairly limited) java
experience to draw on.
 
Chris
me <noone@all.net>: Dec 19 01:25AM

On Thu, 18 Dec 2014 16:43:49 -0800, Öö Tiib wrote:
 
 
> "qgraphicsitems"s, "qanimation"s and "qeventloops". Also its latest
> QtCreator crashes too frequently ... feels that Qt has changed its
> owners too often and so is currently going down.
 
Admittedly, I'm beginning to share those Qt concerns, but for rapid
application prototyping it's still a good framework to get something up
and running: usually a python back-end with a Qt front end...and if the
project has professional or commercial value then a translation from
python to C++.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 19 01:53PM

On 19/12/2014 01:16, Chris Vine wrote:
> a virtual run method to assist that is totally bizarre. What
> polymorphic behaviour could a run method reasonably offer? A thread
> object is a classical concrete type.
 
I think it makes perfect sense to derive from std::thread so there is
nothing intrinsically wrong with having a virtual "thread started" method.
 
/Flibble
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 19 02:03PM

On 19/12/2014 13:53, Mr Flibble wrote:
>> object is a classical concrete type.
 
> I think it makes perfect sense to derive from std::thread so there is
> nothing intrinsically wrong with having a virtual "thread started" method.
 
Actually I am talking bollocks - I forgot what my code-base actually
does: I have a thread class that *contains* a boost::thread object and
you can derive from this thread class instead.
 
/Flibble
Martijn Lievaart <m@rtij.nl.invlalid>: Dec 19 03:04PM +0100

On Fri, 19 Dec 2014 13:53:26 +0000, Mr Flibble wrote:
 
 
> I think it makes perfect sense to derive from std::thread so there is
> nothing intrinsically wrong with having a virtual "thread started"
> method.
 
A thread object needs a start function, so making thread a virtual base
makes perfect sense to me. To call that a "thread started" function
instead of run() or operator()() seems a stretch though.
 
M4
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 19 10:14PM

On Fri, 19 Dec 2014 13:53:26 +0000
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote:
[snip]
> I think it makes perfect sense to derive from std::thread so there is
> nothing intrinsically wrong with having a virtual "thread started"
> method.
 
So, what polymorphic behaviour do you think this "run" method described
by the OP might exhibit? A run method should just start the thread.
It is horrible 1990's over-OO design to use polymorphism just to
represent the function to be executed. All you need do is apply the
thread function/lambda/callable object passed to the thread object to
its arguments (if any), which is what std::thread does.
 
Chris
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 19 10:33PM

On Fri, 19 Dec 2014 15:04:21 +0100
> A thread object needs a start function, so making thread a virtual
> base makes perfect sense to me. To call that a "thread started"
> function instead of run() or operator()() seems a stretch though.
 
So let me ask you then what polymorphic behaviour this run() method
might exhibit? std::thread just takes a callable object with arguments
and applies the callable object to its arguments (if any) in a new
thread. To use polymorphism just to encapsulate the callable object is
OO-obsessive mis-design, in my view (and also, apparently, the standard
library developers).
 
A thread object does not need a start function, although there is some
advantage in having one (I have a thread class with a start function).
But all it need do is start the new thread.
 
Chris
Lynn McGuire <lmc@winsim.com>: Dec 18 05:40PM -0600

On 12/16/2014 11:29 AM, Paavo Helde wrote:
> *only* for formatting error messages ;-)
 
> Cheers
> Paavo
 
Error messages are usually a critical piece of our code that are not
tested very well. So, for error messages I have built a typesafe class
around sprintf and just use standard strings for building the error
message. Not the prettiest code (and is verbose also) but gets the
message across.
 
Lynn
jacob navia <jacob@spamsink.net>: Dec 19 01:01AM +0100

Le 19/12/2014 00:31, Christopher Pisz a écrit :
> suffixes to read one line of code. Having to memorize tables of codes to
> get anything done is the C way. I leave my decoder rings in the box of
> cereal.
 
Good. And then... how do you specify a right justified floating point
number with 3 digits precision?
 
Ahhh you have to look in your C++ reference manual to set the width, to
set the precision, etc etc!
 
> For those that already memorized the damn thing in 1970 and even its
> least used parts, good for you.
 
For those that already memorized the damm thing in 1990 and even its
least used parts, good for you.
 
I have the same respect for you as I do
> the guy who had to do calculus without a calculator, but I will bring my
> calculator when I need to do a calculus problem.
 
Calculus with a calculator?????
 
Good luck with that. Solving an integral with a calculator!
 
:-)
Christopher Pisz <nospam@notanaddress.com>: Dec 18 06:28PM -0600

On 12/18/2014 6:01 PM, jacob navia wrote:
> number with 3 digits precision?
 
> Ahhh you have to look in your C++ reference manual to set the width, to
> set the precision, etc etc!
 
3 things versus 80+ hmmm. I can memorize 3 things.
 
>> least used parts, good for you.
 
> For those that already memorized the damm thing in 1990 and even its
> least used parts, good for you.
 
Learning something in the 90s how the guys in the 70s did it is the same
effect. i am not surprised though, it is 2014 and you are still missing
what happened in 1992.
 
 
> Calculus with a calculator?????
 
> Good luck with that. Solving an integral with a calculator!
 
> :-)
 
https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=solving%20an%20integral%20with%20a%20calculator
Robert Wessel <robertwessel2@yahoo.com>: Dec 18 06:30PM -0600

On Fri, 19 Dec 2014 01:01:22 +0100, jacob navia <jacob@spamsink.net>
wrote:
 
>Calculus with a calculator?????
 
>Good luck with that. Solving an integral with a calculator!
 
 
Advanced calculators have supported symbolic integration for years.
Here's a demo of using a TI-89:
 
https://www.youtube.com/watch?v=l3Wrq_sVkCU
 
And numeric integration goes back a really long way. My late 80s
vintage HP-28S can do numerical integration.
scott@slp53.sl.home (Scott Lurndal): Dec 19 02:31PM

>around sprintf and just use standard strings for building the error
>message. Not the prettiest code (and is verbose also) but gets the
>message across.
 
Surely you're using snprintf, not sprintf? sprintf should never
be used.
Lynn McGuire <lmc@winsim.com>: Dec 19 01:35PM -0600

On 12/19/2014 8:31 AM, Scott Lurndal wrote:
>> message across.
 
> Surely you're using snprintf, not sprintf? sprintf should never
> be used.
 
Sounds like a good idea. But, no.
 
std::string asString (int val)
{
char buffer [100];
#ifdef _MSC_VER
sprintf_s (buffer, sizeof (buffer), "%d", val);
#else
sprintf (buffer, "%d", val);
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)