gnash-commit
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-commit] gnash ChangeLog server/asobj/Key.cpp server/mov...


From: zou lunkai
Subject: Re: [Gnash-commit] gnash ChangeLog server/asobj/Key.cpp server/mov...
Date: Mon, 16 Jul 2007 17:21:47 +0800

On 7/10/07, strk <address@hidden> wrote:
On Tue, Jul 10, 2007 at 12:22:34PM +0000, Zou Lunkai wrote:

> +     std::vector<KeyListener> & listeners = _vm.getRoot().getKeyListeners();

Zou, just a minor thing.
I was using a std::set in the old design.
std::set is an ordered container, using a binary tree for seeks.
This helps by making the removeListener() faster.
In general try always using typedefs for the containers. I think
I already provided a KeyListeners typedef in this case.
Using a typedef helps changing the underlying container without
requiring a lot of changes around.
In the KeyListener class case, the std::set should be defined with
a custom comparator, using the wrapped intrusive_ptr for comparison.


I followed your suggestion and did some code cleanups today, but found
difficulties with using std::set.

Background:
(1)KeyListener  is defined in movie_root.h;
(2)To simplify the question,  KeyListener class is just something like this:
KeyListener {
  boost::intrusive_ptr<as_object>  _listener;
  int  flag;
  bool operator < ();  // custom comparator,  compares different  _listeners,
                                   // using the wrapped intrusive_ptr
for comparison.
}
(3) why should I use std::set as a container, see the above quote from strk:)


The problem is the std::set container just support read-only
structure,  then the following code cann't even compile :

std::set<KeyListener >  listeners;
std::set<KeyListener > ::iterator it = listeners.begin();
it ->flag = 0;  // error, gcc does't compiler this,  KeyListener is
supposed to be read-only.
                     // but vc8 compiles well and works without a warning

I think you have seen the problem now, I can not modify anything of an
object stored in a std::set container, even it is not the key. Of
course, the comiler does not know what is the key.

Before asking the question, I'v done some test. Testing results show
that vc8 seems more tolerant on this.  And there are some links
discussing about the related problem.

http://gcc.gnu.org/ml/gcc/2001-07/msg01260.html
http://www.velocityreviews.com/forums/t287950-which-type-should-quotstdsetbegin-constquot-return.html

any comments and help?

zou




reply via email to

[Prev in Thread] Current Thread [Next in Thread]