Ioannis,
> > Had you read "Effective STL," this has't been your answer.
>
>
> :-)
Sorry, but I can't view these cute faces because my mail server
provides text only.
> > Sometimes,
> > there are policies such as willing to have a constant-time operation
> > on the map that have higher proiority for the implementer (for any
> > reason they know). And achieving that runtime needs you to cut down
> > the use of size update after any operation of the map.
>
>
> Not any operation, size() has to be updated during insert() or erase() only.
>
> Also bool empty() const { return size()==0; } takes constant time.
Hmmm.... The only operation you have neglected is operator[]. But there
is another fine point. That is, when you are going to insert or erase
only one element, it is extremely easy to update size, but when dealing
with range counterparts, the story is not that easy.
> > I think the existance of nasty C++ implementations such as VC++6,
> > reveals that this is not just a fiction, and there even are wellknown
> > implementations who may have chosen that way.
>
>
> Anyway we are talking without any basis here, ...
Maybe! I don't have any problem if you don't want to continue it.
> ... the implementor can choose
> whatever method he likes to implement size() but if he calculated size()
> everytime it was called (or only the first time if no other change has been
> made) would be unwise since our code would wait for the internal loop of our
> thousands record counting to complete.
>
> In any case one would expect that the perofmrmance of size() in a if()
> statement wouldn't take 10 seconds. TC++PL provides the above check as a
> reasonable implementation I agree with it.
There may be some trade-off as I told. Anyway...
> > You'r right. But max-performance of what? I mean, if there is an
> > operation, say O, that has higher priority from your point of view (as
> > the implementer, or disigner, etc.), and you want O to be done in a
> > constant time, and that forces you to forget updating size after O,
> > will you still think that max-performance obliges you to have size as
> > an internal member?
>
>
> There is not any Big-Oh requirement of the standard both regarding size() or
> empty(). In theory empty() could be slower than size() (since there is not
> any kind of restriction), but I said let's try to be realists.
Theoritically, yes.
> I used VC++ 6 only to what it is best for. To learn C90. :-) Regarding ISO
> C++ it is crap. VC++ .NET 2002/2003 on the other hand are very good
> regarding C++ compliance.
I haven't still heard anything opposing that. But it takes time to see
what botchs it has, if any. (Generally, nothing in Software-houses such
as Microsoft is reliable.) So far, I agree with you.
> > I have just
> > realised that the compiler we were talking about was GCC, and I
> > hartapologise for the suspection I have had to his majesty. But
> > remember that I didn't know that's GCC. Knowing that, don't you still
> > preserve me the right of suspecting the implementation?
>
>
> Well I would start suspecting if the code was crawling.
Right!
> Does VC++ 6 crawl whem map::size() is used?
I'm not sure in this specific case, but I have encountered several
similar situations. Please don't ask me to enumerated them, because I
haven't documented them. But you can make search on interenet.
Wishes,
--Hossein
--
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup
CareerBuilder.com has over 400,000 jobs. Be smarter about your job search
http://corp.mail.com/careers
|
