Saturday, December 20, 2014

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

me <noone@all.net>: Dec 20 11:31AM

On Thu, 18 Dec 2014 21:05:42 +0000, Mr Flibble wrote:
 
 
> Stop fucking moaning mate.
 
> void start() { stdThread=new thread(std::bind(&UsefulThread::run,
> this)); }
 
Well, partial kudos anyway...std::bind() was helpful, but if run was a
virtual then it barfed. It works when run is a simple class method. The
workaround of having run() call a virtual works.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 20 01:42PM

On 19/12/2014 22:14, Chris Vine wrote:
> 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.
 
That is like saying "It is horrible 1990's over-OO design to use virtual
functions." which is of course nonsense.
 
You seem to be ignoring my other reply: my virtual "task()" function is
actually in my thread class which *contains* a boost::thread object.
 
My start() method:
 
void thread::start()
{
lock();
if (started())
{
unlock();
throw thread_already_started();
}
try
{
iState = Starting;
if (!iUsingExistingThread)
{
thread_object_pointer newThread(new
boost::thread(boost::bind(&thread::entry_point, this)));
iThreadObject = newThread;
unlock();
}
else
{
unlock();
entry_point();
}
}
catch(const std::exception& aException)
{
iState = Error;
unlock();
std::cerr << std::string("Error starting thread due to exception
being thrown (") + aException.what() + ")." << std::endl;
throw;
}
catch(...)
{
iState = Error;
unlock();
std::cerr << std::string("Error starting thread due to exception of
unknown type being thrown.") << std::endl;
throw;
}
}
 
My entry_point() method which calls the pure virtual task() function:
 
void thread::entry_point()
{
lock();
iState = Started;
iId = boost::this_thread::get_id();
unlock();
try
{
task(); /* This is the pure virtual that requires overriding */
if (!iUsingExistingThread)
{
lock();
if (iState == Started)
iState = Finished;
unlock();
}
}
catch(const std::exception& aException)
{
std::cerr << std::string("Thread terminating due to an uncaught
exception was being thrown (") + aException.what() + ")." << std::endl;
throw;
}
catch(...)
{
std::cerr << "Thread terminating due to an uncaught exception of
unknown type being thrown." << std::endl;
throw;
}
}
 
 
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"
 
/Flibble
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 20 01:44PM

On 20/12/2014 11:31, me wrote:
 
> Well, partial kudos anyway...std::bind() was helpful, but if run was a
> virtual then it barfed. It works when run is a simple class method. The
> workaround of having run() call a virtual works.
 
You are talking shite mate: you can use virtual functions with
std::bind. Are you a fucking annoying troll? You seem like one to me;
either that or you are a common all garden bullshitter.
 
/Flibble
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.
"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
Luca Risolia <luca.risolia@linux-projects.org>: Dec 20 07:01PM +0100

Il 18/12/2014 22:59, jacob navia ha scritto:
> Why <<?
 
The inserter "<<" and the extractor ">>" had been deliberately chosen
for a number of reasons:
 
1. it was not possible to invent new lexical elements
2. other operators like "=" or ">" and "<" were considered inappropriate
for I/O. In particular, the former has a bad order of operator
association i.e. cout=a=b means cout=(a=b) instead of (cout=a)=b.
3. many preferred two distinct operators for insertion and extraction,
and ">>" and "<<" are symmetric symbols as the operations they represent.
4. operator >> and operator << have a priority low enough to write
expressions such as cout << a+b*c << '\n' without the need of parenthesis.
5. they are rarely used with base types
Vir Campestris <vir.campestris@invalid.invalid>: Dec 20 09:28PM

On 20/12/2014 18:01, Luca Risolia wrote:
> The inserter "<<" and the extractor ">>" had been deliberately chosen
> for a number of reasons:
 
On friday I met some code that said
 
foo % bar % now % now;
 
foo turned out to be a boost object that overrides operator% for a
printf-type operation where you can specify parameters by position.
 
And, yes, now was the current time.
 
Andy
"Öö Tiib" <ootiib@hot.ee>: Dec 20 08:00AM -0800

> I thought that lambda expression like (_1<_2) generates functor. It looks
> like it rather generates an object of a functor, right ? This is the
> source of my confusion.
 
Yes, make clear difference in your mind about what is type what is
variable what is function and what is function call.
 
> I also wonder why the following does not compile
> map<string, string> myMap(_1<_2)
 
Where it is written that you can define such variable?:
 
std::less<std::string> c = _1 < _2;
 
You can't. C++ is not voo-doo shamanism of dark wizards. It is clear,
strongly-typed programming language.
 
> I suspect that most probably the 3-rd template parameter is difficult to
> deduce and a compiler just gives up. Am I right ?
 
How? Now you mix up function templates and class templates. C++ does not
deduce type of class by constructor arguments. You will be wrong for
several years to come if you try to deduce what a line of code does by
looking at it and philosophizing what it "most probably" does.
 
Instead look into specification of 'std::map':
 
template < class Key, // map::key_type
class T, // map::mapped_type
class Compare = less<Key>, // map::key_compare
class Alloc // map::allocator_type
= allocator<pair<const Key,T> >
> class map;
 
What is the trick that it allows you to declare?:
 
map<string, string> x;
 
What is fully written out type of 'x' on above line?
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
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)