Saturday, October 22, 2016

Digest for comp.lang.c++@googlegroups.com - 19 updates in 3 topics

"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 21 05:53PM -0700

I saw an amazing new series premiere tonight. "The Encounter" on
PureFlix. It's based on the 2010 movie of the same title, my
all-time favorite movie. In the movie, Jesus reaches out to
save three people. In the new series, He reaches out to
save the Earthly lives and eternal souls of some young men.
 
2010 Movie:
https://www.youtube.com/watch?v=oGdurzFWPPA
 
2016 Series Premiere:
https://pureflix.com/subscriptions/new?media_id=787629635622
 
Best regards,
Rick C. Hodgin
Melzzzzz <mel@zzzzz.com>: Oct 22 05:09AM +0200

On Fri, 21 Oct 2016 17:53:19 -0700 (PDT)
> https://pureflix.com/subscriptions/new?media_id=787629635622
 
> Best regards,
> Rick C. Hodgin
 
http://www.imdb.com/list/ls000901468/
 
--
press any key to continue or any other to quit
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 22 07:32AM -0700

Why are some people believers, and some not?
 
"We cannot convince a man to believe any
more than we can raise the dead. Such
things are the work of God's Spirit. Men are
brought to faith only through the supernatural
working of God, and He has promised to
work-not through human wisdom or intellectual
expertise, but through the preaching of Christ
crucified and resurrected from the dead!"
- Paul Washer
 
What did Jesus teach?
 
http://biblehub.com/kjv/john/6-44.htm
44 No man can come to me, except the Father which
hath sent me draw him: and I will raise him up at the
last day.
 
-----
Only an inner change by God will enable you to come to know the
truth, to come to faith, to come to see your sin, to come to repent,
to come to Jesus, to ask forgiveness and be saved.
 
Only Jesus can save us. And only those the Father draws will be
saved.
 
Best regards,
Rick C. Hodgin
jacobnavia <jacob@jacob.remcomp.fr>: Oct 22 11:02PM +0200

Le 22/10/2016 à 05:09, Melzzzzz a écrit :
> press any key to continue or any other to quit
 
That looks like Mr Hodgin's "preaching". Any answer is the same
actually, he doesn't care about any answer and can't stop his compulsive
behavior.
 
But nobody can help him. He just doesn't listen.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 22 02:30PM -0700

jacobnavia wrote:
> But nobody can help him. He just doesn't listen.
 
The same could be said for you, Jacob, and many others. The
only difference is if you're right and I'm wrong nothing will happen.
But if I'm right and you're wrong (which I am), you will burn in the
flames of Hell forever.
 
It's worth serious consideration, sir.
 
Best regards,
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 22 03:11AM +0100

On 21/10/2016 17:17, Daniel wrote:
> application will never use more than the main thread, you can improve
> performance by specifying a Mutex template parameter as null_mutex.
 
> But I think I would prefer to use a stateful allocator.
 
Defaults.
 
std::allocator will likely be calling std::malloc which also requires
(internally) synchronization for thread safety so we can ignore this
overhead when comparing std::allocator with boost::fast_pool_allocator.
 
/Flibble
Daniel <danielaparker@gmail.com>: Oct 21 07:46PM -0700

On Friday, October 21, 2016 at 10:12:11 PM UTC-4, Mr Flibble wrote:
 
> std::allocator ... also requires (internally) synchronization for thread safety
 
Indeed
 
> so we can ignore this overhead when comparing std::allocator with
> boost::fast_pool_allocator.
 
Umm ... no :-)
Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 22 05:03PM

On Thu, 2016-10-20, Daniel wrote:
 
>> One reasonable way to compare them could be to look at some typical
>> concrete usage examples, implemented with both approaches.
 
> Yes, those, but also aesthetics.
 
It's in the concrete examples you find the aesthetics; that's where
you might see one of the approaches becoming awkward and the other one
elegant and straightforward.
 
> I've never actually seen std::multimap used outside of
> examples. Perhaps I've been too cloistered.
 
I don't think I've used it either. But I don't know why, so I think
your question is a good one.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 22 09:22PM +0100

On 22/10/2016 03:46, Daniel wrote:
 
>> so we can ignore this overhead when comparing std::allocator with
>> boost::fast_pool_allocator.
 
> Umm ... no :-)
 
Umm ... yes.
 
boost::fast_pool_allocator can offer better performance over
std::allocator when it uses a mutex (default) and even better
performance when it doesn't and you are using it with just one thread.
 
/Flibble
JiiPee <no@notvalid.com>: Oct 22 12:54AM +0100

On 21/10/2016 07:32, Öö Tiib wrote:
> I know only few cases where I have to declare something to be
> of type raw pointer to something else.
 
 
You need a raw pointer if you want a polymorhism and you dont want to
own the object.
 
 
like:
 
class Player
 
{
 
public:
 
private:
 
Renderer* m_renderer; // draws the object
 
};
 
 
now m_renderer can be used as polymorhic pointer to call whatever we
want to have the renderer. And we can live change the renderer...
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 22 01:32AM +0100

On 22/10/2016 00:22, Chris Vine wrote:
> cases where you need raw pointers and why. (Actually, I would be
> satisfied by 2, provided they didn't amount to evading the issue, but I
> cannot speak for your interlocutor).
 
Just because you are lacking the experience to know where to use a raw
pointer doesn't mean you can demand that information from someone else.
 
Three use cases for raw pointers immediately come to mind:
1) Pointers to array elements (preferable to using indices)
2) Non-owning pointer to a polymorphic type the value of which can be
changed at runtime to point to different objects.
3) Opaque raw pointer used as a handle (type erasure or interfacing with
C API)
 
I am sure there are plenty of others.
 
/Flibble
"Öö Tiib" <ootiib@hot.ee>: Oct 22 04:33AM -0700

On Saturday, 22 October 2016 03:32:44 UTC+3, Mr Flibble wrote:
> > cannot speak for your interlocutor).
 
> Just because you are lacking the experience to know where to use a raw
> pointer doesn't mean you can demand that information from someone else.
 
Why to be so pointlessly patronizing? It smells like Jerry
Stuckle or Rick C. Hodgin and so is good to avoid.
 
 
> Three use cases for raw pointers immediately come to mind:
> 1) Pointers to array elements (preferable to using indices)
 
One strong reason why to use raw array is that string literal
is raw array and other is that array dimensions can be deduced from
initializers. Both cases matter about static immutable arrays.
AFAIK the plans about C++17 are to add 'std::array_view' and
'std::string_view' to remove or to reduce those reasons, but I am
not too hopeful about it.
 
> 2) Non-owning pointer to a polymorphic type the value of which can be
> changed at runtime to point to different objects.
 
Again it is unclear where we *must* use raw pointer as mutable reference
to non-owned object. What owns it and how? We likely can use raw pointer
but usually other things (like 'std::reference_wrapper', 'std::weak_ptr'
or some iterator) are more suitable.
 
> 3) Opaque raw pointer used as a handle (type erasure or interfacing with
> C API)
 
Both the 'std::shared_ptr' and 'std::unique_ptr' can be to opaque type
(unlike 'std::auto_ptr'). There just are some constraints.
 
For example on case of class with unique-to-opaque member there is
little constraint that rule of zero causes compiler errors and so
developer has to use rule of five.
 
The smart pointers are useful for wrapping opaque pointers from C API:
 
using unique_file_ptr = std::unique_ptr<std::FILE, int (*)(std::FILE*)>;
 
static
unique_file_ptr make_file(const char* filename, const char* flags)
{
return unique_file_ptr(std::fopen(filename, flags), std::fclose);
}
 
Again if we need a *shared* file pointer then there is little constraint
that we need to make it so that shared_ptr does not call fclose to null
pointer, unique_ptr is smart enough on its own so above works.
 
 
> I am sure there are plenty of others.
 
There may be few. For example we need raw pointer as covariant return
type (on the rare case when we need it).
 
However I wanted to hear some from WoodBrian because he claimed that his
code base is full of such usages where raw pointer is best. Like Chris
pointed out he failed to name any.
"Öö Tiib" <ootiib@hot.ee>: Oct 22 06:07AM -0700

On Saturday, 22 October 2016 02:54:37 UTC+3, JiiPee wrote:
> };
 
> now m_renderer can be used as polymorhic pointer to call whatever we
> want to have the renderer. And we can live change the renderer...
 
All smart pointers I know of have been designed to be useful for
dynamically polymorphic pointers. Actually most of the "weight"
of smart pointers is (somewhat invisibly to users) in support of
such polymorphism.

class Player
{
public:
// ...
private:
// ...
std::unique_ptr<Renderer> renderer_; // draws the object
};
Gareth Owen <gwowen@gmail.com>: Oct 22 03:30PM +0100

> {
> return unique_file_ptr(std::fopen(filename, flags), std::fclose);
> }
 
You have to be careful with the latter, as fclose(NULL) is UB.
"Chris M. Thomasson" <invalid@invalid.invalid>: Oct 22 10:04AM -0700

On 10/21/2016 4:22 PM, Chris Vine wrote:
> cases where you need raw pointers and why. (Actually, I would be
> satisfied by 2, provided they didn't amount to evading the issue, but I
> cannot speak for your interlocutor).
 
FWIW, I use raw pointers when implementing synchronization primitives.
 
Structures like:
__________________________________
struct node
{
std::atomic<node*> next;
};
 
struct stack
{
std::atomic<node*> head;
};
__________________________________
 
are fairly common.
 
Also, you will probably see raw pointers in implementations of
std::malloc, operator new and friends.
"Öö Tiib" <ootiib@hot.ee>: Oct 22 11:29AM -0700

On Saturday, 22 October 2016 17:31:05 UTC+3, gwowen wrote:
> > return unique_file_ptr(std::fopen(filename, flags), std::fclose);
> > }
 
> You have to be careful with the latter, as fclose(NULL) is UB.
 
I am. Why you erased next sentence of mine that already addressed it?:
"Again if we need a *shared* file pointer then there is little constraint
that we need to make it so that shared_ptr does not call fclose to null
pointer, unique_ptr is smart enough on its own so above works."
 
If you wanted same function for 'shared_ptr' then I can try to make one:
 
using shared_file_ptr = std::shared_ptr<std::FILE>;
 
static
shared_file_ptr open_shared_file(const char* filename, const char* flags)
{
auto fp = std::fopen(filename, flags);
return fp != n ? shared_file_ptr(fp, std::fclose) : shared_file_ptr();
}
JiiPee <no@notvalid.com>: Oct 22 07:40PM +0100

On 22/10/2016 14:07, Öö Tiib wrote:
> // ...
> std::unique_ptr<Renderer> renderer_; // draws the object
> };
 
 
mutta unique pointer defines who owns the renderer. If this player does
not own it it would be wrong to use unique pointer but rather a raw
pointer. I know Bjarne has said similar thing (like: "if its not about
ownership, you can use old raw pointer ..." )
 
 
But if the player owns the renderer, then unique pointer would be best.
but obviously here it does not...
"Öö Tiib" <ootiib@hot.ee>: Oct 22 11:41AM -0700

On Saturday, 22 October 2016 20:04:18 UTC+3, Chris M. Thomasson wrote:
 
> are fairly common.
 
> Also, you will probably see raw pointers in implementations of
> std::malloc, operator new and friends.
 
Yes. In implementations of all the primitives like containers or
smart pointers. ;) These things are what remove raw pointers from
usual abstraction level we work at. Most of the time we are not
implementing yet another smart pointer or container but we use
one from *HUGE* pile of already existing, well designed and well
tested ones.
"Öö Tiib" <ootiib@hot.ee>: Oct 22 12:06PM -0700

On Saturday, 22 October 2016 21:40:49 UTC+3, JiiPee wrote:
> > std::unique_ptr<Renderer> renderer_; // draws the object
> > };
 
> mutta unique pointer defines who owns the renderer.
 
"Mutta" means "but"?
 
> not own it it would be wrong to use unique pointer but rather a raw
> pointer. I know Bjarne has said similar thing (like: "if its not about
> ownership, you can use old raw pointer ..." )
 
Sure, we still may use raw pointers for whatever we want to. Pointers are
part of language. I indeed *may* but if I choose some alternative then
all is usually even better. For example for non-owning relations I
prefer references, non-owning smart pointers (like weak_ptr) or iterators
(when real owner is collection).
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)