Должен ли я сделать свой собственный каркас? - PullRequest
1 голос
/ 23 января 2009

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

// In my framework:
namespace MyFX { 
    typedef std::string String;
};

// Port specific (MFC in this case)
CString ToCString(const MyFx::String &str) { /* magic */ }

// Port specific (.NET specific)
System::String^ ToManagedString(const MyFx::String &str) { /* magic */ }

Я слишком много изобретаю колесо?

Я бы использовал MyFx :: String в интерфейсах пользовательского интерфейса между пользовательским интерфейсом и другими уровнями.

Ответы [ 6 ]

6 голосов
/ 23 января 2009

Мне кажется, что в этом нет большой пользы; по моему опыту, точка использования этих платформ заключается в том, что вы не будете изобретать велосипед заново. Если вы обнаружите, что вам нужно написать новый класс строки или новый векторный класс, вы должны серьезно задуматься об этом и убедиться, что вы не просто делаете что-то другое неправильно. Я не говорю, что нет причин писать свой собственный класс строк, я просто говорю, что это редко. Учитывая это, я бы предложил просто использовать нужные фреймворки напрямую.

Что касается функций преобразования, я полагаю, что компилятор не увидит вашу функцию ToCString иначе, чем это выглядело бы:

CString ToCString( const std::string & ) {...}

Это потому, что определение типа C ++ не создает новый тип, а только псевдоним существующего типа.

Дальнейшие мысли

Я думаю, что беспокойство, которое вы озвучиваете здесь, является очень естественным, и я знаю, что оно возникало в моей команде несколько раз. Тем не менее, я думаю, что ответ по-прежнему, как указано выше.

Хотя классы STL, вероятно, не идеальны, они были разработаны очень умными людьми, которые много думали об этой задаче. Таким образом, шансы на то, что вам понадобится написать полный класс строки замены, очень малы. Более того, без малейшего намерения вам (или мне) понадобится очень много времени, чтобы реализовать надежный универсальный класс строк, который мог бы подходящим образом заменить std :: string.

Другой возможный способ подумать об этом - это: вы бы подумали «заменить» класс String в Java или C #? Я думаю, что ответ здесь явно «нет», хотя иногда могут быть ограниченные области, где вы используете что-то кроме String для представления последовательности символов. То же самое и здесь: std :: string настолько близко, насколько C ++ достигает встроенного строкового класса, и вам почти наверняка не нужно его заменять.

5 голосов
/ 23 января 2009

"Я слишком много изобретаю колесо?" - да. Не делай этого.

3 голосов
/ 23 января 2009

Должен ли я сделать свой собственный каркас?

Э-э ... нет.

Я бы не стал беспокоиться о замене std :: vector, пока в этом нет необходимости, потому что YAGNI .

2 голосов
/ 23 января 2009

«это зависит» - если вы считаете, что в будущем вы можете перейти на какую-то другую библиотеку / библиотеки (например, из-за переноса на другие платформы), то создайте структуру, соответствующую вашим потребностям, но это фасад, максимально тонкий и простой

это решение о соотношении времени и риска, которое может принять только вы

1 голос
/ 23 января 2009

См. Также: https://stackoverflow.com/questions/22795/when-to-notionally-build-your-own-compiler, и, возможно, более интересно, статья Джоэла, которая поставила вопрос: В защиту синдрома не изобретенного здесь .

Но короткий ответ: не без чертовски веской причины.

0 голосов
/ 02 марта 2009

Самым большим преимуществом будет опыт обучения, который вы получите.

...