Farid Zaripov wrote:
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 08, 2007 2:36 AM
To: [email protected]
Subject: Re: [PATCH] Fix of STDCXX-268, STDCXX-331
Farid Zaripov wrote:
Attached is a proposed patch for fix the bugs STDCXX-268
and STDCXX-331.
If the bodies of the functions are the same wouldn't be
better to call one from the other rather than introducing the macro?
(The macro makes it impossible to step through the functions
in most debuggers. I know we have macros in there already but
we don't need to make things worse by adding more :)
I agree that it would be better.
Or are we invoking the macro with arguments of different
types each time (Iterator, pointer, const_pointer) because
we're working around the lack of member templates?
Yes. If _RWSTD_NO_INLINE_MEMBER_TEMPLATES macro
is defined then the range form of the method insert is present twice
with types const_pointer and const_iterator.
(We should discuss and decide if we want to keep these workarounds or
if
it's time to get rid of them and assume that the compiler is
reasonably modern).
I don't have the compiler without supporting the inline mebmer
templates.
We need to make the list of the compilers without supporting the inline
member
templates and then decide.
I don't know of any C++ compiler that's in widespread use
that doesn't support member templates. Even MSVC 6 handles
them (it just doesn't grok member templates defined outside
the body of the enclosing class).
So unless someone objects (I assume you're fine with it) I
propose we ditch the _RWSTD_NO_INLINE_MEMBER_TEMPLATES config
macro and all the workarounds for it. We should do a clean
sweep through the library to remove it rather than removing
it piecemeal.
We can either remove the macro first and then commit a cleaner
version of your patch w/o or we can do it the other way around.
Do you have a preference? (If the latter we should probably
open a Jira task as a reminder.)
Btw., I wonder if we could simplify (optimize) this code so
as to call erase(__start, __it) in the catch block instead of
looping (the idea is that the range form of erase() might be
more efficient than calling the single form repeatedly):
Yes, but to get __start we need use loop or std::advance, because
__start = __it - __n.
iterator __start = __it;
std::advance (__start, -n);
erase (__start, __it);
Another approach is to remember the iterator after first successful
insert (__it, *__first)
operation.
What do you prefer?
Definitely the latter. Looping would be expensive.
Martin
