headers
Matthias Kronenberger | 1 Aug 2002 01:48
Picon
Picon
Favicon

Re: collection container

Hm, what's the point in having such collections?
The pointers in a container would refer to data that is stored somewhere.
Since we want to minimize side effects, the only valid use of a pointer
container would be to store a set
of polymorphic objects.
Even now, the ownership question is raised. So, one should use a smart
pointer.

To adapt the pointers for the standard algorithm of the STL, one could use a
projection iterator adapter.

----- Original Message -----
From: "Bohdan" <yg-boost-users <at> m.gmane.org>
Newsgroups: gmane.comp.lib.boost.user
Sent: Thursday, August 01, 2002 12:49 AM
Subject: collection container

> Has boost any plans on creating container, that holds data by pointer, not
> by
> value?
>
> Rationale:
> It is impossible to use normally vector<...> for types that do not have
> copy constructor. Interface of vector< shared_ptr<...> > doesn't seems to
be
> very convenient( for example with std::algorithms ).
> And most of all it is not good idea to show vector< shared_ptr<...> >
> interface to
> user of my lib, that wants to have container::iterator with normal
behavior.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Bohdan | 1 Aug 2002 11:12
Picon

Re: collection container


"Matthias Kronenberger" <mkronen <at> rhrk.uni-kl.de> wrote in message
news:000501c238ec$cdd152c0$5ab2f683 <at> koe5isewcagsnh...
> Hm, what's the point in having such collections?
> The pointers in a container would refer to data that is stored somewhere.

ok. What if your class hasn't copy constructor or you don't want to
copy your object ... have you other choice ?

> Since we want to minimize side effects, the only valid use of a pointer
> container would be to store a set
> of polymorphic objects.

Sure, this is another purpose for implementing it.

> Even now, the ownership question is raised. So, one should use a smart
> pointer.

You are right. If you look again on my previous posting you will see
something about shared_ptr< ... >.

>
> To adapt the pointers for the standard algorithm of the STL, one could use
a
> projection iterator adapter.

   I know about projection iterator and iterator adaptor library.
And i didn't tell that it is impossible to use vector< smart_ptr<...> > with
std::algorithms, i said that it is just uncomfortable.
   Of course you can use iterator adaptor and be happy, but you
(Continue reading)

Permalink | Reply | 3 comments |
headers
Matthias Kronenberger | 1 Aug 2002 11:44
Picon
Picon
Favicon

Re: collection container


----- Original Message -----
From: "Bohdan" <yg-boost-users <at> m.gmane.org>
Newsgroups: gmane.comp.lib.boost.user
Sent: Thursday, August 01, 2002 11:12 AM
Subject: Re: collection container

>
> "Matthias Kronenberger" <mkronen <at> rhrk.uni-kl.de> wrote in message
> news:000501c238ec$cdd152c0$5ab2f683 <at> koe5isewcagsnh...
> > Hm, what's the point in having such collections?
> > The pointers in a container would refer to data that is stored
somewhere.
>
> ok. What if your class hasn't copy constructor or you don't want to
> copy your object ... have you other choice ?
>
>

Well, the objects need to be stored somewhere. If we don't want to deal with
reallocation, we need a container
whose iterators are stable under insert, for example a list or a set.

You are now able to use the iterator to that container to access the
objects.

std::vector <someIterator> v;
v[123]->functionCall();
or
v.front()-> dataMember;
(Continue reading)

Permalink | Reply | 2 comments |
headers
John Maddock | 1 Aug 2002 13:28
Picon

Re: Creating groups of regular expressions

> I have started using Regex++ and like it a lot but is there a way to
> use grouping constructs using Regex++ / any alternative that would
> provide the same functionality?

Can you explain that please, the regex lib supports marked sub-expressions
if that's what you mean...

John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm
Permalink | Reply | 0 comments |
headers
Lev Assinovsky | 1 Aug 2002 11:12

Newbie link problem

Hi all! 
I would like to do a very simple thing: 
link my main tst.cpp with the third party library $(MYDIR)/libfoo.a. 
The final command line should be: 
g++ -o tst tst.cpp -L$(MYDIR) -lfoo 
Currently I have in my Jamfile: 
exe tst : tst.cpp 
: <include>$(ADC_ROOT) <include>$(BOOST_ROOT) <include>"$(HOME)/inc" 
; 
What must be added to provide linking with libfoo.a? 
(adding of variable LINKLIBS=$(MYDIR)/libfoo.a DOESN'T WORK)
Thanks in advance! 

----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909

[Non-text portions of this message have been removed]
Permalink | Reply | 0 comments |
headers
Bohdan | 1 Aug 2002 13:43
Picon

Re: collection container

> Well, the objects need to be stored somewhere.

What is wrong with shared_ptr or intrusive_ptr ?
This is user problem, how he wants to allocate his object.
Even more he can use different allocation strategies
for objects in same collecion.

> If we don't want to deal with
> reallocation,

What realloctation ?  Without copy constructor ... ?

> we need a container
> whose iterators are stable under insert, for example a list or a set.

As mentioned in previous postings these containers require
copy constructor ... so you can forget about using them directly
for storing objects. It would be better to use some kind of pool,
if you want, but such container would be very restricted in use,
because user can not select it's own allocation strategy.
My opinion is that container should deal with some kind of
pointers, but not with real data. Imagine you have descendant
objects of the same base class in one collection ... so which
allocation strategy you propose in this case ... ?

> You are now able to use the iterator to that container to access the
> objects.
>
> std::vector <someIterator> v;
> v[123]->functionCall();
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bohdan | 1 Aug 2002 15:53
Picon

Re: collection container

Sorry for mistake:

> std::vector <someIterator>::iterator doesn't behave like normal item
> operator.

should be

std::vector <someIterator>::iterator doesn't behave like normal iterator.

Info: <http://www.boost.org>
Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl>
Unsubscribe: <mailto:boost-users-unsubscribe <at> yahoogroups.com>

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Permalink | Reply | 0 comments |
headers
Erik Arner | 1 Aug 2002 15:42
Picon

[BGL] Vertex removal without iterator invalidation?


Yet another question from the BGL newbie...

I understand that performing remove_vertex() on graphs with
vertexList=vecS will result in invalidated itarors and descriptors for
the graph.

However, some toy examples i made suggest that if I remove a vertex in
such a graph, the vertex descriptors and vertex iterators for vertices
with *lower* ID than the removed vertex remain valid after removal,
while those for higher ID vertices are invalidated.

Is this a true feature of a graph with Vertexlist=vecS, or is my
observation a mere coincidence? Is it safe to write code that exploits
this "feature"?

If it indeed is a feature, I can construct a sorted list of vertices to
remove, and remove the vertices in descending order in an easy fashion.

If it is not a feature, any suggestions on how to perform this task i.e.
removing a list of vertices while keeping the VertexList type vecS?

Thanks,
Erik

Info: <http://www.boost.org>
Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl>
Unsubscribe: <mailto:boost-users-unsubscribe <at> yahoogroups.com>

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jeremy Siek | 1 Aug 2002 18:06
Picon
Picon
Favicon

Re: [BGL] Vertex removal without iterator invalidation?

Hi Erik,

On Thu, 1 Aug 2002, Erik Arner wrote:
yg-boo>
yg-boo> Yet another question from the BGL newbie...
yg-boo>
yg-boo> I understand that performing remove_vertex() on graphs with
yg-boo> vertexList=vecS will result in invalidated itarors and descriptors for
yg-boo> the graph.
yg-boo>
yg-boo> However, some toy examples i made suggest that if I remove a vertex in
yg-boo> such a graph, the vertex descriptors and vertex iterators for vertices
yg-boo> with *lower* ID than the removed vertex remain valid after removal,
yg-boo> while those for higher ID vertices are invalidated.
yg-boo>
yg-boo> Is this a true feature of a graph with Vertexlist=vecS, or is my
yg-boo> observation a mere coincidence? Is it safe to write code that exploits
yg-boo> this "feature"?

Yes, that is indeed a true feature.

yg-boo> If it indeed is a feature, I can construct a sorted list of vertices to
yg-boo> remove, and remove the vertices in descending order in an easy fashion.

That sounds plausible.

Cheers,
Jeremy

----------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
Erik Arner | 1 Aug 2002 18:16
Picon

Re: [BGL] Vertex removal without iterator invalidation?

Jeremy Siek wrote:
> 
> On Thu, 1 Aug 2002, Erik Arner wrote:
>
> yg-boo> Is this a true feature of a graph with Vertexlist=vecS, or is my
> yg-boo> observation a mere coincidence? Is it safe to write code that exploits
> yg-boo> this "feature"?
> 
> Yes, that is indeed a true feature.

Great! Saves me alot of headache... I'll have my hands on the book in a
few days, so hopefully I won't have to bother you so much in the future
:-)

Thanks,
Erik

Info: <http://www.boost.org>
Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl>
Unsubscribe: <mailto:boost-users-unsubscribe <at> yahoogroups.com>

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Permalink | Reply | 0 comments |

Gmane