Pull to refresh
24
0.1
Send message
Я о другом. Смысл искажается. Хотя конечно дело ваше.
Но хотя бы вставить пояснение того, что на самом деле означает слово "персональная" в этом контексте. А то ведь смысл этого слова в русском языке совсем не сочетается с тем, что имелось в виду в английском варианте.
По поводу "персональной функции".

Приведу цитату из LLVM manual:

Because different programming languages have different behaviors when handling exceptions, the exception handling ABI provides a mechanism for supplying personalities. An exception handling personality is defined by way of a personality function (e.g. __gxx_personality_v0 in C++), which receives the context of the exception, an exception structure containing the exception object type and value, and a reference to the exception table for the current function. The personality function for the current compile unit is specified in a common exception frame.

Исходя из этой цитаты, на мой взгляд, personality function не может переводиться как "персональная функция", а скорее как "функция, отражающая особенности [конкретного механизма исключений]". Но данный перевод теряет лаконичность оригинальной фразы. Поэтому возможно лучше оставить это словосочетание без перевода (например со сноской на детальное объяснение того, что это значит), так же, как вы поступили с landing pads.
Ну не без этого, но это не главная причина.
У нас много legacy, при чем это касается не только софта, но и всяких бюрократических моментов.
Спасибо, прикрепил файлики.
Не совсем. Но версия компилятора у нас приколочена очень крепко (самый новый из доступных — GCC 4.1.3).
Спасибо — это очень интересно.
Может быть стоит добавить эту информацию в багрепорт?
Спасибо за отзыв.
К сожалению, в моем случае перспектива перехода на С++11 на работе кажется фантастической :)
Я цитировал черновик С++14, но видимо немного более старый, чем сейчас есть на сайте.
Но, видимо, изменения откатили обратно (и это прошло мимо меня). Вот, например, патч для gcc по поводу этого.
Признаю свою вину, что не сверился с последним черновиком.
Вы были правы.
Простите, но мое чувство справедливости не дает проигнорировать этот момент.
Тут речь, вообще-то, о плюсах, в которых нет VLA.

Дело в том, что уже есть, правда называются они не VLA (см. цитаты). Тот же параграф, что вы цитировали выше, в новом стандарте претерпел изменения:
In a declaration T D where D has the form
D1 [ expressionopt] attribute-specifier-seqopt

и ниже:
If the expression, after converting to std::size_t, is a core constant expression whose value is N, the
type of the identifier of D is “derived-declarator-type-list array of N T”.
Otherwise, the type of the identifier of D is “derived-declarator-type-list array of runtime bound of T” and
the value of the expression designates the number of elements N in the array.

Короче говоря неконстанту в размере массива писать теперь официально можно и это не ошибка.
Я к чему говорю: мой ответ касался вашего замечания, что переменная плохо ищется потому, что у нее короткое имя — логично было предположить, что вы не знаете про grep, и/или регулярки.

Но контекст-то нужно учитывать. Я сперва озвучил цифры не просто так. В контексте, который я описывал, именно короткое имя является причиной «плохого поиска» и именно поэтому, чтобы смочь составить регулярку, нужно знать достаточно о вариантах применения, дабы отразить это в выражении. Если варианты неизвестны, то поиск сильно затрудняется.
Вы должно быть забыли поставить запятую, т.к. из того, что имя короткое совсем не следует, что оно плохо ищется :) Например вот вам команда с регуляркой «навскидку», которую я бы на вашем месте использовал «grep -rnIE "\bL\b[^\"]*"» — скипает бинарные файлы и «широкие» строки, выводит только строки с их номерами в файле, где используется одинокая большая Эл.

Допустим мы представим, что я не знаю про регулярки (только допустим). Допустим, что я не умею пользоваться grep (только допустим). Теперь допустим я решил попробовать поискать таким образом у себя и получил лог в полтора миллиона строк (и это я еще обрезал поиск только по h, c и cpp). «Плохо ищется» означало, я не получу обозримый лог поиска. Я получу портянку на пару недель изучения :) Во-вторых, если к твоей регулярке добавить еще поиск вхождения по «define», то становится гораздо проще. Но это ведь нужно знать, что там надо писать define, компилятор об это не говорит. Хорошо, допустим я знаю про это (я знал, выше писал, сработал паттерн), но я все равно не нашел подобным образом ничерта. Потому что искал по коду комплекса, где у меня развалилась сборка, а макрос этот злосчастный был во внешних зависимостях.
ну выдаст компилер ошибку, переименовать переменную не так трудно ведь?

При всем уважении, но «должны» это не про реальные проекты. Бывает всякое, я как-то боролся с проблемой, потому что некто определил макрос L. Было несколько переменных внутри структур с таким же названием, кроме того, — это лексема для указания «широких» строк. Размер проекта примерно 700мб исходного кода. Причем раньше это работало (много лет), но стало разваливаться при обновлении версии компилятора. По-другому включилась последовательность h-ников и все, приехали. Найти это при таких объемах было чрезвычайно сложно, во-первых потому, что имя короткое и оно плохо ищется. Во-вторых ошибка вовсе не указывала на проблемное место, а всплывала за много «километров» от него, с совершенно невразумительной диагностикой. Если бы у меня на тот момент уже не выработался паттерн: «видишь непонятную хрень — виноваты макросы», я бы потратил еще больше времени.
Так что, при всем уважении, ваши рассуждении просто говорят о том, что вы никогда не имели дел с legacy такого объема.
Это же не сегфолт в рантайме, исправить легко.

Сегфолты, к слову, обычно проще исправить, чем такое.
Это не баг, а legacy из С. Массив в С и С++ не объект первого класса, точно так же как и функция.
Понимаю, что некропост, но мне очень интересно.
Я вообще то думал, что Вы вспомните libaio — и уже собирался понасмехаться, но не судьба :-)

А можно не насмехаться, а нормально рассказать в чем проявляются его недостатки и почему такое критическое мнение насчет этого?
Спрашиваю совершенно серьезно.
А зачем вам миниатюрность и низкое энергопотребление для теплицы и соленоидных вентилей? Там же и места должно быть полно и электричество будет. Всяко соленоиды будут жрать больше центральной микросхемы

Ну там далеко не теплица — обычный участок.
Электричество есть, но может и пропасть (такое бывает). Если не будет электричества не будет и воды (смысл держать вентили автономными отпадает), так что питать автономно надо только сам компьютер — для того, чтобы сообщить о перебоях в питании (тоже по СМС). Тогда нужно будет придти и полить вручную.
Насчет миниатюрности, все просто: мелкое проще спрятать. Не нужно будет искать большой погодозащищенный корпус, а потом думать куда его деть, чтобы никто не спер. Вообще конечно миниатюрность не главный критерий, но она была бы плюсом.

В-главных, слишком мелкая, даже дырочки «половинного» шага, надо будет паять проводочки.

Это не проблема. Во-первых у меня есть штырьковые разъемы для такого шага. Во-вторых ничего страшного, если придется паять.

Во-вторых, не видно 1-wire, I2C и прочих протоколов, не понятно есть ли аналоговые входы (входы с АЦП). Термометры на 1-wire очень популярны.

Это все не нужно. Нужно только замыкать и размыкать цепь. GPIO с этим справится вполне. Единственное что нужно будет дополнительно — это датчик напора воды.
Давно вынашиваю идею сделать автоматизированную систему полива в оранжерее и на дачном участке, с удаленным управлением по СМС и собственным автоматическим расписанием (которое можно было бы редактировать через веб-интерфейс). Учитывая малые размеры, достаточную производительность, наличие GPIO (для управления соленоидными вентилями) и похоже достаточно низкое энергопотребление, данный девайс как раз подошел бы в качестве мозга всей системы. Вообще именно отсутствие приемлемого вычислителя для этой задачи и останавливало. А тут, стало быть, такой хороший, на мой взгляд, вариант.
только один раз при первом вхождении

Он говорил про разные translation unit, а не про множественные включения в один.
Visual Studio не поддерживает

Поправлюсь, не поддерживала до версии 2012, насколько я могу судить. Однако все еще работает не корректно в некоторых случаях.
Например в таком
template<typename T>
struct Base
{
    template<typename U>
    struct InnerBase
    {};
};
template<typename T, typename U>
struct Derived : public Base<T>
{
    struct InnerDerived : public Base<T>::template InnerBase<U>
    {};
};

int main()
{
    Derived<int, int>::InnerDerived foo;
}

Сорри за оффтоп :)
Я не спорю с тем, что диагностика в С++ может проигрывать другим языкам. Однако это
всё, что связано с аргументами шаблона, проверяется только на второй фазе

не совсем так. Скажем, частично проверка аргументов производится при специализации, и в некоторых других случаях.
template <typename T1, typename T2>
struct A
{
};
template <typename T1>
struct A<T1, 2>
{
};

Ну да ладно, собственно это не важно. Rust хороший язык, надеюсь найдется время познакомиться с ним поближе.
Шаблоны в Rust проверяются на корректность до их инстанцирования...

В С++ тоже. Это называется two-phase name lookup. Не смотря на то, что Visual Studio не поддерживает его, он все еще остается требованием стандарта.
womble.decadent.org.uk/c++/template-faq.html#two-phase

Information

Rating
3,622-nd
Location
Россия
Registered
Activity