WinAPI и POSIX , бой насмерть

[D_KEY]

Цитата sergioK @ 08.05.21, 10:34

В внутри IDE баг в рализации гита, merge стирает мои файлы, потерял три дня,
кто за такое отвечаеть должен ?

А можно пруф какой-то? А то еще ведь могут быть виноваты кривые руки
Кстати, если бы ты чаще заливал свои изменения на сервера компании, то всем было бы проще. Не понимаю людей, который хотя бы раз в день это не делают.
Я почти все существенные измения в ветке сразу пушу.

Цитата

в начеле 2000 когда покупали VS и было четкая докуметация

Тебе и сейчас никто не мешает покупать. У нас вон покупают
Под винду собираемся студийным компилятором плюс многие предпочитают студию в качестве IDE, поэтому покупают.

Но я не очень понимаю, что тебе не хватает в документации по gcc, например?

Цитата

да и какого черта ради документации Я должен идти в интернет? кторый
и тормозить может

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

Цитата

мне как по попался фрейворк с chm файлами, так работать одно удовольствие.

По-моему это как раз неудобно. Ну сделай сам себе chm на основе документации из интернета. Для тебя это проблема?

Сообщение отредактировано: D_KEY - 08.05.21, 15:13

[Wound]

Цитата D_KEY @ 07.05.21, 11:34

Да не, отличный компилятор. Clang мне чуть больше нравится, но я бы не сказал, что такое уж большое преимущество. С какими проблемами ты столкнулся? Поделись.

Да с примитивными, даже в специализацию не умеет. Одни баги.

[D_KEY]

Цитата Wound @ 08.05.21, 16:04

Да с примитивными, даже в специализацию не умеет. Одни баги.

Что-то я давно ни с чем таким не сталкивался. Сможешь показать? Я не ради спора спрашиваю, если что.

Добавлено 08.05.21, 17:13
Шаблоны использую, если что.

Если не трудно, можешь, например, на godbolt закинуть.

[Wound]

Цитата D_KEY @ 08.05.21, 17:10

Что-то я давно ни с чем таким не сталкивался. Сможешь показать? Я не ради спора спрашиваю, если что.

https://github.com/cpp-ru/ideas/issues/322

Добавлено 08.05.21, 17:29
Конкретно у меня было подобное. Искать или набирать примеры - мне лень. При этом компилировалось шлангом, msvs, gcc - ни в какую не хотел компилировать, причем на тот момент последний. В итоге наткнулся на баг что в ссылке.

Добавлено 08.05.21, 17:30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282

[shm]

Это не баг. Студийный компилятор просто клал на это изначально, а gcc проверял, чтобы более точно соответствовать стандарту. В С++ 17 разрешили и в gcc скоро исправят, не сомневайся.
ЗЫ: проблем с реализацией стандарта в msvc намного больше.

[Wound]

Цитата shm @ 08.05.21, 18:36

Это не баг. Студийный компилятор просто клал на это изначально, а gcc проверял, чтобы более точно соответствовать стандарту. В С++ 17 разрешили и в gcc скоро исправят, не сомневайся.
ЗЫ: проблем с реализацией стандарта в msvc намного больше.

Это баг. Код со специализацией без проблем компилируется clang, msvs, gcc - выдает ошибку. И кто там на что изначально клал, я тебя не понял?

Сообщение отредактировано: Wound - 08.05.21, 19:32

[D_KEY]

Цитата shm @ 08.05.21, 18:36

Это не баг

Таки баг, поскольку даже с ключем -std=c++20 последними версиями не компилируется. Хотя надо будет глянуть в стандарте, как должно быть.

Добавлено 08.05.21, 20:06
clang компилируется аж с 6 версии (сейчас 12).

[Wound]

Цитата D_KEY @ 08.05.21, 20:04

clang компилируется аж с 6 версии (сейчас 12).

Да. Причем так получилось, что приложение писал на QT, под виндой, но ориентировано оно было на AstraLinux + Windows. С виндой проблем не было, а на астре по умолчанию стоит gcc, я помню тестил на последнем gcc на отдельном сайте, и код падал с ошибкой. MSVS компилил его нормально. Я подумал что в MSVS баг, специально проверил на шланге, так как где то читал мол де - это единственный компилятор, максимально полно поддерживает текущий стандарт. И clang мой код тоже нормально компилировал. Я начал глубже разбираться в проблеме и наткнулся на те ссылки что запостил выше. Т.е. это баг именно в GCC, из за этого, пришлось на AstraLinux отдельно ставить clang 9, вместо использования компилятора по умолчанию - что наложило свой негативный отпечаток на gcc. Если б вы в телеге сидели в беседке форума, то возможно бы как раз участвовали в обсуждении того кода, который у меня тогда валился. А так я просто не вспомню его на вскидку, а лезть на рабочую машину и искать сейчас этот код - очень лениво. Но думаю понятно о чем речь идет из примеров по ссылке.

Добавлено 08.05.21, 21:20
Ну и к слову в изначальном моем примере - никаких вложенных классов не было вообще, просто ЕМНИП использовалась частичная и/или полная специализация класса/методов(не помню точно)

Сообщение отредактировано: Wound - 08.05.21, 21:20

[D_KEY]

Цитата Wound @ 08.05.21, 21:07

Если б вы в телеге сидели в беседке форума, то возможно бы как раз участвовали в обсуждении того кода, который у меня тогда валился. А так я просто не вспомню его на вскидку, а лезть на рабочую машину и искать сейчас этот код - очень лениво. Но думаю понятно о чем речь идет из примеров по ссылке.

Да, спасибо

Я тебя понимаю, в принципе. Только мне обычно студийный компилятор всегда жизнь портил, а вот с gcc давно не сталкивался с проблемами.
Мы компилируемся студийным под винду, под линукс на сборочных собираемся и clang и gcc. У себя локально я clang использую в линуксе.

[OpenGL]

Цитата D_KEY @ 08.05.21, 21:38

Мы компилируемся студийным под винду

А почему не clang-ом?

[shm]

Цитата D_KEY @ 08.05.21, 20:04

Таки баг, поскольку даже с ключем -std=c++20 последними версиями не компилируется. Хотя надо будет глянуть в стандарте, как должно быть.

С таким успехом можно назвать багом все фичи из с++20, которые не реализованы в том же msvc.

Добавлено 09.05.21, 06:46
Ну ок, пусть будет баг. Не увидели разработчики gcc один пункт в новом стандарте, исправят. Msvc тут как бы плохой пример, т.к. они изначально на этот самый стандарт клали, поэтому такой код, емнимп, компилился до C++17, хотя не должен был.

Сообщение отредактировано: shm - 09.05.21, 06:48

[Wound]

Цитата shm @ 09.05.21, 06:35

С таким успехом можно назвать багом все фичи из с++20, которые не реализованы в том же msvc.

Ты на календарь то глянь. речь идет о 17 стандарте, gcc его еще не поддерживает? Тогда тем более в топку это багнутое говно.

Добавлено 09.05.21, 10:56

Цитата shm @ 09.05.21, 06:35

Не увидели разработчики gcc один пункт в новом стандарте, исправят.

Это такой же новый стандарт как и c++11, C++14. Я понимаю что время летит быстро, но не на столько же, чтоб стандарт 5 летней давности называть новым. Уже 23 во всю пилят, а те еще 17 не могут поддержать.

[shm]

Цитата Wound @ 09.05.21, 10:55

Ты на календарь то глянь. речь идет о 17 стандарте, gcc его еще не поддерживает? Тогда тем более в топку это багнутое говно.

В msvc багов больше на порядок и они страшнее. Я даже сам рапортовал https://developercommunity.visualstudio.com...ystem-time.html. Мне просто лень перечислять все баги с которыми только я столкнулся (их много и все уже не вспомню). На абсолютно кривую реализацию стандарта я даже не обращаю внимание. Ты присосался только к одной проблеме gcc и почитал его бажным компилятором. Ну что ж, твое право.

Сообщение отредактировано: shm - 09.05.21, 11:58

[Wound]

Цитата shm @ 09.05.21, 11:56

В msvc багов больше на порядок и они страшнее. Я даже сам рапортовал https://developercommunity.visualstudio.com...ystem-time.html. Мне просто лень перечислять все баги с которыми только я столкнулся (их много и все уже не вспомню). На абсолютно кривую реализацию стандарта я даже не обращаю внимание. Ты присосался только к одной проблеме gcc и почитал его бажным компилятором. Ну что ж, твое право.

В msvs если и есть баги, их вполне оперативно устраняют(это видно даже по тому багрепорту, ссылку на который ты указал), хотя я сам лично не сильно сталкивался, плюс ты можешь в IDE указать другой компилятор типа clang, ЕМНИП. А в gcc - эти баги висят годами и они нах никому не упали фиксить их.

Сообщение отредактировано: Wound - 09.05.21, 12:04

[shm]

Цитата Wound @ 09.05.21, 12:01

это видно даже по тому багрепорту, ссылку на который ты указал

А если внимательно почитать обсуждение?

Добавлено 09.05.21, 12:16

Цитата Wound @ 09.05.21, 12:01

А в gcc - эти баги висят годами и они нах никому не упали фиксить их.

Зависит от приоритета.

Добавлено 09.05.21, 12:20

Цитата

Hi folks!

Sorry for the confusion here. This might be somewhat misleadingly marked "fixed pending release." The problem is that this issue is caused by the DLL interface exposed by msvcp140.dll. It passes struct xtime instances back and forth, which are effectively UNIX timestamps against the system clock. Changing that interface is unfortunately an ABI breaking change. VS2017 and 2019 have been ABI compatible releases with VS2015, so we haven't been able to fix this paritcular bug there. (I think this_thread::sleep_for might be fixable with some hacks and a new msvcp140_3.dll, but condition_variable::sleep_for, probably not)

The reason this got marked as fixed pending release is that we already have changes staged in our ABI breaking branch that completely rewrite all the concurrency support in the standard library to fix this and *many* other bugs. So we have a branch with this fixed, and as soon as we can ship an ABI break it will be fixed, but unfortunately people really like the ABI compat guarantees.

As a result we don't really know exactly which release will contain the fix. We (the standard library team) have done the work; we are only waiting to ship it till the number of customers angry about ABI breaking bugs remaining unfixed exceeds the number of customers happy that lack of ABI break means they don't need to recompile the world.

Have a great day!

Billy O'Neal

Visual C++ Libraries
Mar 27, 2019

Добавлено 09.05.21, 12:24
Перевожу: да, у нас куча багов в рантайме, но фиксить пока не будем, т. к. бинарная совместимость для нас важнее.