Внутренние определения типов в C++ - хороший стиль или плохой стиль?
Я копирую / вставляю ваш шорткод, и эта строка работает как задумано:
return $album_id = $attr['album'];
Возвращает переданный параметр альбома. Если вы хотите, вы можете использовать extract , чтобы получить идентификатор непосредственно как $ album:
extract(shortcode_atts(
array(
'album' => 1,
)
, $attr));
теперь это выглядит довольно неправильно:
<script src="http://linklink.net/cpg/api-posts.php"></script>
is для JavaScript это не имеет ничего общего с php. просто включите оператор sql и выведите его прямо в шорткод. изменил способ возврата данных (ob_start / get_clean). также, как упоминал Дхарман, проверьте, как безопасно выполнять SQL-операторы.
function cpg_shortcode($attr) {
extract(shortcode_atts(
array(
'album' => 1,
)
, $attr));
ob_start();
$query = mysql_query("SELECT * FROM `cpgq7_pictures` WHERE aid=$album ORDER BY ctime DESC LIMIT 0 , 3");
if (mysql_num_rows($query) == 0) {
echo 'No hay fotos';
} else {
echo '<h6>';
while ($row = mysql_fetch_array($query)) {
$domain = "http://linklink.net/cpg";
$album_url = "$domain/thumbnails.php?album=$album#content";
$album_img = "$domain/albums/" . $row['filepath'] . 'thumb_' . $row['filename'];
echo '<a href="' . $album_url . '" target="_blank"><img src="' . $album_img . '" alt="" /></a>';
}
echo '<a href="' . $album_url . '" target="_blank"><img src="https://i.imgur.com/4wmomUt.png" alt="" /></a></h6>';
}
return ob_get_clean();
}
add_shortcode('cpg', 'cpg_shortcode');
8 ответов
Я думаю, что это отличный стиль, и я использую его сам. Всегда лучше максимально ограничить область имен, и использование классов - лучший способ сделать это в C ++. Например, стандартная библиотека C ++ интенсивно использует typedefs внутри классов.
Еще один голос за то, что это хорошая идея. Я начал это делать при написании симуляции, которая должна была быть эффективной как во времени, так и в пространстве. Все типы значений имеют Ptr typedef, который начинался как общий указатель boost. Затем я провел некоторое профилирование и изменил некоторые из них на интрузивный указатель без необходимости изменения кода, в котором использовались эти объекты.
Обратите внимание, что это работает только тогда, когда вы знаете, где будут использоваться классы, и что все виды применения имеют одинаковые требования. Я бы не использовал это в библиотечном коде, например, потому что вы не можете знать при написании библиотеки контекст, в котором она будет использоваться.
Typedefs - это то, что основанный на политике дизайн и черты построены на C ++, так что Power Общего программирования на C ++ происходит от самих typedef.
Typdefs are definitely are good style. And all your "reasons I like" are good and correct.
About problems you have with that. Well, forward declaration is not a holy grail. You can simply design your code to avoid multi level dependencies.
You can move typedef outside the class but Class::ptr is so much prettier then ClassPtr that I don't do this. It is like with namespaces as for me - things stay connected within the scope.
Sometimes I did
Trait<Loren>::ptr
Trait<Loren>::collection
Trait<Loren>::map
And it can be default for all domain classes and with some specialization for certain ones.
STL постоянно делает подобные вещи - определения типов являются частью интерфейса для многих классов в STL. .
reference
iterator
size_type
value_type
etc...
- это все определения типов, которые являются частью интерфейса для различных шаблонных классов STL.
Я рекомендую переместить эти typedefs за пределы класс. Таким образом, вы удаляете прямую зависимость от общего указателя и векторных классов и можете включать их только при необходимости. Если вы не используете эти типы в своей реализации класса, я считаю, что они не должны быть внутренними определениями типов.
Причины, которые вам нравятся, все еще совпадают,
Когда typedef используется только внутри самого класса (то есть объявляется как private), я думаю, это хорошая идея. Однако именно по указанным вами причинам я бы не стал использовать его, если typedef нужно знать за пределами класса. В этом случае я рекомендую вывести их за пределы класса.
Он служит в качестве заявления о намерениях - в приведённом выше примере, класс Лорема предназначено для подсчёта ссылок с помощью boost::shared_ptr и хранится в vector.
Это именно то, что делает а не.
Если я вижу в коде 'Foo::Ptr', то понятия не имею, является ли это shared_ptr или Foo* (в STL есть ::pointer typedefs, которые являются T*, помните) или что-то в этом роде. Esp. если это общий указатель, то я вообще не предоставляю typedef, но сохраняю явное использование shared_ptr в коде.
На самом деле, я почти никогда не использую typedefs за пределами метапрограммирования шаблонов.
STL постоянно делает подобные вещи
Дизайн STL с концепциями, определенными в терминах членских функций и вложенных typedefs - это исторический тупик, современные библиотеки шаблонов используют свободные функции и классы признаков (ср. Boost.Graph), так как они не исключают из моделирования концепции встроенные типы, а также потому, что это облегчает адаптацию типов, которые не были спроектированы с учетом концепций данных библиотек шаблонов.
Не используйте STL как повод для совершения тех же ошибок.
.