comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Naming conventions for private virtual methods - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/cd78ce70e48273eb?hl=en
* Boost - 11 messages, 6 authors
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
* Return by reference - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/f6dd94c3223a1dbf?hl=en
* a totally self balanced tree for unsigned integers... - 4 messages, 2
authors
http://groups.google.com/group/comp.lang.c++/t/f7fa6decb00d9969?hl=en
* Available C++ Libraries FAQ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/3575ff8bbf7f732e?hl=en
* Can't think of a good subject - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/ff410bf5e81204c2?hl=en
* show all subset of a set - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/708873746ae8ae59?hl=en
* This is 4 u - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/e7671013dc7133f3?hl=en
* A Brief Introduction to Islam - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/a31b8ce9ae713c37?hl=en
==============================================================================
TOPIC: Naming conventions for private virtual methods
http://groups.google.com/group/comp.lang.c++/t/cd78ce70e48273eb?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Feb 14 2014 10:28 am
From: Daniel
On Friday, February 14, 2014 11:53:14 AM UTC-5, Victor Bazarov wrote:
>
> From the implementation 'value' here is a "setter", so it might make
> sense to indicate that.
>
> Another argument is that the overloaded function shall be specific to
> each class deriving from 'base', so it might make sense to add
> "specific" to it (either as a suffix or as a prefix).
>
That's helpful, thanks,
Daniel
==============================================================================
TOPIC: Boost
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
==============================================================================
== 1 of 11 ==
Date: Fri, Feb 14 2014 11:12 am
From: Paavo Helde
Öö Tiib <ootiib@hot.ee> wrote in
news:5499b6d8-5127-428a-96a1-44df98c1a473@googlegroups.com:
> If the objects for 'std::shared_ptr' are allocated with
> 'make_shared' then I haven't observed much performance
> difference with intrusive ref-counting. What are the key features
> it lacks?
Intrusive smartpointers have a convenient property that they can be created
from plain pointers (like 'this') or references. Let's say you are changing
some function which currently has only a pointer or reference to the
object, and want to call some other function which expects a smartpointer,
or want to store a smartpointer for later use. With intrusive smartpointers
this is a no-braner, otherwise it becomes a PITA to pass smartpointers
through all those functions which actually do not need them.
Of course, this style works best if *all* objects of the given class can be
accessed via smartpointers (all objects are allocated only dynamically, for
example). This requirement may appear as a drawback in some cases.
Cheers
Paavo
== 2 of 11 ==
Date: Fri, Feb 14 2014 12:03 pm
From: Ian Collins
James Kanze wrote:
> On Saturday, 18 January 2014 00:09:45 UTC, Ian Collins wrote:
>> woodbrian77@gmail.com wrote:
>
>>> I think std::array would be a better example. I still
>>> don't find much need for shared_ptr.
>
>> Maybe you don't but others certainly do!
>
> I don't know. The way it's implemented often creates more
> problems than it's worth.
Like any software tool, it depends how you use it. Smart pointers and
reference counting were a couple of the C++ tricks that first pulled me
over from C and I've been using them ever since.
> Reference counted pointers seem irrelevant for a lot of
> applications: some won't use any dynamic memory, except within
> the standard containers, and many others will only use it for
> entity objects, which have deterministic lifetimes for which
> shared_ptr is totally irrelevant. And even in the few cases
> where intensive use of reference counted pointers is relevant,
> you probably want some sort of invasive counting, to avoid
> errors.
Invasive counting should have a slight performance edge, but the
programmer doesn't always have control of the type contained by the
pointer. In cases where objects are manipulated more often than that
are allocated, the advantages are less obvious. Most of my use cases
for std::shared_ptr are build a tree, process the tree data where the
process phase dominates the run time.
Care to explain "to avoid errors"?
> We experimented with `std::shared_ptr` when we moved to
> C++11, but found that it didn't work for us, and went back to
> our home written one.
I went the other way...
--
Ian Collins
== 3 of 11 ==
Date: Fri, Feb 14 2014 1:17 pm
From: Öö Tiib
On Friday, 14 February 2014 21:12:58 UTC+2, Paavo Helde wrote:
> Öö Tiib <ootiib@hot.ee> wrote in
> news:5499b6d8-5127-428a-96a1-44df98c1a473@googlegroups.com:
>
> > If the objects for 'std::shared_ptr' are allocated with
> > 'make_shared' then I haven't observed much performance
> > difference with intrusive ref-counting. What are the key features
> > it lacks?
>
> Intrusive smartpointers have a convenient property that they can be created
> from plain pointers (like 'this') or references.
Boost has 'shared_from_this<>()' but I have never needed it. Some Boost.Asio
examples use it.
> Let's say you are changing
> some function which currently has only a pointer or reference to the
> object, and want to call some other function which expects a smartpointer,
> or want to store a smartpointer for later use. With intrusive smartpointers
> this is a no-braner, otherwise it becomes a PITA to pass smartpointers
> through all those functions which actually do not need them.
Is it some sort of mid-way refactoring where we have raw pointers in mix
with smarts?
> Of course, this style works best if *all* objects of the given class can
> be accessed via smartpointers (all objects are allocated only dynamically,
> for example). This requirement may appear as a drawback in some cases.
Yes, typically constructor is protected and there are factories that
'make_shared'. What is the drawback with that approach?
== 4 of 11 ==
Date: Fri, Feb 14 2014 2:49 pm
From: Paavo Helde
Öö Tiib <ootiib@hot.ee> wrote in
news:6614aa58-859d-4a24-9cab-adb713b48ae2@googlegroups.com:
> Yes, typically constructor is protected and there are factories that
> 'make_shared'. What is the drawback with that approach?
The drawback is that sometimes you want a temporary object which could be
an automatic object on the stack, but you cannot have that (as the
constructor is protected, for good reasons). I understand this is only a
performance issue, but in the spirit it is against the zero overhead
principle of C++.
Cheers
Paavo
== 5 of 11 ==
Date: Fri, Feb 14 2014 5:05 pm
From: Öö Tiib
On Saturday, 15 February 2014 00:49:43 UTC+2, Paavo Helde wrote:
> Öö Tiib <ootiib@hot.ee> wrote in
> news:6614aa58-859d-4a24-9cab-adb713b48ae2@googlegroups.com:
>
> > Yes, typically constructor is protected and there are factories that
> > 'make_shared'. What is the drawback with that approach?
>
> The drawback is that sometimes you want a temporary object which could be
> an automatic object on the stack, but you cannot have that (as the
> constructor is protected, for good reasons). I understand this is only a
> performance issue, but in the spirit it is against the zero overhead
> principle of C++.
I can't find case when I want that. You can leave particular constructor
public as performance optimization but it is becoming rather dim for me
what type of object we are talking about.
== 6 of 11 ==
Date: Fri, Feb 14 2014 10:46 pm
From: Jorgen Grahn
On Fri, 2014-02-14, James Kanze wrote:
> On Saturday, 18 January 2014 00:09:45 UTC, Ian Collins wrote:
>> woodbrian77@gmail.com wrote:
>
>> > On Friday, January 17, 2014 9:37:16 AM UTC-6, Alf P. Steinbach wrote:
>
>> >> You can use the header-only sub-libraries without building Boost.
>
>> >> However, the most useful of them are now part of the standard, e.g.
>> >> shared_ptr.
>
>> > I think std::array would be a better example. I still
>> > don't find much need for shared_ptr.
>
>> Maybe you don't but others certainly do!
>
> I don't know. The way it's implemented often creates more
> problems than it's worth.
>
> Reference counted pointers seem irrelevant for a lot of
> applications: some won't use any dynamic memory, except within
> the standard containers, and many others will only use it for
> entity objects, which have deterministic lifetimes for which
> shared_ptr is totally irrelevant.
That's where I am. My objects are either on the stack or owned by
containers. No doubt smart pointers have a place in C++, but I have
not yet come across a problem where I needed them.
And that takes us back to Ian Collins' "Maybe you don't but others
certainly do!" above. "Others" doesn't mean "everyone else" but
"enough people to make it worth standardizing".
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 7 of 11 ==
Date: Sat, Feb 15 2014 2:12 am
From: Tobias Müller
Paavo Helde <myfirstname@osa.pri.ee> wrote:
> ÷ˆ Tiib <ootiib@hot.ee> wrote in
> news:5499b6d8-5127-428a-96a1-44df98c1a473@googlegroups.com:
>
>> If the objects for 'std::shared_ptr' are allocated with
>> 'make_shared' then I haven't observed much performance
>> difference with intrusive ref-counting. What are the key features
>> it lacks?
>
> Intrusive smartpointers have a convenient property that they can be created
> from plain pointers (like 'this') or references. Let's say you are changing
> some function which currently has only a pointer or reference to the
> object, and want to call some other function which expects a smartpointer,
> or want to store a smartpointer for later use. With intrusive smartpointers
> this is a no-braner, otherwise it becomes a PITA to pass smartpointers
> through all those functions which actually do not need them.
But that's also a bit dangerous. If a function takes a reference as
parameter/raw pointer I usually expect that it is not taking (any kind of)
ownership of the object.
I always wondered if it useful to have a "smart object" template like:
template <typename T>
class RC : public T
{
public:
/* add perfect forwarding constructors here */
void addRef();
void release();
private:
int count;
};
theoretically it combines the the advantages of internal and external
reference counts:
- you can use T on the stack and RC<T> as smart object, as with external
counts.
- performance of internal counts.
- safety/"ownership contract" of external count: you can only create smart
pointers from RC<T>* not from T*.
- You can pass by raw pointer/reference and create smart pointers on
demand, but still have the "ownership contract"
Any disadvantages?
Tobi
== 8 of 11 ==
Date: Sat, Feb 15 2014 3:14 pm
From: Öö Tiib
On Saturday, 15 February 2014 12:12:53 UTC+2, Tobias Müller wrote:
> I always wondered if it useful to have a "smart object" template like:
>
> template <typename T>
> class RC : public T
> {
> public:
> /* add perfect forwarding constructors here */
> void addRef();
> void release();
> private:
> int count;
> };
>
> theoretically it combines the the advantages of internal and external
> reference counts:
> - you can use T on the stack and RC<T> as smart object, as with external
> counts.
> - performance of internal counts.
> - safety/"ownership contract" of external count: you can only create smart
> pointers from RC<T>* not from T*.
> - You can pass by raw pointer/reference and create smart pointers on
> demand, but still have the "ownership contract"
>
> Any disadvantages?
The 'boost::intrusive_ref_counter' is bit better since one can regulate
thread safety of access to that 'count'. Also CRTP makes it simpler,
no need for variadic template constructor for template (that makes
most readers head spin).
== 9 of 11 ==
Date: Sun, Feb 16 2014 4:46 am
From: Tobias Müller
Öö Tiib <ootiib@hot.ee> wrote:
> On Saturday, 15 February 2014 12:12:53 UTC+2, Tobias Müller wrote:
>> I always wondered if it useful to have a "smart object" template like:
>>
>> template <typename T>
>> class RC : public T
>> {
>> public:
>> /* add perfect forwarding constructors here */
>> void addRef();
>> void release();
>> private:
>> int count;
>> };
>>
>> theoretically it combines the the advantages of internal and external
>> reference counts:
>> - you can use T on the stack and RC<T> as smart object, as with external
>> counts.
>> - performance of internal counts.
>> - safety/"ownership contract" of external count: you can only create smart
>> pointers from RC<T>* not from T*.
>> - You can pass by raw pointer/reference and create smart pointers on
>> demand, but still have the "ownership contract"
>>
>> Any disadvantages?
>
> The 'boost::intrusive_ref_counter' is bit better since one can regulate
> thread safety of access to that 'count'. Also CRTP makes it simpler,
> no need for variadic template constructor for template (that makes
> most readers head spin).
But boost::intrusive_ref_counter is basically just a helper class for
implementing a plain normal intrusive count.
It has none of the advantages of the above solution.
My RC template works with any existing class, and with appropriate
specialization also with primitive types. Just by using RC<SomeClass> or
RC<int>. No need to declare a wrapper. No need to decide at design time
whether a class should be "smart".
Tobi
== 10 of 11 ==
Date: Sun, Feb 16 2014 11:16 am
From: Richard Damon
On 2/15/14, 5:12 AM, Tobias Müller wrote:
> Paavo Helde <myfirstname@osa.pri.ee> wrote:
>> ÷ˆ Tiib <ootiib@hot.ee> wrote in
>> news:5499b6d8-5127-428a-96a1-44df98c1a473@googlegroups.com:
>>
>>> If the objects for 'std::shared_ptr' are allocated with
>>> 'make_shared' then I haven't observed much performance
>>> difference with intrusive ref-counting. What are the key features
>>> it lacks?
>>
>> Intrusive smartpointers have a convenient property that they can be created
>> from plain pointers (like 'this') or references. Let's say you are changing
>> some function which currently has only a pointer or reference to the
>> object, and want to call some other function which expects a smartpointer,
>> or want to store a smartpointer for later use. With intrusive smartpointers
>> this is a no-braner, otherwise it becomes a PITA to pass smartpointers
>> through all those functions which actually do not need them.
>
> But that's also a bit dangerous. If a function takes a reference as
> parameter/raw pointer I usually expect that it is not taking (any kind of)
> ownership of the object.
>
> I always wondered if it useful to have a "smart object" template like:
>
> template <typename T>
> class RC : public T
> {
> public:
> /* add perfect forwarding constructors here */
> void addRef();
> void release();
> private:
> int count;
> };
>
> theoretically it combines the the advantages of internal and external
> reference counts:
> - you can use T on the stack and RC<T> as smart object, as with external
> counts.
> - performance of internal counts.
> - safety/"ownership contract" of external count: you can only create smart
> pointers from RC<T>* not from T*.
> - You can pass by raw pointer/reference and create smart pointers on
> demand, but still have the "ownership contract"
>
> Any disadvantages?
>
> Tobi
>
One issue is that RC<Base> and RC<Derived> are not related, so if you
have a collection that takes RC<Base>, there is no way to add a
RC<Derived> to it.
There probably are use cases for this, just as there are use cases for
the standard version.
== 11 of 11 ==
Date: Mon, Feb 17 2014 5:21 am
From: Öö Tiib
On Sunday, 16 February 2014 14:46:12 UTC+2, Tobias Müller wrote:
> Öö Tiib <ootiib@hot.ee> wrote:
> > On Saturday, 15 February 2014 12:12:53 UTC+2, Tobias Müller wrote:
> >> I always wondered if it useful to have a "smart object" template like:
> >>
> >> template <typename T>
> >> class RC : public T
> >> {
> >> public:
> >> /* add perfect forwarding constructors here */
> >> void addRef();
> >> void release();
> >> private:
> >> int count;
> >> };
> >>
> >> theoretically it combines the the advantages of internal and external
> >> reference counts:
> >> - you can use T on the stack and RC<T> as smart object, as with external
> >> counts.
> >> - performance of internal counts.
> >> - safety/"ownership contract" of external count: you can only create smart
> >> pointers from RC<T>* not from T*.
> >> - You can pass by raw pointer/reference and create smart pointers on
> >> demand, but still have the "ownership contract"
> >>
> >> Any disadvantages?
> >
> > The 'boost::intrusive_ref_counter' is bit better since one can regulate
> > thread safety of access to that 'count'. Also CRTP makes it simpler,
> > no need for variadic template constructor for template (that makes
> > most readers head spin).
>
> But boost::intrusive_ref_counter is basically just a helper class for
> implementing a plain normal intrusive count.
> It has none of the advantages of the above solution.
None? It may be I do not understand the advantages. We can use 'T' on
the stack and 'shared_ptr<T>' as shared object. Performance of internal
counts is there with 'make_shared'. There is 'shared_ptr::use_count'.
Usage of raw pointers directly in code does not make sense for me. I
either use standard iterators/smart pointers/references or some self-made
things. 'boost::intrusive_ref_counter' may be useful for designs
involving copy-on-write or pimpl or both. Your 'RC<T>' may be also
useful but I can not think of example.
> My RC template works with any existing class, and with appropriate
> specialization also with primitive types. Just by using RC<SomeClass> or
> RC<int>. No need to declare a wrapper. No need to decide at design time
> whether a class should be "smart".
Usage of 'RC<int>' is more likely over-engineering than
'std::shared_ptr<int>' (where 'int' may be "handle" of something needing
special "deleter"). The question is not about "smartness". There are
objects that are never "cloned" (may be "copied") and there are objects
that are never "copied" (may be "cloned"). It needs to be clear design
time what type of object it is there and smart pointers make sense only
for the second type.
==============================================================================
TOPIC: Return by reference
http://groups.google.com/group/comp.lang.c++/t/f6dd94c3223a1dbf?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Feb 14 2014 10:20 am
From: Luca Risolia
James Kanze wrote:
>> > SubObject &sub = c.GetSubObject();
>
>> Don't return references to sub objects.
>
> That depends on the role of the class. Things like
> std::vector<>::operator[] should certainly return a reference.
>> To safely share (sub)objects in memory use smart pointers.
>
> I can't really think of a situation where I'd want to "share" an
> object. An object will normally either be independant (an
> entity object, owned by no one), or part of another object.
Look at the example I gave in my other answer to this post to know what
sharing means with regard to the OP question. There you will certainly notice
that the term "share" is used in two standard function names at least. That
example should make the concept more clear to you and also answer to both your
previous observations.
==============================================================================
TOPIC: a totally self balanced tree for unsigned integers...
http://groups.google.com/group/comp.lang.c++/t/f7fa6decb00d9969?hl=en
==============================================================================
== 1 of 4 ==
Date: Fri, Feb 14 2014 1:44 pm
From: "Chris M. Thomasson"
I do not even want to go into why James tried to post this as his own!
:^/ GRRRR!!!!! #$%#$% FUC32432KL#$@#$@
Anyway, He made a fatal mistake! My name is in my cryptic MACROS!!!!
Take a look:
https://groups.google.com/d/topic/comp.programming/tjlLW7fFmsE/discussion
HAW HAW!!!!!
:^)
Anyway, I need to use it now for a database.
== 2 of 4 ==
Date: Fri, Feb 14 2014 2:51 pm
From: "Chris M. Thomasson"
"Chris M. Thomasson" wrote in message
news:ldm2of$p64$1@speranza.aioe.org...
[...]
Here is the link to the relevant code:
https://groups.google.com/forum/#!msg/comp.programming/tjlLW7fFmsE/fXdyD9QcG2cJ
notice my name in TREE_NAME?
Grrr!!!
____________________________________________________
typedef unsigned int tree_key;
#define BITS 4
#define MASK ~(UINT_MAX << BITS)
#define NODES (MASK + 1)
struct tree
{
struct tree* nodes[NODES];
tree_key key;
};
struct tree*
tree_find(struct tree* root,
tree_key origin_key)
{
tree_key key = origin_key;
while (root)
{
if (root->key == origin_key) break;
root = root->nodes[key & MASK];
key >>= BITS;
}
return root;
}
Is that something like what you are thinking of Ben?
Here is source code for a quick test program that implements the new
algorithm:
#include <stdio.h>
#include <assert.h>
#include <stdlib.h>
#include <string.h>
#include <limits.h>
#include <time.h>
#define QUOTEX(t)#t
#define QUOTE(t)QUOTEX(t)
#define HASH_DEPTH 1
#define HASH(k) ((k) & (HASH_DEPTH - 1))
#define TREE_BITS 4
#define TREE_MASK ~(UINT_MAX << TREE_BITS)
#define TREE_NODES (TREE_MASK + 1)
#define TREE_SEARCH_ALGO_BINARY 0
#define TREE_SEARCH_ALGO_BIT 1
#define TREE_SEARCH_ALGO TREE_SEARCH_ALGO_BIT
#if (TREE_SEARCH_ALGO == TREE_SEARCH_ALGO_BINARY)
# undef TREE_NODES
# define TREE_NODES 2
# define TREE_NAME "Normal Binary Tree\n\n\n"
#else
# define TREE_NAME "Chris' %lu-Ary %lu-Bit Trie?\n\n\n", \
TREE_NODES, TREE_BITS
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment