Возврат структуры из функции

[vpb]

tolstopuz в сообщении #1602126 писал(а):

Человек по каким-то личным причинам принципиально хочет пользоваться игрушечным компилятором, который до 2017 года не понимал стандарт C89, да еще и не обновляет его версию, хотя в ней хотя бы этот баг исправлен. Печально.

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

[tolstopuz]

vpb в сообщении #1602188 писал(а):

и он подходит (по словам автора) для маломощных компьютеров.

Маломощный компьютер - это 8088 с двумя флопповодами по 360 килобайт, на нем будет работать Турбо-Паскаль 7.0, я примерно так в 1992 году работал на "Поиске". Если на вашем компьютере работает Windows 7, он уже совсем не маломощный.

[vpb]

tolstopuz в сообщении #1602197 писал(а):

Если на вашем компьютере работает Windows 7, он уже совсем не маломощный.

Понятно. Будем знать.

[mihaild]

vpb в сообщении #1602179 писал(а):

В книжках и статьях тоже бывают ошибки, тем не менее люди же их читают, и извлекают для себя пользу

Тут есть очень большая разница: Вы можете самостоятельно сделать своё рассуждение по мотивам статьи, и убедиться в его правильности. А вот реалистично написать свой бинарный код по мотивам скомпилированного - нет. И даже понять, что в скомпилированном коде ошибка очень сложно.
Поэтому компилятор должен быть максимально надежным. Плюс если уж Вы умеете работать с командной строкой (это не так мало, многие студенты первого курса не умеют и довольно тяжело учатся), то и с использованием gcc или clang у Вас проблем не будет.

[TheRuinedMap]

mihaild в сообщении #1602238 писал(а):

Поэтому компилятор должен быть максимально надежным. Плюс если уж Вы умеете работать с командной строкой (это не так мало, многие студенты первого курса не умеют и довольно тяжело учатся), то и с использованием gcc или clang у Вас проблем не будет.

Чем больше вы верите в надежность компилятора, тем труднее вам будет разобраться в ситуации, когда аналогичные глюки полезут из gcc или clang.

[mihaild]

TheRuinedMap в сообщении #1602293 писал(а):

Чем больше вы верите в надежность компилятора, тем труднее вам будет разобраться в ситуации, когда аналогичные глюки полезут из gcc или clang

Не особо. И в моей практике баг в clang вылез ровно один раз (и выглядел он не как неправильная работа программы, а как OOM при компиляции).

[TheRuinedMap]

mihaild в сообщении #1602297 писал(а):

TheRuinedMap в сообщении #1602293 писал(а):

Чем больше вы верите в надежность компилятора, тем труднее вам будет разобраться в ситуации, когда аналогичные глюки полезут из gcc или clang

Не особо. И в моей практике баг в clang вылез ровно один раз (и выглядел он не как неправильная работа программы, а как OOM при компиляции).

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

Всякий раз, когда я привожу этот пример для GCC

Используется синтаксис C++

#include <cstdint>
#include <cstdio>

std::uint16_t foo(std::uint16_t abgr)
{
  return (abgr ^= (abgr >> 8)) ^= (abgr << 8);
}
 
int main() 
{
  std::uint16_t tmp = 0xAABB;
  std::printf("%x %x\n", tmp, foo(tmp));
}

требуется время, чтобы убедить собравшихся, что правильный вывод в современном С++ - aabb 1111, а не aabb bb11, которое до сих пор упорно выдает GCC.

[Geen]

TheRuinedMap в сообщении #1602314 писал(а):

правильный вывод в современном С++

а можно пруф?

[TheRuinedMap]

Geen в сообщении #1602319 писал(а):

TheRuinedMap в сообщении #1602314 писал(а):

правильный вывод в современном С++

а можно пруф?

Какого рода "пруф"? Начиная с С++17 были введены более жесткие правила упорядочения (sequencing) в операторе присваивания: http://eel.is/c++draft/expr.ass#1. А именно, было добавлено однозначное: "The right operand is sequenced before the left operand." Если выражение в функции вычислять в соответствии с правилами С++17 (и позже), то получится 0x1111.

[photon]

(Оффтоп)

TheRuinedMap в сообщении #1602314 писал(а):

Всякий раз, когда я привожу этот пример для GCC

Для тех, кто использует в своем коде такие конструкции, есть отдельный котел

[Geen]

TheRuinedMap в сообщении #1602322 писал(а):

Начиная с С++17 были введены

А можно ссылку не на драфт?

[TheRuinedMap]

(Оффтоп)

photon в сообщении #1602325 писал(а):

TheRuinedMap в сообщении #1602314 писал(а):

Всякий раз, когда я привожу этот пример для GCC

Для тех, кто использует в своем коде такие конструкции, есть отдельный котел

Но речь-то идет не о таких конструкциях, а о том, что где-то в недрах GCC упорядочение вычисления оператора присваивания реализовано неправильно. А уже в каких конструкциях это вылезет - дело пятое. Я вот пока нашел такую... А завтра какой-нибудь Гойко Митич наткнется (или может уже наткнулся) на более практичный вариант, страдающий от того же бага...

-- 24.07.2023, 11:03 --

Geen в сообщении #1602326 писал(а):

TheRuinedMap в сообщении #1602322 писал(а):

Начиная с С++17 были введены

А можно ссылку не на драфт?

Во-первых, это и есть "не драфт" в отношении С++17.

Во-вторых, "ссылка не на драфт" может выглядеть только так: [expr.ass]/1. И эта ссылка уже содержится в приведенной мною ссылке.

[Geen]

TheRuinedMap в сообщении #1602327 писал(а):

Во-первых, это и есть "не драфт" в отношении С++17.

это из чего следует?

TheRuinedMap в сообщении #1602327 писал(а):

Во-вторых, "ссылка не на драфт" может выглядеть только так: [expr.ass]/1. И эта ссылка уже содержится в приведенной мною ссылке.

ссылка содержится в ссылке.....
знавал я перл-гольф, вот совсем недавно ещё и с++-гольф познал... но вот в 'русский язык'-гольф я не играю - слабы мои знания в этой части.

-- 24.07.2023, 22:30 --

photon в сообщении #1602325 писал(а):

использует в своем коде такие конструкции

Вообще не понимаю практической необходимости в l-value присваивания.

[mihaild]

TheRuinedMap в сообщении #1602314 писал(а):

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

Я не понимаю, как вера в компилятор влияет на отладку. Рано или поздно я либо нахожу у себя ошибку, либо получаю настолько простой код, что могу проверить его по стандарту. Пока что всегда (кроме упомянутого выше случая) реализовывался первый вариант.

Geen в сообщении #1602326 писал(а):

А можно ссылку не на драфт?

А за не-драфт хотят денег. Но там всё то же самое.

[Geen]

mihaild в сообщении #1602331 писал(а):

А за не-драфт хотят денег.

Знаю, на халяву надеялся