Независимый Форум города Дубна

Или я уже совсем устал, или вот этот sum даст переполнение зараз (никаких unsigned):

SaaBaka писал(а):Мой вариант короче, проще и быстрее :)

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

Конечно. Только это контролируемое переполнение - оно используется для сокращения (и соответственно ускорения) кода. Альтернативой является лишнее ветвление, примерно как в твоем примере. Разумеется такое не прокатит в языке, который явно запрещает/проверяет такие переполнения run-time, но для С++ такое вполне допустимо,

Ну и для тех, кто надеется на одинаковую репрезентацию знаковых переменных:
http://en.wikipedia.org/wiki/Signed_num ... sentations
Именно поэтому нет переполнения беззнаковых, и есть для знаковых. Иногда - очень полезно знать как обойти.

Конечно. Только это контролируемое переполнение - оно используется для сокращения (и соответственно ускорения) кода. Альтернативой является лишнее ветвление, примерно как в твоем примере. Разумеется такое не прокатит в языке, который явно запрещает/проверяет такие переполнения run-time, но для С++ такое вполне допустимо.

Ega23
C++ - это что называется craftsman language. Можно очень многое, но нужно чрезвычайно хорошо понимать, что делаешь.

Именно поэтому такие вестчи для "общих решений" должны расписываться в виде блок-схем.
А конкретная реализация на конкретном языке под конкретную платформу уже может отличаться.

З.Ы. Универсализм - зло.
З.З.Ы. В этом ключе всегда умиляет фраза в вакансиях: "знание паттернов проектирования".

SaaBaka писал(а):Ega23
C++ - это что называется craftsman language. Можно очень многое, но нужно чрезвычайно хорошо понимать, что делаешь.

Я в курсе. Именно это и не нравится. Для одиночной разработки ещё куда ни шло, для командной - очень плохо, приходится каждый раз через дебри прорываться.

SaaBaka писал(а):<..> для С++ такое вполне допустимо. <..> Можно очень многое, но нужно чрезвычайно хорошо понимать, что делаешь.

Иногда даже понимание не спасает. Мы очень намучились с подобными кодами, когда переходили с одной архитектуры процессора на другую, а потом с 32 на 64 бита. Потому что было нарисовано очень много кода, построенного на предположениях о том, какие размеры типов, и куда придется указатель и как именно "behavior undefined", да. А ведь можно было и не "оптимизировать", и сократить время (=деньги) на техподдержку, миграцию и дальнейшую разработку. Компилятор ведь очень не дурак, если ему попроще обьяснить что нужно сделать - он и сам оптимизирует враз.

Слушайте, гуру-сишники, а вот объясните мне такую штуку.
Вот есть исходник некой DLL. Есть описалово на экспортируемые функции. можно посмотреть ,как оно устроено "унутре".
Допустим, что некая функция Foo1 может вернуть значения 0, 10, 20, 30, 100.
Допустим, что некая функция Foo2 может вернуть значения 0x0000, 0xFFFF, 0xFFAA.

Заведение типов Foo1_Exit_Code и Foo2_Exit_Code - это общий стиль всех си-программеров, или просто мне так не везло в жизни?

Вообще такая хрень в IRL встречается достаточно редко. В реальных задачах обычно нет условий вида "и все это непременно стоя и в гамаке"...

Потому что было нарисовано очень много кода, построенного на предположениях о том, какие размеры типов, и куда придется указатель и как именно "behavior undefined", да.

Это просто кривой код, оптимизация тут не при чем. Любой кроссплатформенный разработчик знает, что длина/репрезентация/выравнивание типов и endianness могут быть разными.

Компилятор ведь очень не дурак, если ему попроще обьяснить что нужно сделать - он и сам оптимизирует враз.

Ну да. Что касается твоего примера - решение "в лоб" (обычный цикл + использование слова большей ширины для суммы) позволяет компилятору еще и автовекторизацию использовать.

SaaBaka писал(а):Что касается твоего примера - решение "в лоб" (обычный цикл + использование слова большей ширины для суммы) позволяет компилятору еще и автовекторизацию использовать.

Это не интересно. Коммерчески - оправдано. Но не интересно.
А при современных мощностях в 99.99% случаев такая хитрая оптимизация и всякие полу-документированные фичи нафиг не нужны, код должен быть читаемым и простым.

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

SaaBaka писал(а):Обычно - да. И это зависит больше от культуры, чем от языка реализации. На обычном джаваскрипте можно нараз такое написать, что хрен поймешь потом вообще.

Это было про возвращаемые типы данных, или про оптимизацию?

Да, джаваскриптная оптимизация иногда способна вызывать поднятие брови у видавших виды сишников
var b = (a+1)|0;

Ega23 писал(а):Заведение типов Foo1_Exit_Code и Foo2_Exit_Code - это общий стиль всех си-программеров, или просто мне так не везло в жизни?

Это как именно, через "typedef int Foo1_Exit_Code", или через энумераторы/обьекты? Если первое, то может они предполагают подмену типа на этапе компиляции для каждой платформы, которую они собираются поддерживать.. А если возвращаемый код это обьект класса Foo1_Exit_Code, тогда это попытка сделать строгую проверку типов для всех сущностей системы, включая возвращаемые значения. Можно сделать и через обычные энумераторы, но они много от чего страдают. Вылечено через enum class в C++11. "Теперь это - норма!" (с) Малышева

LuckyOne [away] писал(а):Это как именно, через "typedef int Foo1_Exit_Code", или через энумераторы/обьекты?

Отдаваемый объект из DLL - очень плохой тон и чревато опасностями. В библиотеки и приложении могут быть разные менеджеры памяти, может быть разная метода учета счетчиков ссылок для magic-классов и т.п.
С платформами - ну предположим, хотя, ИМХО, очень странное решение, интерфейс экспортируемых функций должен быть единым для всех.

Похоже, я капитально туплю. Ты ж смотришь дебаг информацию напрямую из нестрипнутой библиотеки, так? Тады я тут не копенгаген, там от ваших виндовых форматов и компиляторов зависит что там есть, и как оно поименовано в обьектных секциях. И вообще, правильно говорить .so, а не .dll :)

ЗЫ: А, не, вроде не туплю. "есть исходник" - это сырцы, а не бинарник. Тады всё как выше в посте изложено.

LuckyOne [away] писал(а):ЗЫ: А, не, вроде не туплю. "есть исходник" - это сырцы, а не бинарник. Тады всё как выше в посте изложено.

сырцы - сырцами. Но если надо строку вернуть из библиотеки, то ты же не class string возвращаешь, а указатель на буфер + длину строки. Иначе разврат и коррупция получатся.

Ega23 писал(а):.. если надо строку вернуть из библиотеки, то ты же не class string возвращаешь, а указатель на буфер + длину строки. Иначе разврат и коррупция получатся.

Долго думал. В голом си нету класса стринг, там да - адрес и длину, без вариантов. В плюсах возвращаю обьекты класса стринг, или, что чаще, const ref на оные, если в классе зашиты и пользователю их менять не треба. С более сложным функционалом так и вообще никак без отдачи обьектов. А иначе ведь и смысла в ентом обьектно-ориентированном дезигне нету.

А вот попробуйте о таких вещах подумать с 7-00 по звонку и до 17-00 по плану.
К семи утра надо строго заканчивать подобные размышления.

пс. Кстати, мне требуется программист с сознанием CUDA (и зачем))

dbalka писал(а):мне требуется программист с сознанием CUDA (и зачем))

..и с подсознанием OpenCL или там OpenMP, так? :)

приятно утром говорить со осознающим знающим
вот семь утра -- пора валить, я - завтра почитающий!

Я все пропустил
Давайте еще алгоритмы пощелкаем, а?
На работе предновогодние запары, сидим всем отделом верстаем, лол. Мозг атрофируется слегка.

Радужное оживление раздела некропостом.

Неизвестным анонимом, который после первого поста исчез.

WingRabbit писал(а):Давайте еще алгоритмы пощелкаем, а?

Есть массив INT. Нужно перевернуть его (задом наперёд). Буферные переменные использовать низя..