Специализация шаблонного метода

[Old]

Нет, не надо ля-ля.

Смотрите кому я отвечаю.

Стандарт - это документ. Страниц на семьсот. В последнем принятом c++14 нет ни слова о частичной специализации шаблонных функций.

Да хоть на 100500.
Даже если эти слова появяться, то они будут просто словами, пока это не реализуют в компиляторах и наоборот.
И в нашем случае нет частичной специализации шаблонных функций, а есть перегрузка.

[kramer]

Смотрите кому я отвечаю.

Оба-на, прошу прощения, недосмотрел.

И в нашем случае нет частичной специализации шаблонных функций, а есть перегрузка.

Есть. В нашем случае (т.е. в вашем коде) там есть и то и другое. Потому как переменное число шаблонных параметров у оператора сравнения. Это и есть частичная специализация, по определению. Полная - это template<>.

[Old]

Есть. В нашем случае (т.е. в вашем коде) там есть и то и другое. Потому как переменное число шаблонных параметров у оператора сравнения. Это и есть частичная специализация, по определению. Полная - это template<>.

Это две совершенно разных функции с совершенно разными параметрами, не нужно проводить параллели с классами, их там по стандарту нет.

Спорить надоело, поэтому еще раз вернусь к разработчикам компиляторов: они все как один не считают это расширением. Если это не расширение, то это стандарт, если это стандарт, то это не частичная специализация.

[Racheengel]

О, сколько нафлудили
Спасибо всем откликнувшимся за пред ложенные решения
Проблему в итоге решили в классе наследнике от TVector, который его специализировал.
И да, тупая древняя 2008 студия много чего не так понимает...

Что касается стандарта - считаю его во многих случаях уделом теоретиков. Реальный код все равно в итоге собирается конкретными компиляторами, и нам намного важнее то, как ту или иную вещь понимает отдельно взятый компиль и какой код генерирует по факту.  А стандарт имхо сродни такому себе Hoch Deutsch - немецкий язык вроде как один, стандартный, да только в каждой земле все равно говорят по своему

[kramer]

И да, тупая древняя 2008 студия много чего не так понимает...

Ох. Товарищ по несчастью. Сочувствую. Я с нее на 2012 только недавно перелез.

А стандарт имхо сродни такому себе Hoch Deutsch - немецкий язык вроде как один, стандартный, да только в каждой земле все равно говорят по своему

Вот-вот. Поэтому, если вы хотите, чтобы вас поняли в любой земле, вы говорите на hochdeutsch, его вроде как в школе учат. Вы, помнится, что-то про переносимость говорили.

[Old]

Вы, помнится, что-то про переносимость говорили.

Вот об это и речь. Стандарт есть, а переносимости все так и нет.

[Racheengel]

Ох. Товарищ по несчастью. Сочувствую. Я с нее на 2012 только недавно перелез.

Да сама то по себе 2008 студия как ИДЕ нормальная, мы ее для кодописания только и юзаем. Пробовали ИДЕ от 2013 - оказалось еще тем оцтоем. Реально используем компилятор от 2013 (а собираем через Qt креатор, т.к. проекты от 2008 студии она толком не может сконвертировать). Компиль классный в плане производительности - 20-25% прироста дает только так. Но есть и старые машины (у заказчиков), которым приходится собирать в 2008

Плюс под линухи у нас GCC и CLang, а это еще те ребята Студия по сравнению с ними еще более-менее толерантна к коду.

Вот-вот. Поэтому, если вы хотите, чтобы вас поняли в любой земле, вы говорите на hochdeutsch, его вроде как в школе учат. Вы, помнится, что-то про переносимость говорили.

Проблема только в том, что производители компиляторов трактуют стандарт по своему, так что переносимости как раз не получается

[kramer]

Проблема только в том, что производители компиляторов трактуют стандарт по своему, так что переносимости как раз не получается

Вот об это и речь. Стандарт есть, а переносимости все так и нет.

Есть она, есть. Не стопроцентная, конечно, от некоторых ифдефов никуда не денешься. Но если вы не буст пишете, то вполне можно свести их количество к минимуму. Лично мне правило "если этого нет в стандарте, вероятны грабли с переносимостью" сэкономило немало крови. Просто потому, что если что-то есть в стандарте, вероятность того, что оно будет работать одинаково на разных платформах несколько выше, чем если этого в стандарте нет. Истина выстраданная

[Igors]

Ну распрекрасно, тогда для способа с ветвлениями в коде - как-то так:
...
Работать будет, но расширяемость никакая, если потребуется для какого-то из классов элементов переопределить логику оператора сравнения контейнера, то придется все эти else-if перелопачивать.

Да, походу придется что-то такое и сделать, наверное. Выглядит, конечно, кривенько, но хотя бы ревью пройдет)

А чего это мы "носик воротим"? Полагаю что главное (если вообще не единственное) соображение типа "ну это слишком просто, незатейливо" - и только Ну какие "перелопачивания", откуда они возьмутся? Совать сюда сравнение объектов никто не собирался, они должны иметь оператор ==. А остальное ложится прекрасно

А вообще использование fuzzy в операторе == считаю неудачной идеей. Это "implicit" действие, за которое придется расплачиваться. Напр 2 контейнера float оказались равны. Но их double копии - уже НЕ равны. Лучше сделать fuzzy сравнение явным (explicit) добавив метод CompareFuzzy. Или, если этот класс в недрах др темплейтов, сделать специализацию всего класса <> и подчеркнуть это Fuzzy в его имени.