1.2, старик (?), 01:36, 04/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Кхх гм ну что ж хорошая новость.Сейчас перекомпилирую 1041 исходный текст.Жаль только что опять OpenACC ни как а я уж по старости своей наивной понадеился на свою rx580 заместо процессора.
| |
|
|
|
4.37, Аноним (37), 06:20, 06/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
мда, чую как корабль назовешь так оно и поплывет
еще не допилили, а уже сТУх
| |
|
|
2.8, Аноним (8), 11:08, 04/05/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
>реализована бо́льшая часть спецификации параллельного программирования OpenACC 2.5
Эх, старик, трах тебя тибедох. (C) Прочитай новость в более сильных очках.
| |
|
1.6, Аноним (6), 06:41, 04/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Печально, но в OBS-репозитории devel:gcc/SLE_11 его уже не будет. Из-за прекращения основной поддержки. А жаль. Было очень удобно использовать компилятор оттуда для билд-фермы. А devtoolset для CentOS не настолько удобный
| |
1.13, старик2 (?), 18:03, 04/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Ну все перекомпилировал не собрался qtcore-5.11.2.А 1040 текстов собралось без проблем пока глюков программ нет.COMMON_FLAGS="-march=native -O2 -fgraphite -fgraphite-identity -floop-interchange -floop-nest-optimize -ftree-loop-distribution -fomit-frame-pointer -pipe"Правда долго очень процессор у меня очень стар как и я тоже.FX-9590 DDR3-2133 asus-V-Formula-Z. 14 часов ушло наверно тротлил хад.
| |
|
2.14, Аноним (14), 20:59, 04/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Только qt с графитом потом рандомно крашится и зависает, в кедах особенно классно сидеть. И вообще фигня, ни одна программа не показала выигрыша в производительности с ним. Лто хотя бы бинарники меньше делает, для плюсовых программ хорошо. А вот пго топчик, оптимизирует без заморочек написанный код (ручками можно того же добиться).
Короче, отключайте всю эту дpянь.
| |
|
1.15, старик2 (?), 23:13, 04/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Хмм возможно и так но проблем с крашами не наблюдал ну скорее всего нет большого количества специфичных программ для серьезной работы где нужна стабильность.Так себе небольшой сервер и мультимедиа десктоп.Да конечно в продакшен с такими флагами ни ни согласен.А лто да еще года четыре назад юзал сравнивал размер бинарников ну и т.д.Главная проблема лто в роллинг бэйс операционках (при обновленнии системы)это изменение версий программ и их кода что ведет по моему опыту к неработоспособности и глюкам программ так как слетает линковка всяких там библиотек или удаление из исходника того что должно работать с другой частью зависимого кода glibc например что и приводит в итоге к глючному бинарнику.Вот как пример собрал не давно лису с лто -march=native -02 и gold линкером (ни какого хардкора)и что в лисе перестал сохранятся масштаб текста и всего отображаемого на странице выставлял +200% при перезагрузке браузера опять 100% -это нужно для больших экранов при просмотре с расстояния чтоб увеличить размер всего на странице.По моему скромному мнению лто хорош на специальных проектах собрал и забыл.Да конечно есть автоматизированный си-ай интегрейшн но это работает в конторах (постоянная сборка пересборка мержка и т.д)а дома лто ну его нафиг нет времени разбираться в багах и зависимостях денег за это не заплатят а система упадет.
| |
1.16, старик2 (?), 23:37, 04/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Гм с профилированием PGO надо по думать.Только оно т.е пго для для небольшого количества программ предназначено (ну в gentoo например).Да предполагаю что любой код можно профилировать но это надо вносить изменения в средство разработки или в билды и т.д.Да и с сценарием работы кода тоже не ясно какая последовательность выполнения модулей блоков алгоритмов чаще выполняется.Набрать статистику работы можно но это не решает всех возможных вариантов работы программы.Так что вопросов очень много.Возможно надо придерживаться золотой середины.
| |
1.17, старик2 (?), 23:59, 04/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Да и с графитом не понятно я не кодер.Какие циклы в каком коде если С++ как часто повторяются и есть ли смысл их обьеденять сокращать и т.д что это даст?
| |
1.18, Аноним (18), 11:32, 05/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –5 +/– |
>case 2: how = 205; break; case 3: how = 305; break;
Это - говнокод, оптимизировать его так смысла не имеет. Имеет смысл уволить того, кто такое пишет, так как оптимизированный компилятором вариант проще для понимания, чем исходный.
| |
|
2.22, Ordu (ok), 12:35, 05/05/2019 [^] [^^] [^^^] [ответить]
| +5 +/– |
Нет. В реальном коде это выглядит обычно так:
enum {
AVADA_KEDAVRA = 2,
ALOHOMORA = 3,
STUPEFY = 4,
/* ... */
};
и дальше где-то:
case AVADA_KEDAVRA: how = 205; break;
case EXPECTO_PATRONUM: how = 1234; break;
case STUPEFY: how = 405; break;
case SECTUM_SEMPRA: how = 1005; break;
case ALOHOMORA: how = 305; break;
Запросто может не быть единой формулы для всех case'ов, но даже если она и есть, использование такой формулы может быть глупостью, потому что потом кто-нибудь изменит enum в хидере, и твоя формула пойдёт лесом, она начнёт работать неправильно. То есть мы получим нелокальный баг -- ты вносишь изменения в один файл, а баг привносится в совершенно другой файл, может быть даже в другом проекте. Что плохо -- он привносится молчаливо, и вся надежда на то, что тесты смогут его выявить. Если не смогут, то ты подаришь этот баг пользователям, когда зарелизишь свои полезнейшие изменения.
Вариант с case'ами лучше тем, что меньше шансов сломать его нелокально, а если C умеет проверять case'ы на полное покрытие значений enum'а (он умеет? а если не умеет, то статический анализатор должен помочь), то тогда вообще всё получается почти идеально. Ты меняешь enum, код либо продолжает работать, либо выкидывает варнинги/ошибки в процессе компиляции.
| |
|
3.23, старик2 (?), 14:27, 05/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Про EXPECTO_PATRONUM осилил эхх тяжело мне новые знания даются с трудом ну ни чего прорвемся все собираюсь собираюсь начать учить C++ и все никак старик как ни как.Спасибо за разьяснения.
| |
|
4.25, Ordu (ok), 15:26, 05/05/2019 [^] [^^] [^^^] [ответить]
| +5 +/– |
Иди лучше русский изучи, дедунь. Я вот тоже не знаю, куда ставить запятые, а куда нет, но если ты их совсем не ставишь, читать крайне сложно. Если по другим твоим сообщениям посмотреть, то тебе и тему слитно/раздельно следует освежить в памяти. Изучи русский. Забей на IT, это не для тебя.
| |
|
5.26, старик3 (?), 15:34, 05/05/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Мне уже 74 год что ты хочешь.Вот доживешь до мои годков тогда посмотрим.А русский я плохо знаю так как родился в Киеве а вырос в германии.Не обижайся если что.
| |
|
6.27, Ordu (ok), 15:55, 05/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Вот доживешь до мои годков тогда посмотрим.
Это ты излишне оптимистично использовал тут множественное число.
| |
6.32, НяшМяш (ok), 21:22, 05/05/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Мне кажется, что в немецком письменном также принято ставить запятые и пробелы после запятых и точек. 74 года - не оправдание.
| |
6.57, SohnEinesOffiziers (?), 15:52, 07/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Мне уже 74 год что ты хочешь.Вот доживешь до мои годков тогда
> посмотрим.А русский я плохо знаю так как родился в Киеве а
> вырос в германии.
Ja ne, is klar!
Mein lieber Herr Gesangsverein, Sachen jibt's dat jibt's gar nit!
| |
|
|
|
3.29, Аноним (18), 16:26, 05/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
>Запросто может не быть единой формулы для всех case'ов, но даже если она и есть, использование такой формулы может быть глупостью, потому что потом кто-нибудь изменит enum в хидере
Не надо просто валить всё в кучу. Если есть подобная структура в енамах, то это говорит о том, что иут надо не в 1 енам всё мешать, а разделить по разным полям в структуре и передавать не инты, а структуры. Если нужно сэкономить место, то битовые поля к вашим услугам.
enum class SpellGroup:uint8_t{
undefined=0
offensive=1,
defensive=2,
service=3
};
struct spell{
SpellGroup offensive:2;
union{
OffensiveSpellId offensive;
DefensiveSpellId defensive;
ServiceSpellId service;
} id:7;
};
| |
|
4.30, Ordu (ok), 18:59, 05/05/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Не надо просто валить всё в кучу. Если есть подобная структура в
> енамах, то это говорит о том, что иут надо не в
> 1 енам всё мешать, а разделить по разным полям в структуре
> и передавать не инты, а структуры.
> надо не в 1 енам...
> надо
Кому надо? Зачем надо? Ты уверен, что этот подход сработает всегда? Скажем, если значения нашего enum'а взяты из /etc/services или ещё откуда? Ты уверен, что вся информация связанная с константой обязательно влезет в машинное слово, в том числе и каноническое имя для этой константы, и ещё описание для пользователя, если он захочет больше подробностей? С переводами на пару десятков языков.
| |
|
5.31, Аноним (18), 21:16, 05/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
>если значения нашего enum'а взяты из /etc/services
ЩИТО? в /etc/services нет перечислений, там только номера портов
>Ты уверен, что вся информация связанная с константой обязательно влезет в машинное слово, в том числе и каноническое имя для этой константы, и ещё описание для пользователя, если он захочет больше подробностей? С переводами на пару десятков языков.
Вы вообще о чём? Мы говорим о перечислениях и о конкретной оптимизации и о том, почему лучше уволить разраба, к коду которого она применима. Если вам надо таскать всю указанную информацию, то перечислением и той конкретной оптимизацией тут и не пахнет.
| |
|
6.35, Ordu (ok), 22:28, 05/05/2019 [^] [^^] [^^^] [ответить] | +1 +/– |  Да, там только перечисление номеров портов с именами сервисов и комментами Вещь... большой текст свёрнут, показать | |
|
7.42, meantraitor (?), 12:53, 06/05/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> _descriptions было бы круто спрятать из .h файла куда-нибудь, но тогда не удастся следующие
> функции заинлайнить статически (это дурацкие ограничения C, их может быть можно обойти инлайном
> в линк-тайме, но я не знаю об этом ничего -- слышал звон, да не знаю где он).
extern struct ServiceDescription _descriptions[];
и все отлично инлайнится.
А за написание в хедере
static struct ServiceDescription { ... } _descriptions[] = { ... }
обычно бьют канделябром по голове, потому в каждом .c, включившем этот .h оседает своя
собственная копия _descriptions[]
| |
|
8.43, Ordu (ok), 13:00, 06/05/2019 [^] [^^] [^^^] [ответить] | –4 +/– |  А, да, я забыл Видишь, это именно те самые глупости в C, которые делают его ока... текст свёрнут, показать | |
|
9.46, Урри (?), 13:52, 06/05/2019 [^] [^^] [^^^] [ответить] | +/– | Неосилятор, или табы правильно расставляй в своей молодежной огороженной песочни... текст свёрнут, показать | |
|
10.48, Ordu (ok), 14:13, 06/05/2019 [^] [^^] [^^^] [ответить] | –1 +/– |  Ты пробовал когда-нибудь переключаться между языками C шная идея include ов -- ... текст свёрнут, показать | |
|
|
10.55, Ordu (ok), 12:13, 07/05/2019 [^] [^^] [^^^] [ответить] | –3 +/– |  Это настолько очевидно, что я не вижу даже что тебя подвинуло об этом писать ... текст свёрнут, показать | |
|
|
|
7.44, Аноним (44), 13:44, 06/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Как с /etc/services работать из C?
Это же азы С - struct servent *getservbyname(cont char *name, const char *proto);
А у вас что это за треш навелосипедился?
| |
|
8.49, Ordu (ok), 14:14, 06/05/2019 [^] [^^] [^^^] [ответить] | –1 +/– |  Дитятко, я выше специально сделал оговорку ради этого Вот специально я был уве... текст свёрнут, показать | |
|
|
|
|
|
3.45, Урри (?), 13:51, 06/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Вы, извиняюсь, на чем пишете?
Потому как при изменении хидера полюбому надо пересобирать проект - что с оптимизацией, что без, код не будет соответствовать новым условиям.
| |
|
4.50, Ordu (ok), 14:15, 06/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Вы, извиняюсь, на чем пишете?
> Потому как при изменении хидера полюбому надо пересобирать проект - что с
> оптимизацией, что без, код не будет соответствовать новым условиям.
Проблема в том, что некоторые изменения хидера не решаются пересборкой проекта. Если хидер написан неудачно или используется не так, как задумано автором этого хидера (что тоже в общем-то попадает в категорию "неудачно написан"), то изменения хидера требуют аудита всего кода, который этим хидером пользуется.
| |
|
3.56, Аноним (56), 15:46, 07/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
> мы получим нелокальный баг --
> ты вносишь изменения в один файл, а баг привносится в совершенно
> другой файл, может быть даже в другом проекте.
Ошибка второго порядка?
| |
|
4.58, Ordu (ok), 17:27, 07/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Ошибка второго порядка?
Я не знаю, есть ли для таких ошибок специальное название. Может быть "не локальная ошибка"?
| |
|
|
|
1.19, Аноним (18), 11:40, 05/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>Currently devices using Nvidia PTX (nvptx) are supported, and AMD GCN device support is in development.
Чувствую я, владельцев старых карты вообще прокинут и во всех новых приложениях будет требование post-gcn карт.
Я бы может быть и купил бы карту (очень жаль, что купить новую кар у за сколько там тыщ будет дешевле, чем работать фуллтайм над допилом всего того софта, её дропнувшего, а потом убеждать всяких **** включить в дистрибутивы софт с лишними функциями, не нужными 99,99% пользователей. потому что у всех уже новые карты), но мой блок питания (450 W, охренеть, почти полкиловатта системник потреблял 10 лет назад, что де теперь творится?) впритык тянет всё то говно, что понапихано в мой системник.
| |
|
2.33, НяшМяш (ok), 21:25, 05/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Если у тебя 450W блок питания уже 10 лет, то очень скоро он может перестать тянуть даже то самое, поставленное те же 10 лет назад. Если в нем заменить электролиты, то спокойно будет тянуть системник вида 9700 (без К) и 1060. Они укладываются в 250 ватт потребления.
| |
|
|
|
3.28, Аноним (18), 16:10, 05/05/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
Вообще-то впилить можно было бы сразу после того, как определились с названием стандарта, так как флаг выводится из него.
| |
3.53, Аноним (53), 07:36, 07/05/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Безобразие, конечно: позавчера вышел компилятор, а в вышедшую две недели назад версию сборочной системы его новые фичи ещё не завезли!
Это проблема сборочной системы, которую надо править после каждого релиза компилятора. В автотулзах уже есть:
CFLAGS=-std=c2x ./configure...
| |
|
4.59, Аноним (61), 14:01, 08/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
Ты вообще в курсе, для чего autocrap и cmake придуманы? Вот как раз для того, чтобы не надо было все эти параметры ручками указывать, к тому же во время сборки (собирает юзер, который знать не знает, какой там стандарт нужен). Но в autocrap для сишных стандартов макроса вообще не завезли, только для плюсов есть ax_cxx_compile_stdcxx. Так что чья б корова мычала.
| |
|
5.60, Аноним (61), 14:04, 08/05/2019 [^] [^^] [^^^] [ответить]
| +/– |
P. S. для особо одарённых: конечно же, можно сделать cmake -DCMAKE_C_FLAGS=-std=c2x. Но это неправильное решение.
| |
|
|
|
|
1.21, Аноним (18), 11:53, 05/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
>Прекращена поддержка архитектур Armv2, Armv3, Armv5 и Armv5E
Таким образом ведь и i686 дропнут.
| |
|
2.47, Урри (?), 13:54, 06/05/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Просто пользуемся предыдущей версией. Никаких исправлений тут все равно нету, одни мало кому нужные фичи.
| |
|
|
2.39, Совершенно другой аноним (?), 09:21, 06/05/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Есть такая линейка процессоров от Intel - Atom-ы называются. Там только сравнительно недавно x86-64 завезли, а до того, считай, тот i686 и только и был.
| |
|
1.41, InuYasha (?), 11:52, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Среди всех этих новостей про жавы, руби, электроны... Хоть что-то краСИвое, вечное, доброе!
| |
1.52, Аноним (52), 18:18, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
>Процесс включения поддержки языка D в GCC начался ещё в 2011 году, но затянулся
Так затянулся, что через пару релизов пора будет депрекейтить, за ненадобностью
| |
1.63, iZEN (ok), 13:46, 10/05/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |

/usr/src/contrib/libstdc++/src/bitmap_allocator.cc: At global scope:
/usr/src/contrib/libstdc++/src/bitmap_allocator.cc:126:1: error: '_GLIBCXX_END_NAMESPACE' does not name a type
126 | _GLIBCXX_END_NAMESPACE
| ^~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/src/contrib/libstdc++/src/bitmap_allocator.cc:30:
/usr/src/contrib/libstdc++/include/ext/bitmap_allocator.h: In instantiation of 'void bitmap_allocator<_Tp>::_M_deallocate_single_object(bitmap_allocator<_Tp>::pointer) [with _Tp = char; bitmap_allocator<_Tp>::pointer = char*]':
/usr/src/contrib/libstdc++/src/bitmap_allocator.cc:123:18: required from here
/usr/src/contrib/libstdc++/include/ext/bitmap_allocator.h:963:54: error: '__real_p' cannot be used as a function
963 | (__real_p) (_S_mem_blocks[_S_last_dealloc_index]))
| ^
/usr/src/contrib/libstdc++/include/ext/bitmap_allocator.h: In instantiation of 'void bitmap_allocator<_Tp>::_M_deallocate_single_object(bitmap_allocator<_Tp>::pointer) [with _Tp = wchar_t; bitmap_allocator<_Tp>::pointer = wchar_t*]':
/usr/src/contrib/libstdc++/src/bitmap_allocator.cc:124:18: required from here
/usr/src/contrib/libstdc++/include/ext/bitmap_allocator.h:963:54: error: '__real_p' cannot be used as a function
/usr/src/contrib/libstdc++/src/bitmap_allocator.cc: In member function 'size_t* free_list::_M_get(size_t)':
/usr/src/contrib/libstdc++/src/bitmap_allocator.cc:103:3: warning: control reaches end of non-void function [-Wreturn-type]
103 | }
| ^
*** Error code 1
Stop.
make[4]: stopped in /usr/src/gnu/lib/libstdc++
Не работает — чините.
| |
1.65, iZEN (ok), 22:22, 07/07/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> firefox
JavaScript error: resource:///modules/sessionstore/SessionStore.jsm, line 1215: uncaught exception: 2147746065
###!!! [Parent][MessageChannel] Error: (msgtype=0x1E0076,name=PBrowser::Msg_RealMouseMoveEvent) Channel error: cannot send/recv
###!!! [Parent][MessageChannel] Error: (msgtype=0x1E0074,name=PBrowser::Msg_StopIMEStateManagement) Channel error: cannot send/recv
###!!! [Parent][MessageChannel] Error: (msgtype=0x1E008F,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv
[Child 4303, Chrome_ChildThread] WARNING: pipe error (3): Socket is not connected: file /tmp/ports/usr/ports/www/firefox/work/firefox-68.0/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 358
— почему информация времени компиляции firefox попала в его рантайм? (firefox-68.0 откомпилирован gcc9-9.1.0)
| |
|