Dependiendo de cuánto tiempo son las cadenas (y su compilador), es mejor que se quede con operator==
. En Visual C++ v10, eso se reduce a una llamada memcmp
a través de char_traits::compare
, que (cuando está optimizado) va a comparar los intervalos de bytes de destino en fragmentos, probablemente tantos bytes a la vez como caben en un registro (4/8 para 32/64 bits).
static int __CLRCALL_OR_CDECL compare(const _Elem *_First1, const _Elem *_First2,
size_t _Count)
{ // compare [_First1, _First1 + _Count) with [_First2, ...)
return (_CSTD memcmp(_First1, _First2, _Count));
}
Mientras tanto, std::equal
(la alternativa más bonito) hace un byte a byte de comparación. ¿Alguien sabe si esto se optimizará de la misma manera ya que son iteradores inversos? En el mejor de los casos, el manejo de la alineación es más complejo ya que el inicio del rango no está garantizado bien alineado.
template<class _InIt1,
class _InIt2> inline
bool _Equal(_InIt1 _First1, _InIt1 _Last1, _InIt2 _First2)
{ // compare [_First1, _Last1) to [First2, ...)
for (; _First1 != _Last1; ++_First1, ++_First2)
if (!(*_First1 == *_First2))
return (false);
return (true);
}
Véase la respuesta de @ greyfade here por algún color en GCC.
quizás un juego en esto sería usar string :: rfind en lugar de igual. – frankc
@frankc: No sé si el 'str1.rfind (str2) == 0' compararía hacia adelante o hacia atrás. Si primero verificamos que las cuerdas tengan la misma longitud, entonces solo hay una posición para verificar, así que vale la pena intentarlo. De hecho, técnicamente no sé si 'std :: equal' va hacia adelante o hacia atrás cuando se aplica a un iterador de acceso aleatorio, pero tengo una sospecha bastante fuerte ... –
no es la parte aleatoria del iterador, es el hecho de que 'rbegin'and' rend' return * reverse * iterators que confirma su sospecha! Gracias, estoy teniendo un momento de "Por qué no pensé en esto" ... – rubenvb