Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > item callback on container or why STL does not have pointer to iterator conversion open?

Reply
Thread Tools

item callback on container or why STL does not have pointer to iterator conversion open?

 
 
forester
Guest
Posts: n/a
 
      08-22-2005
lets say its common situation when object have subobjects in container
and receives callbacks from contained items. and object want to move
objects in containers on signal(callback).

iterator is needed for container modifications, item cannot know its
iterator, at least its not easy to do so and i think cannot be done
type-safe avoiding virtual functions and stuff.

'this' pointer from items is a freeby :>.
the problem is, std containers want full linear scan to find iterator
from pointer, while from implemention side converting pointer to
std::list or std::map iterator is free (substracting offset to get
std::list::node from pointer and then construct iterator from node).

why this is done so? this makes std containers unusable in described
child to container callback scenarios - huge overhead trying to move
item in container on callback.

 
Reply With Quote
 
 
 
 
Alipha
Guest
Posts: n/a
 
      08-22-2005

forester wrote:
> lets say its common situation when object have subobjects in container
> and receives callbacks from contained items. and object want to move
> objects in containers on signal(callback).
>
> iterator is needed for container modifications, item cannot know its
> iterator, at least its not easy to do so and i think cannot be done
> type-safe avoiding virtual functions and stuff.
>
> 'this' pointer from items is a freeby :>.
> the problem is, std containers want full linear scan to find iterator
> from pointer, while from implemention side converting pointer to
> std::list or std::map iterator is free (substracting offset to get
> std::list::node from pointer and then construct iterator from node).


this cannot be done without using reinterpret_cast or c-style cast and
invoking implementation-defined behavior.

> why this is done so? this makes std containers unusable in described
> child to container callback scenarios - huge overhead trying to move
> item in container on callback.


have the container be std::set<child*> or perhaps a non-standard
hash_set. in those cases, retrieving an iterator from a child* would be
sufficiently fast for most needs.

 
Reply With Quote
 
 
 
 
forester
Guest
Posts: n/a
 
      08-22-2005
reinterpret_cast is not needed, static_cast well be ok, node from
list/tree can look this:

template <class T>
struct node : T {
node<T> *prev_;
node<T> *next_;
};
T *ptr;
node<T> *node_ptr = static_cast<node<T>* >(ptr);

using std::set<T*> or non-standart hash to perform operation that can
be done by one processor instuction looks insane, imho.

 
Reply With Quote
 
Pete Becker
Guest
Posts: n/a
 
      08-22-2005
forester wrote:
> reinterpret_cast is not needed, static_cast well be ok, node from
> list/tree can look this:
>
> template <class T>
> struct node : T {
> node<T> *prev_;
> node<T> *next_;
> };
> T *ptr;
> node<T> *node_ptr = static_cast<node<T>* >(ptr);
>
> using std::set<T*> or non-standart hash to perform operation that can
> be done by one processor instuction looks insane, imho.
>


I was going to reply to this, until I saw the assertion that not doing
it is insane. That's not a good way to encourage discussion. I'll just
say that while your hack might work in some circumstances, it's
incomplete, and it won't work for other kinds of containers.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
 
Reply With Quote
 
forester
Guest
Posts: n/a
 
      08-22-2005
well for other types of containers unsupported conversion will result
in nice compiling error. for what are iterators traits at the end?

i am sorry if my message was looking wrong way, this is not my child
language and i used nearest word to express my feelings .

 
Reply With Quote
 
Pete Becker
Guest
Posts: n/a
 
      08-22-2005
forester wrote:
>
> i am sorry if my message was looking wrong way, this is not my child
> language and i used nearest word to express my feelings .
>


I overreacted. Sorry.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
 
Reply With Quote
 
Ram
Guest
Posts: n/a
 
      08-23-2005
> reinterpret_cast is not needed, static_cast well be ok, node from
> list/tree can look this:
>
> template <class T>
> struct node : T {
> node<T> *prev_;
> node<T> *next_;
> };
> T *ptr;
> node<T> *node_ptr = static_cast<node<T>* >(ptr);


You are going against the entire principle of data abstraction, etc.
etc. Thats not a standard way of doing it as the language doesn't
say anything abt the way lists and maps are implemented.

>
> using std::set<T*> or non-standart hash to perform operation that can
> be done by one processor instuction looks insane, imho.


Not really, without knowing abt the way the containers are implemented.

Ram

 
Reply With Quote
 
Maxim Yegorushkin
Guest
Posts: n/a
 
      08-23-2005
forester wrote:
> lets say its common situation when object have subobjects in container
> and receives callbacks from contained items. and object want to move
> objects in containers on signal(callback).
>
> iterator is needed for container modifications, item cannot know its
> iterator, at least its not easy to do so and i think cannot be done
> type-safe avoiding virtual functions and stuff.
>
> 'this' pointer from items is a freeby :>.
> the problem is, std containers want full linear scan to find iterator
> from pointer, while from implemention side converting pointer to
> std::list or std::map iterator is free (substracting offset to get
> std::list::node from pointer and then construct iterator from node).
>
> why this is done so? this makes std containers unusable in described
> child to container callback scenarios - huge overhead trying to move
> item in container on callback.


Standard containers are no silver bullets, they are just usual pieces
of code suitable for reuse in some circumstances and not suitable in
others. Writing your own container may well save you from troubles
trying to put a square standard container in a round hole.

 
Reply With Quote
 
forester
Guest
Posts: n/a
 
      08-23-2005
> You are going against the entire principle of data abstraction, etc.
> etc. Thats not a standard way of doing it as the language doesn't
> say anything abt the way lists and maps are implemented.


this was just example on reply that this cannot be done compatibly.

maybe language does not say how to implement lists, but it say how they
must behave.
like contant time insertions/deletions for lists, constant time access
by index for vector.
and i am talking about constant time pointer to iterator conversion.

 
Reply With Quote
 
forester
Guest
Posts: n/a
 
      08-23-2005
> Standard containers are no silver bullets, they are just usual pieces
> of code suitable for reuse in some circumstances and not suitable in
> others. Writing your own container may well save you from troubles
> trying to put a square standard container in a round hole.


with such approach all that rare used allocators stuff is not needed in
STL - anyone who need to tune allocations can go to hell and write his
own containers, because, you know, silver bullet and round hole stuff.

please note that this is common scenario, where template library,
designed to be flexible, does not behave effectivily.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: STL container iterator not available within template? Saeed Amrollahi C++ 1 06-18-2009 09:37 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
STL inherit from container<T>::iterator Christoph Heindl C++ 2 04-04-2006 06:41 AM
Copy elements from one STL container to another STL container Marko.Cain.23@gmail.com C++ 4 02-16-2006 05:03 PM
std::container::iterator vs std::container::pointer Vivi Orunitia C++ 11 02-04-2004 08:09 AM



Advertisments