| 1.1, Named (?), 00:01, 09/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +9 +/– | |
> В каждом функциональном обновлении теперь меняется первая цифра... корректирующие обновления, как и раньше приводят к увеличению третьей цифры.
А вторая цифра на что тогда?
Непонятно, зачем в последнее время многие переходят на такую нумерацию. Особенно в профессиональных продуктах.
Ведь есть же четкая схема: первая цифра - значительные функциональные изменения (возможно, с нарушением обратной совместимости), вторая - изменения с обеспечением совместимости, 3-я - багфиксы. Понятно по версии, чего можно ждать от обновления.
| | |
| |
| 2.3, Аноним (-), 01:09, 09/03/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Непонятно, зачем в последнее время многие переходят на такую нумерацию.
По сути, большего и не надо. Одно число обозначает ветку, второе - номер более-менее стабильного релиза в ветке. Уверен, через какое-то время от второй цифры тоже избавятся: будут просто брать последний коммит в нужной ветке, а производители в ветки будут добавлять только исправления ошибок, а вообще все другие изменения отправлять в ещё не зарелизенную ветку.
Глобальных изменений в софте больше не происходит. Это раньше было Windows 3.1, Windows 95, Windows NT, и периодически новое поколение вносило что-то принципиально новое. А сейчас одинаковые ветки без масштабных изменений. Linux 2.0, 2.2 и 2.4 отличались достаточно сильно, 2.6 уже не настолько отличалась от 2.4, а уж после 2.6 принципиальных изменений практически и не было. Точнее, были, но разбивались на мелкие куски и внедрялись постепенно непрерывным потоком, так что ничего глобального между смежными релизами не ощущалось.
Психологически, мне было бы комфортнее с тремя цифрами. Зафиксировали бы просто старшую цифру, и меняли вторую и третью. Ну и что, что linux 3.127.11? Вооще не проблема. А возможность смены первой оставили бы на какой-нибудь глобальный случай, который сейчас и предусмотреть нельзя.
| | |
| |
| 3.4, YetAnotherOnanym (ok), 02:00, 09/03/2018 [^] [^^] [^^^] [ответить]
| +5 +/– |
 > Глобальных изменений в софте больше не происходит
Уфффф... Ну наконец-то! А то они меня уже утомили.
| | |
| 3.8, Аноним (-), 09:12, 09/03/2018 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Уверен, через какое-то время от второй цифры тоже избавятся: будут просто брать последний коммит в нужной ветке
Последний коммит - это тоже слишком сложно.
Просто перейдут на блокчейны и смарт-контракты - все станет просто и понятно.
| | |
| |
| 4.23, Аноним (-), 17:02, 09/03/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Последний коммит - это тоже слишком сложно.
> Просто перейдут на блокчейны и смарт-контракты - все станет просто и понятно.
А что, это идея. Комитнул в проект - выполнил таск - прокатили тесткейсы - вот тебе бабло. А иначе иди и переделывай свою халтуру. А так чтобы протирать штаны, переваливать работу на других да еще и денег получать - опа-па!
| | |
|
|
| 2.6, Тот_Самый_Анонимус (?), 06:09, 09/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Первое число — на ветку с длительным сроком поддержки. Второе — на выпуски между первыми ветками, третье — на исправления.
| | |
| 2.11, пох (?), 09:26, 09/03/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Непонятно, зачем в последнее время многие переходят на такую нумерацию.
инвесторы (ну вы уже запомнили какое слово подставлять вместо) любят большие числа. А если ты им версию 2.7.2.1 - они резонно спрашивают "с какой ерундовой херней вы там копаетесь и не урезать ли вам финансирование". Потому что нет уже инвесторов, не осталось.
| | |
| 2.14, Аноним (-), 10:08, 09/03/2018 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> есть же четкая схема: первая цифра - значительные функциональные изменения (возможно, с нарушением обратной совместимости), вторая - изменения с обеспечением совместимости, 3-я - багфиксы.
Сейчас в моде "непрерывная разработка", все функциональные изменения вводятся постепенно, так что первая цифра просто никогда бы не менялась.
| | |
| |
| |
| 4.22, Nexmean (?), 16:46, 09/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
То ли дело было раньше, пусть программа и была недоделкой, зато дискретной!
| | |
| 4.25, Аноним (-), 17:19, 09/03/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> И поэтому программы превращаются в непрерывную недоделку.
Зато быстрофиксы прилетают. А раньше надо было еще и ждать быстрофикса хрен знает сколько. Очень удобно курить бамбук полгода с известной проблемой.
| | |
|
|
|
| 1.2, Гоги (?), 00:01, 09/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –14 +/– |
LLVM так хорошо развивается, что уже два раза почешешь репу, подо что писать новый язык - под дотнет (с кучей готовых либ) или нэтив, но зато с полным гемороем по написанию ВСЕГО.
| | |
| |
| 2.28, Вареник (?), 20:58, 09/03/2018 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Для аппликух есть .NET и JDK.
Для игр-3D-DeepLearning-Robotics-околонаучного-статистики-графиков есть C++ и интерфейсами либ на Python.
с продвижением JS как средства все затормозить во всех этих категориях.
| | |
|
| 1.5, leap42 (ok), 02:13, 09/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 > Добавлена предварительная поддержка санитайзеров (ASan, UBsan, те, которых никто не знает)
можно начинать пользоваться
| | |
| 1.18, Аноним (-), 13:33, 09/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– | |
>Поддержка оператора "‹=›" для трехстороннего сравнения;
Астанавитесь!!!
| | |
| |
| |
| 3.33, Аноним (-), 22:56, 10/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
А как это должно уменьшить объём писанины?
if (a < b) {
// ...
} else if (a > b) {
// ...
} else {
// ...
}
switch (a <=> b) {
case std::partial_ordering::less:
// ...
break;
case std::partial_ordering::greater:
// ...
break;
default:
// ...
break;
}
Единственное "достоинство" — выглядит не по-сишному.
| | |
| |
| 4.34, 0xd34df00d (??), 23:50, 10/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
 Это уменьшает объём писанины в первую очередь для автора класса, а не для клиента. Для кучи практически полезных случаев компилятор способен сгенерировать определение оператора (и всех выражающихся через него) сам. Можно посмотреть в пропозалах или на cppreference ( http://en.cppreference.com/w/cpp/language/default_comparisons ) подробнее.
Где бы это было полезно в чистом клиентском коде, я сходу не могу придумать.
Ну и, кроме того, иерархия типов определяемых порядков (частичный порядок, сильный порядок, вот это всё) — это интересно.
| | |
| |
| 5.39, Аноним (-), 18:20, 11/03/2018 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Где бы это было полезно в чистом клиентском коде, я сходу не могу придумать.
Самый простой пример — сравнение строк:
switch (str1 <=> str2) {
// ...
}
будет значительно эффективнее, чем
if (str1 < str2) {
// ...
} else if (str1 > str2) {
// ...
} else {
// ...
}
Есть, конечно, функции типа strcmp(), но:
1) для неравенства строк стандарт определяет только знак возвращаемого значения, так что вариант со switch-ем отпадает (скорее мелкое неудобство, чем реальный недостаток, но всё же);
2) сишные функции не годятся для строк, не оканчивающихся на '\0' (std::string_view и пр.), и строк, которые сами знают свою длину и могут содержать '\0' в любом месте.
| | |
|
|
|
|
| 1.19, Iaaa (ok), 14:31, 09/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 > По умолчанию в исполняемые файлы теперь добавляется секция ".init_array", если в системе не установлен GCC. Если наличие GCC обнаружено и версия старее 4.7.0, то как и раньше подставляется секция ".ctors";
А домашний адрес, если обнаружен, автоматом в секции не проставляется? И как насчет полного списка установленных пакетов туда же, в отдельную секцию?
Почему было не запилить для этой фичи флажок, вместо вот такого шпионажа?
| | |
| |
| |
| 3.21, Iaaa (ok), 15:14, 09/03/2018 [^] [^^] [^^^] [ответить]
| +3 +/– | |
У анонима, как обычно, апломба вагон и знаний тележка.
Я то в курсе для чего нужна секция ".init_array". А вот ты мне можешь объяснить, какое отношение имеет установленный или НЕ установленный в системе GCC наполнению этой секции?
Особенно с учетом того, что я в любой момент могу гцц снести или доустановить, без какой-либо перекомпиляции своих, запланированных для сборки ТОЛЬКО шлангом, сорцов?
| | |
| |
| 4.32, all_glory_to_the_hypnotoad (ok), 18:17, 10/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
 +1. Вообще эта магия внутри шланга с gcc подзадалбывает. Развернули у нас на производстве, понимаешь, clang вместо gcc и его стандартной библиотеки. Так этот грёбанный clang, как его не корми опциями, всё равно время от времени умудряется отыскать в системе gcc и что-то из него утянуть. Причём даже нельзя угадать из какой именно из установленных в системе версий gcc утянет.
| | |
| |
| 5.35, пох (?), 09:48, 11/03/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Вообще эта магия внутри шланга с gcc подзадалбывает.
эта магия просто не для вас предназначена, а для обычного пользователя - которому нужно чтобы инструмент просто работал, собирая здесь и сейчас - и не ломался о модуль, собранный рядомстоящим компиляторами.
а разработчиков, вместо билдхоста собирающих что-то даже для тестов на собственной хз как хз для чего настроенной системе - надо давить поганым давилом.
(потому что дальше начинаются докеры, полная операционная система внутри пакета, и прочий мусор вида "у меня на домашнем ноуте все работает, сделайте мне!" )
> Причём даже нельзя угадать из какой именно из установленных в системе версий gcc утянет.
можно. просто вы не умеете. И низачем не нужно.
| | |
| |
| 6.38, Аноним (-), 12:39, 11/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
> а разработчиков, вместо билдхоста собирающих что-то даже для тестов на собственной хз
> как хз для чего настроенной системе - надо давить поганым давилом.
Вот я даже не представляю, как при таком поведении компилятора можно собрать что-то без помощи докера или аналога, позволяющего создать минимальное воспроизводимое сборочное окружение. Впрочем, при необходимости полностью выпилить gnu-стек и докер не сильно помогает.
| | |
| |
| 7.40, пох (?), 15:20, 13/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Вот я даже не представляю, как при таком поведении компилятора можно собрать что-то без помощи
> докера
да в том и дело, что прекрасно соберется, и будет работать - даже если пара .o произведена не тем компилятором.
Переносу на соседнюю машину - да, подлежать совсем не будет, потому что зависит от хз какой libgcc_s и еще аллах ведает, чего. Но пользователю - оно и не надо. А непользователь говорит "дурак я, что-ли, на своем ноуте ЭТО делать, он же греется и руки обжигает", и делает push. Там за него само все соберется и результат пришлет.
> Впрочем, при необходимости полностью выпилить gnu-стек и докер не сильно помогает.
а его пока и нельзя выпилить полностью - даже если кому-то повезло с платформой, и он может обойтись без gnu ld (freebsd вот - пока не может, не смотря на все старания), без прослойки совместимости в трансляторе - не обойдешься в любом случае (то есть те же gcc_s и прочее все равно притащит) - ну и было бы тогда, за что бороться?
| | |
|
| 6.41, Ne01eX (ok), 11:56, 15/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
 >[оверквотинг удален]
> эта магия просто не для вас предназначена, а для обычного пользователя -
> которому нужно чтобы инструмент просто работал, собирая здесь и сейчас -
> и не ломался о модуль, собранный рядомстоящим компиляторами.
> а разработчиков, вместо билдхоста собирающих что-то даже для тестов на собственной хз
> как хз для чего настроенной системе - надо давить поганым давилом.
> (потому что дальше начинаются докеры, полная операционная система внутри пакета, и прочий
> мусор вида "у меня на домашнем ноуте все работает, сделайте мне!"
> )
>> Причём даже нельзя угадать из какой именно из установленных в системе версий gcc утянет.
> можно. просто вы не умеете. И низачем не нужно.
Что самое, сцуко пародоксальное, то бардак в дистрибутивах наблюдается только в RPM-based. И частично в бубунте с дебиан. И почти никак в Slackware. Другими словами, - всё зависит от вендоров. Как правило, - чем жирнее дистрибутив, тем больше хаоса. Тем нужнее LXC и.т.п.
Впрочем, непосредственно с компиляторами это никак не связано.
| | |
|
|
|
|
|
| 1.29, Fleonis (?), 01:19, 10/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Я что то не смог найти ничего по поводу оператора <=> . кто знает, поясните пожлуйста.
| | |
| |
| 2.30, Аноним84701 (ok), 01:58, 10/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
 > Я что то не смог найти ничего по поводу оператора <=> . кто знает, поясните пожлуйста.
http://en.cppreference.com/w/cpp/language/operator_comparison
[CODE]
Three-way comparison
The three-way comparison operator expressions have the form
lhs <=> rhs (1)
The expression returns an object such that
(a <=> b) < 0 if lhs < rhs
(a <=> b) > 0 if lhs > rhs
(a <=> b) == 0 if lhs and rhs are equal/equivalent.[/CODE]
| | |
|
| 1.42, Ne01eX (ok), 12:45, 15/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Где-то в соседней теме какой-то умник кричал, что дескать с помощью clang можно собрать gcc. Несколько лет назад я пробовал собрать этот набор компиляторов (gcc) с помощью clang, но не взлетело. В этот раз, исключительно just for fun озадачился сборкой gcc-7.3.0 с помощью clang clang++.
Собственно, я и не ожидал что сборка зайдёт дальше непосредственно gcc и g++, но clang не смог сделать даже это.
Пробовал с llvm-6.0.0 на x86_64 и i586. Чуть попозже попробую ещё раз, подойдя более серъёзно (реально интересует такая возможность).
Ну и пока что... Я, опять же, just for fun попробовал сравнить эффективность сборки (размер ELF и его производительность) gcc/g++ и clang/clang++ около 20 пакаджей (с флажками -O2 и -O3, всего по четыре каждого для двух платформ - i586 и x86_64). Чё-то всё пока не пользу clang. Опять же, - меня слабо интересуют искусственные попугаи, мне реально интересно, где использование clang/clang++ даст хоть какой-то плюс. Пускай это будет даже +1% по производительности и -1% по объёму. Может подскажете такое ПО? :-)
Интереса для попробую с -Ofast (это -O3 -ffast-math -fno-protect-parens -fstack-arrays). То что gcc это умеет, я не сомневаюсь. Умеет ли так clang?
P.S. clang++ заваливается на сборке mariadb (хотя, теоретически не должен). Кто-нибудь собирал им mariadb 10.2.13 или 10.3.5 с полным набором плагинов. Особенно интересуют плагины rocksdb (собранный с jemalloc и zstd) и tokudb. :-) У кого-нибудь получалось их собрать clang++?
| | |
| |
| 2.43, Andrey Mitrofanov (?), 11:19, 16/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Где-то в соседней теме какой-то умник кричал, что дескать с помощью clang
> можно собрать gcc. Несколько лет назад я пробовал собрать этот набор
>компиляторов (gcc) с помощью clang, но не взлетело.
"Обычно" неродным компилятором собирают только stage1 gcc
https://gcc.gnu.org/install/build.html
- бутстрапят из другого компилятора, а не билдят целиком.
С т.з. банальной эрудиции, FreeBSD, собирающая базу с системным clang, _должна_ же [успешно] собирать gcc-[67890] в портах системным clang-ом. Хотя они и "второй системный" gcc-4.2.1 попользуют -- недорого возьмут.
...а вот же, например:
https://gcc.gnu.org/ml/gcc/2015-05/msg00028.html
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00973.html
https://gcc.gnu.org/ml/gcc/2014-10/msg00269.html
и далее https://duckduckgo.com/?q=with+clang+bootstrap+site:gcc.gnu.org/ml%2F везде.
Для fun-а
https://duckduckgo.com/?q=diverse+double+compilation
https://www.schneier.com/blog/archives/2006/01/countering_trus.html
//
https://lists.gnu.org/archive/html/guile-user/2017-11/msg00040.html
| | |
| |
| |
| 4.45, Andrey Mitrofanov (?), 13:23, 16/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
>> https://www.schneier.com/blog/archives/2006/01/countering_trus.html
>> //
>> https://lists.gnu.org/archive/html/guile-user/2017-11/msg00040.html
> Вообще в точку попал, спасибо! По предпоследней ссылке: Там чувак (Dan) в
> комментах в одном абзаце всю статью рассказал (мне понравился коммент как
> пример лаконичности). :-)
Самый фан в --
" If they produce the same binary, then either they are both non malicious, or they are both malicious in the exact same way (which we are guessing is relatively unlikely since they don't share any of the same code) " --https://www.schneier.com/blog/archives/2006/01/countering_trus.html#c37840
-- то есть либо оба норм, либо оба прохаканы, но одинаково. Мы можем только гадать, но отметаем неудобный вариант, как ... маловероятный.
Наука!
Wheeler trick обходит _это_ с "completely independent compilers: A and T" -- независимы настолько, что одного хака в двух быть не может.
...
У автора Mes более надёжный подход: исходим не из 2ух недоверенных компилеров, а пишем минимальный, маленький и обозримый в одно лицо компилятор, достаточный и работоспособный только на ... stage1 gcc или tinycc, достаточный для сборки stage1 gcc.
И кста, твой комментатор исходил из "имеем исходники gcc, которым не доверяем" и совсем не отразил это (=что мы не читаем исходники и не знаем, не лежит ли хак в них) в гадальной части, типа: ...или хак находится в недоверенных исходниках, или его там нет.
А у тов.Wheeller-а про _недоверие_ таки именно к исходникам gcc не было: он-то ловит "самораспространяющийся хак (патченную сборку) бинарника", не _обсуждая_ хаки в исходниках. В отличие "упростившего всё" от комментатора Dan.
| | |
| |
| 5.46, Ne01eX (ok), 14:18, 16/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
> а пишем минимальный, маленький и обозримый в одно лицо компилятор, достаточный
> и работоспособный только на ... stage1 gcc или tinycc, достаточный для
> сборки stage1 gcc.
> И кста, твой комментатор исходил из "имеем исходники gcc, которым не доверяем"
> и совсем не отразил это (=что мы не читаем исходники и
> не знаем, не лежит ли хак в них) в гадальной части,
> типа: ...или хак находится в недоверенных исходниках, или его там нет.
> А у тов.Wheeller-а про _недоверие_ таки именно к исходникам gcc не было:
> он-то ловит "самораспространяющийся хак (патченную сборку) бинарника", не _обсуждая_
> хаки в исходниках. В отличие "упростившего всё" от комментатора Dan.
Ладно, лирика это всё. На практике тому же gcc абсолютно всё равно какие флаги используются в stage1. Он всё равно напихает своих при конфигурации. О какой повторяемости результата stage1/stage2 вообще тогда может быть и речь?
Короче вечером попробую повторить, собрав только базовую инфраструктуру и Си компилятор.
Пока у меня отдельно шуршит сборка gcc-7_20180315.
clang пока тихо дожидается своего часа =)
| | |
|
|
|
|
|
