Почему использование кортежей в C ++ не более распространено?
Проблема здесь заключается не в высоте строки, а в вертикальном размещении глифов, в частности в местоположении базовой линии текста. Это то, что решил дизайнер шрифтов; дизайнер рисует глифы и помещает их в квадрат em, концептуальное устройство, которое имеет высоту, равную (или определенную) высоту шрифта. В частности, дизайнер решает, сколько места находится ниже базовой линии, с одной стороны, и выше высоты заглавных букв, с другой. Обычно эти пространства равны или почти равны, но они не обязательно должны быть. Если они существенно отличаются, предполагаемое использование шрифта, вероятно, является особенным и не включает использование, как показано на изображении. Это предполагает, что выбор шрифта должен быть пересмотрен, но предположим, что он исправлен.
Существует несколько способов решения проблемы. Если над буквами слишком много места, уменьшение line-height делает его меньше, но оно также влияет на пространство выше. Верхнее дополнение помогает в определенном смысле, но увеличивает общую высоту, занимаемую элементом. Вы также можете играть с vertical-align, но это влияет на высоту строк.
Вероятно, самый простой подход - использовать относительное позиционирование, предполагая, что проблема связана с текстом с одним слоем. Относительное позиционирование просто перемещает контент определенным образом, не влияя на расположение в противном случае. Для этого вам понадобится оболочка, то есть элемент, содержащий текст, так что вы можете просто заменить текст, а не фон.
В следующей демонстрации используется шрифт Google, Candal, который имеет аналогичную проблема, но в другом направлении: базовая линия слишком низкая. Модификации этого подхода для удовлетворения исходной проблемы должны быть очевидными, но точное количество перемещения необходимо определить эмпирически (или из информации, извлеченной из файла шрифта с помощью инспектора шрифтов). Естественно, здесь нужно использовать блок em, даже если вы задаете размер шрифта в пикселях или точках (так что код не нужно менять, если размер шрифта изменится однажды).
<link href='http://fonts.googleapis.com/css?family=Candal' rel='stylesheet'>
<style>
div { font-family: Candal }
div { background: lightgreen; font-size: 200%}
</style>
<p>What we have got initially:
<div>BRAKE HOSE AND AIR CHAMBER</div>
<p>Reducing line height (even “setting solid”) does not really help:
<div style="line-height: 1">BRAKE HOSE AND AIR CHAMBER</div>
<p>But displacing the text upwards by 0.1em does:
<div><span style="position: relative; bottom: 0.1em">
BRAKE HOSE AND AIR CHAMBER</span></div>9 ответов
Потому что это еще не стандарт. Все, что нестандартно, имеет гораздо более высокие препятствия. Pieces of Boost стали популярными, потому что программисты требовали их. (на ум приходит hash_map). Но хотя кортеж удобен, это не такая уж очевидная победа, чтобы люди беспокоились о нем.
Циничный ответ состоит в том, что многие люди программируют на C ++, но не понимают и / или не используют функциональность более высокого уровня. Иногда это происходит потому, что они не разрешены, но многие просто не пытаются (или даже не понимают).
В качестве примера без повышения: сколько людей используют функции, найденные в ?
] Другими словами, многие программисты на C ++ - просто программисты на C, использующие компиляторы C ++ и, возможно, std :: vector и std :: list . Это одна из причин, почему использование boost :: tuple не является более распространенным.
Синтаксис кортежа C ++ может быть более подробным, чем хотелось бы большинству людей.
Примите во внимание:
typedef boost::tuple<MyClass1,MyClass2,MyClass3> MyTuple;
Итак, если вы хотите широко использовать кортежи, вы либо получите определения типов кортежей повсюду, либо повсюду получите досадно длинные имена типов. Мне нравятся кортежи. Использую при необходимости. Но обычно это ограничивается парой ситуаций, таких как N-элементный индекс или при использовании мультиотображений для связывания пар итераторов диапазона. И это обычно в очень ограниченном объеме.
Это все очень уродливо и взломано по сравнению с чем-то вроде Haskell или Python. Когда здесь появится C ++ 0x и мы получим ключевое слово auto, кортежи станут выглядеть намного привлекательнее
. Полезность кортежей обратно пропорциональна количеству нажатий клавиш, необходимых для их объявления, упаковки и распаковки.
Для меня это привычка, руки вниз: кортежи не решают для меня никаких новых проблем, просто с некоторыми я уже могу справиться отлично. Менять местами значения по-прежнему проще по старинке - и, что более важно, я действительно не думаю о том, как поменять местами «лучше». Это достаточно хорошо как есть.
Лично я не думаю, что кортежи - отличное решение для возврата нескольких значений - звучит как работа для struct s.
При использовании C ++ во встроенных системах извлечение библиотек Boost становится сложным. Они соединяются друг с другом, поэтому размер библиотеки растет. Вы возвращаете структуры данных или используете передачу параметров вместо кортежей. При возврате кортежей в Python структура данных находится в порядке и типе возвращаемых значений, это просто неявно.
Но что, если вы хотите повернуть три значения?
swap(a,b);
swap(b,c); // I knew those permutation theory lectures would come in handy.
Итак, с 4 и т. Д. Значениями в конечном итоге n-кортеж станет меньше кода, чем n-1 перестановки. А со свопом по умолчанию это 6 назначений вместо 4, которые были бы, если бы вы сами реализовали трехцикловый шаблон, хотя я надеюсь, что компилятор решит это для простых типов.
Вы можете придумать сценарии, в которых свопы громоздки или неуместны, например:
tie(a,b,c) = make_tuple(b*c,a*c,a*b);
немного неудобно распаковывать.
Дело в том, что существуют известные способы решения наиболее распространенных ситуаций, для которых подходят кортежи, и, следовательно, нет особой срочности брать кортежи. По крайней мере, я не уверен, что:
tie(a,b,c) = make_tuple(b,c,a);
не делает 6 копий, что делает его совершенно непригодным для некоторых типов (наиболее очевидными являются коллекции). Не стесняйтесь убедить меня, что кортежи - хорошая идея для " и не хотят поощрять их использование, делая их проще. Некоторые люди просто предпочитают именованные структуры для входных и выходных параметров, и, вероятно, их невозможно убедить с помощью бейсбольной биты использовать кортежи. О вкусах не спорят.
и не хотят поощрять их использование, делая их проще. Некоторые люди просто предпочитают именованные структуры для входных и выходных параметров, и, вероятно, их невозможно убедить с помощью бейсбольной биты использовать кортежи. О вкусах не спорят.Не все могут использовать boost, а TR1 не пока еще не получил широкого распространения.
Конечно, кортежи могут быть полезны, но, как уже упоминалось, есть небольшие накладные расходы и пара препятствий, которые вам нужно преодолеть, прежде чем вы сможете их использовать.
Если ваша программа постоянно находит В местах, где вам нужно вернуть несколько значений или поменять местами несколько значений, возможно, стоит пойти по пути кортежей, но в противном случае проще сделать что-то классическим способом.
В общем, не у всех уже установлен Boost, и я, конечно, не стал бы загружать его и настраивать свои включаемые каталоги для работы с ним только для его кортежей. Я думаю, вы обнаружите, что люди, уже использующие Boost, с большей вероятностью найдут использование кортежей в своих программах, чем пользователи, не использующие Boost,
У меня такое ощущение, что многие используют Boost.Any и Boost.Variant (с некоторой инженерией) вместо Boost.Tuple.