C++ определенные шаблоны из-за дизайна языка
Мне потребовалось долгое время, чтобы понять как важные и тонкие переменные наличия что:
1) существуйте на стеке
2) назовите их деструкторы, когда они упадут из объема
.
Эти две вещи позволяют вещи как:
A) RAII
B) GC refcounted
Достаточно интересный, (1) и (2) не доступны на "более низких" языках как C/Assembly; ни на "более высоких" языках как Ruby/Python/Java (так как GC предотвращает предсказуемое разрушение объектов).
Мне любопытно - что делают другие методы Вы знаете об этом, очень C++, конкретный, должный к проектным решениям языка.
Спасибо!
Править: Если Ваш ответ, "это работает в C++ и этом другом языке", это хорошо также. Вещи, о которых я хочу узнать, подобны:
Путем желания не иметь определенные функции (как GC), мы получаем другие функции (как RAII + предикабельное разрушение объектов). В том, каким областям C++, путем желания НЕ иметь функции, которые другие "высокоуровневые" языки имеют, C++, удается получить шаблоны, которые не могут выразить те высокоуровневые языки.
6 ответов
Я действительно люблю классы чертов. Не совсем специфичный C ++ (другие языки, как их Scala), но он позволяет адаптировать объекты, в основном указывать набор операций, которые должен поддерживать тип. Представьте, что вы хотите «Hasher», в смысле TR1 :: hash . Хеш определяется для некоторых типов, но не для других. Как вы можете сделать класс, который имеет хеш, определенный для всех типов, которые вы хотите? Вы можете объявить такое класс, как:
template < typename T>
struct hashing_tratis
{
typedef std::tr1::hash<T> hashing_type;
};
, то есть вы ожидаете, что класс, который имеет правильный, определенный для использования iSing_type. Тем не менее, хеш не определен, скажем, для myType , так что вы можете написать:
template <>
struct hashing_traits<myType>
{
typedef class_that_knows_how_to_hash_myType hashing_type;
};
таким образом, предположим, что вам нужен способ для хешащего типа, который вы используете в своей программе (в том числе mytype ). Вы можете написать «Универсальный» Hasher, создавая усаживание черты:
template <typename T>
struct something {
typename hashing_traits<T>::hashing_type hasher;
.... // here hasher is defined for all your relevant types, and knows how to hash them
Любопытно повторяющиеся шаблон
, вероятно, Весь мета-программированная концепция также
Ну, это можно сделать как на языке программирования D, так и на тех двух, о которых вы упомянули, но шаблоны, достаточно мощные, чтобы функционировать по существу, так как скомпилировать время набора уток довольно полезно. Мне часто кажется, что большая часть споров между статическим и динамическим языками может быть решена с помощью достаточно хорошей системы шаблонов, так что даже если типы должны быть решены статически во время компиляции, они не должны быть известны во время разработки. С++ был пионером этой идеи (по крайней мере, среди основных языков). D делает это на несколько шагов дальше.
С шаблонами и утиным типированием во время компиляции вы получаете лучшее из обоих миров: гибкость отсутствия необходимости указывать типы во время разработки функции или класса, а также безопасность и быстродействие их знания во время компиляции.
Немногие языки поддерживают множественную диспетчерскую (причем наиболее распространенной является двойная диспетчерская), как это делает C++, это можно делать статически или динамически.
С его помощью вы можете позволить инстанциям взаимодействовать друг с другом, не зная и не тестируя их конкретный тип.
Ну, почти все «конструктивные узоры» имеют сильный галстук к C ++. Вы должны предположить, что они не имеют ничего общего с «правильным дизайном» и «лучшими практиками» и все, что связано с Bizarre C ++, а тщательно рассмотрим реальную потребность в любых из них, а не бессмысленно осложнения вашего кода. Тем более, что многие из узоров дизайна являются BANDAIDS, чтобы исправить проблемы, созданные еще другими шаблонами дизайна. Это относится к десяти раз больше, чем при использовании любого языка, чем C ++, потому что C ++ имеет огромное количество проблем, ни один другой язык не делает.
Например, Singleton является наиболее очевидным примером этого. Настоящая причина этого - это способ, которым C ++ имеет очень плохо реализуемую статическую инициализацию. Без этого вы на самом деле должны знать, что вы делаете, чтобы правильно сделать инициализацию работать, и большинство людей действительно нет. Для большинства использующих дополнительный накладной расход Singleton в порядке, но его следует помнить, что у него есть накладные расходы, и он не использовал на большинстве языков. Это также создает дополнительные проблемы в каждой одной реализации, которую я видел.
То же самое относится к мосту шаблон, я вижу, используя Singletons, но просто нет причин, когда когда-либо использовать шаблон моста. Это сводится к «Вы знаете, что делаете?». Если это так, вам не нужен мостовой шаблон. Если нет, вы, вероятно, должны узнать больше, прежде чем пытаться решить проблему, побуждаю вас использовать мостов. Самое главное, на всех языках не очень полезно на языках, кроме C ++. Точка этого заключается в отделении осуществления и интерфейса, которая в более современных языках OO выполняется уже потому, что у них есть правильные модули некоторых видов. В C ++ лучше использовать чистые виртуальные интерфейсы для таких случаев (и не думают, что это ухудшает производительность, у него гораздо лучшая производительность, чем мостовая модель в сочетании с шаблонами).
Но это проблема с рисунками дизайна; Это не методология вообще, просто куча случайных вещей. Случайные вещи, которые большинство людей, пропагандирующих их, на самом деле не понимают, большинство из которых правильно не имеют никакого места, называемого ничто со словом дизайна в них. Они не являются инструментами дизайна, а специфические решения различных проблем. Многие из которых можно избежать.
Как ни странно, Java API полон мостов и широкого спектра других конструктивных узоров, которые полностью бессмыслены в Java. Java API прост в использовании большую часть времени, но преодоленная наследница может быть очень громоздкой для работы.
Всегда делают абонент, ответственную за распределение памяти / Dealocation, что означает, что Код, который будет выглядеть так в Java / C #:
MyClass DoSomething (MyClass averianstance);Похоже, в C / C ++:
Void DoSomething (MyClass * Concomebuffer, MyClass * Converinstance);- Используя деструкторы, чтобы закрыть розетки, файловые ручки и т. Д.