Неумехи просто станут делать другие ошибки. И опять будут во всём винить компилятор. А больше ничего не изменится.

Ага. Беды начинаются, когда "обучившиеся программированию" начинают на нем программировать .

Вот то, что он создавался для обучения программированию - вот это и есть родимое пятно всех "языков ради языка". Ни Си ни Си++, ни тот же Perl не создавались для обучения, они создавались для РАБОТЫ.

"Мама мыла раму..." © . В реальности, все хуже - не далее, как месяц назад очередная утилитка тупо отказалась запускаться вываливаясь с характерными питоновскими воплями . Утилитка о NXP/Jennic просто командная строка, но зачем то размером 250K и DLL-ок на полмега. За что?

Вот как раз если первый операнд сделать знаковым, то в случае операции ~ красота картинки сохранится:
temp2 = 0xFFFE расширится его до 0xFFFFFFFE, а последующая операция ~temp2 обнулит лишние старшие навязанные два байта.

Поэтому в начальном примере код if(~(signed int16)temp2 !=temp1) continue; даст ожидаемый результат.



Согласно великому классику "В компиляторе все должно быть прекрасно...".
В нашем конкретном случае с логическими побитовыми операциями вынужденность добавления явных преобразований похожих на

наводит на мысль, что некоторые моменты в стандарте шиворот-навыворот.

Сообщение отредактировал aiwa - May 9 2016, 23:31

Стандарт не обязан быть логичным для всех, потому что это стандарт. Однако если вспомнить, что все операции над переменными типа char и short производятся только после приведения к типу int, то многое становится понятным. Почему к int? Потому что существовали и, видимо, существуют архитектуры в которых арифметические операции возможны только для операндов с размером машинного слова, которое и представлено типом int. Иными словами, правила преобразований в С архитектурно зависимы, и в спорных случаях следует использовать явное приведение типов.

Кроме того, попробуйте разобраться, как должны работать следующие операторы:

Бывает хуже. Например IAR выдаёт предупреждение "unreachable code", а Keil то же место тихо-спокойно пропускает.
(прямо относится к исходному мессаджу)

О сколько нам открытий трудных..

Беспредметное, безосновательное утверждение.


Языком для обучения он позиционировался в 1990 году, с тех пор практически сразу стал языком для решения практических задач. Его ни в коем случае нельзя сравнивать с C/C++ - совершенно разные возможности и ниши, но если сравнивать с перлом, то сравнение будет не в пользу последнего.


Понятия не имею, в чём вы. Программа на питоне - это текстовый скрипт. Для исполнения она требует исполняемой среды. Про какие dll речь, мне не ведомо.

Если наводите критику, так делайте это предметно. Конкретно что кривого в питоне, какие косяки в его дизайне. Про Аду не спрашиваю, про неё сам знаю. И Ада - действительно искусственно созданный ЯП по ТЗ МО США. Но питон - нет, у него совершенно другая история и свой путь развития. И питону уже не надо доказывать своё право на существование - он давно это доказал делом. Когда я познакомился с питоном лет 10 назад, так забыл как страшный сон эти sed'ы и awk, и с тех пор все утилиты для себя пишу на питоне, ни разу не пришлось разочароваться. И у всех, кого знаю, кто познакомился с питоном, чем плотнее знакомство, тем выше оценка. Подозреваю, что вы с ним реально почти не знакомы, но пришлось столкнуться с парой образчиков говнокода, отсюда и мнение о языке. Тут можно напомнить, что на сях легко наговнкодить так, что питонам и не снилось. Но это не характеризует сам язык.

Полностью согласен, но мне кажется он должен при возможности следовать канонам формальной логики.
Компилятору желательно еще быть и удобным: повторюсь с примером, когда знаковый тип 'char' компилятор всегда
трактует как 'unsigned char' по желанию пользователя.



Да этот вопрос как бы и не касается архитектуры - только небольшая рокировка явного и неявного преобразования типов исключительно для операции ~: операции результат которой остается в разрядной рамке операнда.
Если компилятор способен сгенерировать ожидаемый код при явном приведении типов ((uint16_t)~temp1), то неплохо бы иметь такую возможность по умолчанию, не мозоля пальцы на явное преобразование и впоследствии глаза при чтении текста.
Для полноты картины при бинарных операциях неплохо бы проводить расширение к большему по размеру операнду.



Все довольно просто: результат (unsigned short+unsigned short) не будет 'unsigned short' потому что операция суммирования выходит за пределы разрядной сетки 'unsigned short' и результат будет зависеть от архитектуры в согласии с правилами целочисленного расширения.

Сообщение отредактировал aiwa - May 10 2016, 08:05

Тип char можно назвать знаковым только по неведению. Не забивайте себе голову лишними предрассудками, а просто загляните в стандарт. Да, неопределённость в вопросе знаковости типа char раздражает. Видимо, есть "исторические причины". Тем не менее, с типом char не надо делать арифметику. Тип char - он для букв, а не чисел.


Код, который для вас кажется ожидаемым, для кого-то другого легко может быть неожиданным. Логика стандарта при приведении типов абсолютно понятна: она заточена под традиционную арифметику с числами. Операции над битами - это нечто иное. Ну что ж, привыкайте. Почитайте стандарт, и тогда компилятор не будет выдавать "неожиданный код".

Пример немного не об этом, но уж раз вы завели речь о разрядной сетке - при использовании uint8_t вместо short все равно будет расширение типа до int, хотя результат помещается в short.


Это, конечно, жуткий оффтопик, но здесь с вами согласен - сравнивать питон следует только с перлом или авк.



Претензий к нему не много, но они вшиты намертво и меняться не будут:

отвратительный дизайн ООП модели (числа и строки не являются объектами, никуда не годный синтаксис доступа к родительским классам - сравните с C++);
очень медленные треды (из-за кривого дизайна интерпретатора), решается вывертами типа мультипроцессинга;
global/nonlocal - это вообще без комментариев;
де-факто существуют две несовместимые версии языка: python2/python3, а так-же наблюдается антагонизм сторонников как первого, так и второго;
однострочные лямбды - ограничение, видимо, произрастает из семантической значимости величины отступа.

Мы попытались перенести проект написанный на C++ и убедились, что овчинка совершенно не стоит выделки. А вот для скриптов, тест-модулей и прочих несложных программ питон подходит просто идеально, но здесь с ним в конкуренцию вступает Ruby.

Я не имею ввиду себя или еще кого-то конкретно. Ожидаемый - с точки зрения формальной логики: если b=~а то-> ~b == а.


Я описал только первый вариант Вашего примера потому что для второго, где short, действия совершенно аналогичны - в силу того, что разряд суммы выходит за пределы двухбайтной сетки.
Но в обоих случаях тип операнда для ~ уже не является типом разрядности short по априори, до выполнения самой арифметической операции с необходимостью расширения операндов.

В принципе, все сводится к случаю, когда источником операнда для ~ является lvalue-значение.

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

Увы, но для меня лично основаним является то, что за всю жизнь я ни одной вменяемой программы на питоне не встретил . Я понимаю, что мой личный опыт не может претендовать на всеобъемлимость, но тем неменее .

Прямо противоположного мнения . Он базируется на слишком небольшом, но все ЛИЧНОМ опыте копания и ОБИЛЬНОЙ доработки питоновских и перловых текстов.

Я говорю об откомпилированных в EXE питоновских исходниках.

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

С этим спору нет .


И до кучи принципиальное отсутствие стандарта языка .

Э-э.., простите, но как вы сравниваете несравнимые вещи? Ответьте для начала на вопрос: что является классом в С++ и что является классом в Питоне? Правильный ответ вам сразу покажет, что вы просто пытаетесь юзать классы Питона точно так же как классы С++. А у них общего только название.


Треды как треды. Всё обычно для интерпретируемого языка. Или вы его С++ опять сравниваете?


Тут не понял.


Насчёт антагонизмов информация устаревшая. В бытность появления тройки, когда она была сырая и глючная, народ плевался, т.к. оные глюки и недоделки мешали работать. Но начиная с версии 3.3+ всё стало пристойно. То, что они отделили развитие, момент спорный, но как показывает практика, решение было скорее правильным, чем не. Можно было и дальше тащить совместимость, как это делает С/C++, обрастая диалектами и поддерживая кривизну исходного дизайна языка, но они решили пофиксить т.н. "бородавки" языка, что привело к некоторой несовместимости. В реальности можно пользоваться и тем, и другим (там немного отличий, на моём уровне так вообще кроме как то, что оператор print сделали функцией, разницы нет), новые вещи лучше писать сразу под тройку.



Не очень понял, что вы пытались сделать. Просто тупо переписать код С++ на Питон? Зачем? Какой выигрыш вы ожидали от этого? Работать будет медленнее, это очевидно. Хотели лёгкости модифицирования кода? Но так и код должен быть по-иному организован. Просто тупо портировать С++ код на Питон не получится - ЯП с совершенно другими парадигмами, требует другие подходы, даёт иной выигрыш. Лучшее, что можно было сделать - это внедрить Питон в С++ программу как embedded движок для решения определённого класса задач, если таковые имеются, и которые эффективнее решаются на Питоне.


Так Питон и есть скриптовый язык. Насчёт несложных, это пардоньте, от подхода и целей зависит - очень неслабые приложения на нём пишут и делают это весьма эффективно. Руби - да, конкурент, с Руби Питон можно сравнивать, но не с С++ ни разу. Питон правильно было бы сравнить с языком Матлаба, только Питон шире, гибче и мощнее. Не приходит же в голову сравнивать язык Матлаба с С++ и потом ругать его за то, что плюсовая программа плохо ложится на m-файлы.

Они вполне сравнимы, отличается реализация, добавляется возможность расширения классов и динамическое разрешение методов, но сути это меняет. Если по смыслу задачи требуется иметь четырехуровневую иерархию, то ее придется реализовать или заменять разными костылями. А далее мы с удовольствием ругаем конструкцию вида super(MyClass, self) или изучение списка self.__class__.__bases__. Кому как, а мне такой подход кажется излишне сложным для скриптового языка. Туда же отнесу и бесконечные self.



Да, я сравниваю эффективность реализации. Погуглите про global interpreter lock.



Никому не нужные ключевые слова из-за изначально плохо продуманной концепции видимости переменных.



Тот факт, что на машине приходится держать оба варианта, говорит сам за себя.


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



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

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

По поводу вумного ИАРа, выкинувшего ветвь исходника, топикстартер правильно поднял тему. Отсутствие предупреждения "unreachable code" тянет на недоработку компилятора. Несложно вставить это ругательство в алгоритм компилятора во все места, где удаляется ветвь кода. Конструктивных возражений здесь не видно. Проглядели, вероятно.

На счёт вырождения выражения с переменными или результатами функций в константу ситуация более сложная. В той же неразрывной ветви алгоритма, ранее, могла быть запись константы в переменную. И результат выражения с этой переменной умный компилятор мог бы опознать как константу. Но это вариант нормы Си-кода и на это даже ремарку нет оснований выдавать. В каких-то других случаях замечание компилятора было бы полезным. Но где-то его сообщая, а где-то умалчивая разработчики компилятора могут встретить законное недовольство юзеров. Хотя могут и помочь увидеть кривизну в исходнике.


Это из другой оперы.

Странное сообщение. Для if. Точнее для сравнения (в худшем случае) знакового rvalue и беззнакового.

С инверсией (~, тильда) (не читал стандарт, но судя по этому обсуждению) в стандарте есть кривизна в том, что два раза может происходить расширение операнда. Сперва до int, потом до ширины второго операнда, если он шире. Это немного криво само по себе и из-за разной ширины int на разных платформах. Но если так исторически сложилось, то это уже навсегда. Гарантированную мультиплатформенную совместимость некоторых выражений с тильдой остаётся делать явным приведением.





Идеально всё-равно не получится. Чуть менее криво или чуть более в таких выражениях. В комбинации с другими операторами будет новая кривизна. Захочется ведь ещё беззнаково расширять.

Сообщение отредактировал GetSmart - May 11 2016, 06:18