C ++ - шаблон против иерархии классов на основе typedef - PullRequest
3 голосов
/ 26 января 2012

Я пишу библиотеку для эффективной обработки чисел. Я должен поддерживать разные типы номеров - double, complex или даже custom_matrix, может быть. По соображениям производительности я решил скомпилировать отдельный библиотечный файл для каждого вида чисел, чтобы компилятор мог использовать агрессивные оптимизации для арифметических операций и вызовов функций. Теперь у меня есть два варианта - либо написать шаблонные классы с параметром number_type, например,

template <typename valueType>
class Worker {
    valueType process(valueType value);
};

или typedef числовой вид в заголовочном файле для всего проекта, например,

in 'project.hpp':

namespace myProject {
    typedef double valueType;
}

in 'worker.hpp':

#include "project.hpp"

namespace myProject {
    class Worker {
        valueType process(valueType value);
    };
}

Лично я не могу согласиться с этим: код на основе шаблонов сводит меня с ума из-за множества избыточных ключевых слов template и typename, в то время как код на основе typedef не может быть скомпилирован в одном файле библиотеки (связывание не удается из-за повторяющихся имен), поэтому я не могу использовать разные типы номеров в одной программе.

Итак, вопрос: я что-то упустил? Есть ли лучший / более чистый способ выполнить мою задачу?

РЕДАКТИРОВАТЬ: я должен использовать double и complex код в одном приложении одновременно.

EDIT2: Хорошо, чтобы прояснить ситуацию: я разрабатываю движок арифметического выражения для приложения для iOS. Поэтому я ограничен C / C ++ / Objective-C, и производительность имеет решающее значение.

Кроме того, я чувствую себя комфортно при использовании шаблонов в обычных обстоятельствах. В моей ситуации все мои исходные файлы заполнены угловыми скобками и ключевыми словами template / typename. Это просто раздражает и отвлекает меня от написания важных вещей.

Полагаю, я буду использовать шаблоны, поскольку, насколько я вижу, лучшего решения не существует.

Ответы [ 3 ]

4 голосов
/ 26 января 2012

C ++ люди скажут вам использовать template, не спрашивая, как ваш код на самом деле будет использоваться.

Ключевой вопрос здесь: будет ли ваша библиотека когда-либо использоваться с двумя разными типами чисел одновременно ?

Если ответ «нет», то шаблоны будут ужасным выбором. Как вам хорошо известно, с шаблонами нелегко работать: они создают больше работы для вас, больше работы для компилятора и больше работы для IDE (которая пытается проанализировать их, чтобы обеспечить автозаполнение).

Просто используйте глобальный typedef. В долгосрочной перспективе вы избавите себя от многих головных болей. Кстати, это именно то, что делает библиотека физики Bullet .

2 голосов
/ 26 января 2012

Вы должны использовать шаблоны. Если вы настаиваете на том, чтобы выполнять абсолютный максимальный объем работы во время компиляции, а не во время выполнения, и ваш язык выбора - C ++, вы будете использовать шаблонное программирование.

Это беспорядок знаков «меньше» и «больше, чем», запутанные сообщения об ошибках и typename ключевые слова (плюс не начинайте меня с явных примеров, когда вы не хотите определять весь класс в заголовке !), но у нас беспорядок.

РЕДАКТИРОВАТЬ: существует третий вариант, в форме предварительной обработки - вы можете дважды запустить один и тот же код через препроцессор, каждый раз помещая символы в другое пространство имен, чтобы получить тот же эффект, что и версия typedef без символ столкновения.

1 голос
/ 26 января 2012

Там действительно нет лучшего способа.Поэтому, если вам нужно использовать более одного типа в любой заданной программе templates, это, в основном, путь.Если вы уверены, что этого никогда не произойдет, продолжайте с typedefs, так как в этом случае их будет достаточно, и их будет легче читать / отлаживать.

Конечно, если вы пишете шаблоны достаточно долго, они могут стать вполне естественными вплоть до того момента, когда вы их используете, даже если они не являются строго необходимыми (так как в этом случае были бы другие разумные способы решения данной проблемы),По крайней мере, это то, что случилось со мной

...