IT в России и мире в реалиях мирового кризиса
1,291,108
7,816
|
Superwad ( Слушатель ) |
| 29 дек 2016 16:43:12 |
Стандартизация С++ - существет только на бумаге
новая дискуссия 581
Это горький факт. Теоретически и на бумаге С++ - стандарт, (как, например, и стандартизирован формат документов MSOffice), но когда доходит до дела, то имеем, что библиотека откомпилированная С++ не вызывается из других программ как положено (не С++), то оказывается, что реальные форматы существующих MSОффисов им не соответствуют.
Так что теория и жизнь - это разные вещи
Так что теория и жизнь - это разные вещи
ОТВЕТЫ (25)
|
adolfus ( Слушатель ) |
| 01 янв 2017 09:23:51 |
Цитата: Superwad от 29.12.2016 13:43:12
Какие-то глупости Вы говорите. Стандарт ISO/IEC 14882 не касается результатов компиляции, а всего лишь синтаксиса языка и того, что каждый элемент его должен делать. Собственно, как и все остальные стандарты на языки программирования. Результатом компиляции является объектный модуль. Форматов объектных модулей несколько и все они жестко стандартизованы. Но формат объектных модулей никакого отношения к стандарту ISO/IEC 14882 не имеет. Объектные модули могут быть организованы в библиотеки, которые опять же имеют разный формат. Одним словом, не несите чепуху, а просто ознакомьтесь со стандартом. В конце концов есть хорошие книги
Другое дело, что некоторые компиляторы не поддерживают некоторые элементы стандарта или поддерживают частично. Этим особенно страдают компиляторы Микрософт. Поэтому у многих из тех, кто пользуется виндовсами возникает такое же впечатление, как у Вас. При этом с++ и с являются самыми переносимыми языками.
|
|
Superwad ( Слушатель ) |
| 09 янв 2017 14:31:44 |
Цитата: adolfus от 01.01.2017 06:23:51
Если все так хорошо на бумаге, то почему так хреново на практике ?
Зы. Компилировал на Линуксе.
PSS. Попробовав С++ - не хочу -нафиг нафиг сей геморрой. Преимуществ никаких, а геморра море....
|
|
adolfus ( Слушатель ) |
| 09 янв 2017 23:17:21 |
Цитата: Superwad от 09.01.2017 11:31:44
На практике хреново только у Вас, а у миллионов все получается и они получают эти самые преимущества в полном объеме безо всякого геморроя. Может проблема не в языке? И бумаги Вы не те читаете? Стандарт у вас есть?
|
|
Valery ( Слушатель ) |
| 10 янв 2017 04:23:44 |
Цитата: adolfus от 09.01.2017 20:17:21
Ну, практика показывает (прогон через IDA некоторых программ), что С++ за счет разных "виртуальных функций" и прочей хрени способен не только похерить все преимущества VLIV, но и массовым ARM и x86/x64 голову свернуть на тему предсказания переходов и проч... То есть, процессор греет воздух вместо того, чтобы радовать меня ростом производительности.
С моей точки зрения, даже С++ конца 80-х годов был гораздо более логичным и предсказуемым.Про Жабы, Шарпы и подобную хрень я вообще молчу. Программист должен понимать, что будет делать железка. Я уже сталкивался со студентом, который не понимал, как работает ввод-вывод на компьютере. Он очень удивлялся, когда его-же программа, слегка поправленная, начинает работать в разы быстрее.
|
|
adolfus ( Слушатель ) |
| 10 янв 2017 11:53:25 |
Цитата: Valery от 10.01.2017 01:23:44
Никто никого не заставляет использовать тяжелые возможности С++. А вот то, что "программист должен понимать, что будет делать железка" -- это в точку.
|
ИвaнычЪ ( Слушатель ) |
| 10 янв 2017 13:38:15 |
Сообщение удалено
ИвaнычЪ
10 янв 2017 14:21:39
ИвaнычЪ
10 янв 2017 14:21:39
Отредактировано: ИвaнычЪ - 10 янв 2017 14:21:39
|
|
Superwad ( Слушатель ) |
| 12 янв 2017 18:20:29 |
Цитата: adolfus от 09.01.2017 20:17:21
Миллионы людей употребляют алкоголь. Алкоголь очень полезный продукт, миллионы людей не могут ошибаться ! (с). Из народного.
Объясните, зачем для большинства задач (а большая часть - то прикладные задачи!) - нужен очень сложный с высокими требованиями С++, если вполне хватает и того же FPC (Паскаль)? Причем с меньшими затратами и дешевле, чем на С++.
А FPC великолепно переносится на разные платформы. Я часть программы делал на Винде, потом докомпилировал на Линуксе и все работало.
Да, условную компиляцию под платформу никто не отменял.
Мантры С++ - это стандарт, на практике не работают. Это полное фуфло. Как говорят на заборе написано, а за ним дрова лежат. На бумаге все красиво,а в жизни совсем не торт. а полный гемор. Нафиг.
|
|
Superwad ( Слушатель ) |
| 13 янв 2017 12:38:11 |
Цитата: adolfus от 12.01.2017 16:11:20
Как раз мне осилить С++ без проблем, но вот вопрос а нафига мне такая геморроина на пятую точку?
Вот и пытаюсь узнать, чем так крут С++ по сравнению с более простым языком, тем более что результат на выходе получается одинаковым, а затраты РАЗНЫЕ.
|
mrt789 ( Слушатель ) |
| 12 янв 2017 19:13:26 |
Цитата: Superwad от 12.01.2017 15:20:29
Язык без фигурных скобочек не взлетит...
А уж если ноги растут из Вирта - не взлетит тем более. Карма у дедушки не той системы.
|
slavae ( Слушатель ) |
| 12 янв 2017 19:39:15 |
Цитата: mrt789 от 12.01.2017 16:13:26
Всё там как надо. Впрочем, в Паскале тоже есть фигурные скобочки )))
|
|
Superwad ( Слушатель ) |
| 13 янв 2017 12:42:48 |
Цитата: mrt789 от 12.01.2017 16:13:26
И чем скобки лучше, чем естественное описание логики привычными словами?
Вы хоть Вирта читали, почему был создан язык Паскаля? Для обучения людей программированию в ПРИВЫЧНОЙ СРЕДЕ . А то что выдает С++ эт только для маргиналов, а остальным?
Кстати, можно вполне и без ООП программировать, тот же С для Apple великолепно это показывает.
{Пожимая плечами}
У меня есть программы, которые используют многопоточность (из-за оптимизации времени выполнения) - и это все сделано на Паскале.
Была одна программка, которая считывала данные из АЦП, буферизировала и сохраняла в БД в режиме реального времени (естественно, многопоточном режиме). Там был буфер, который сам следил за своим размером, считывание и запись в БД. И работало все на 5 баллов (да еще и под Линуксом). написано было на Lazarus. Так может дело не только в языке а в нормальным мозгах? Просто у меня программирование это дополнение к основной работе (облечение рутинной дел) и скорость разработки (особенно отладки) мне критично. Поэтому чем проще и надежнее инструмент - тем для меня лучше. А вот С++....
|
Поверонов ( Слушатель ) |
| 14 янв 2017 21:37:44 |
Цитата: Superwad от 13.01.2017 09:42:48
Занудства ради Apple использует
Цитата: ЦитатаObjective-C - компилируемый объектно-ориентированный язык программирования, используемый корпорацией Apple, построенный на основе языка Си и парадигм Smalltalk. В частности, объектная модель построена в стиле Smalltalk — то есть объектам посылаются сообщения.
|
|
TAU ( Слушатель ) |
| 13 янв 2017 19:03:27 |
Цитата: mrt789 от 12.01.2017 16:13:26
А Вы слышали, что на Модуле-2 и на Обероне разработаны многие критически важные приложения?
|
|
Yuri__1964 ( Слушатель ) |
| 13 янв 2017 06:18:34 |
Цитата: Superwad от 12.01.2017 15:20:29
Так прикладные задачи никто сейчас на С++ и не делает, есть C#, Java, JavaScript ну и т.д.
|
Lapsha ( Слушатель ) |
| 13 янв 2017 06:57:16 |
|
|
folk ( Слушатель ) |
| 13 янв 2017 11:12:57 |
Да Вы батенька дальше своего носа то не смотрите) Если Вы не делаете не значит никто - разве можно этого не понимать?
Возьмем например любой САПР - Pcad, AutoCad, SolidWorks, Synopsys. Назовите пожалуйста версию на C# Java и особенно JavaScript - мож мы тут и правда от жизни отстали. Численные расчеты конечно тоже на C# пишут, чтобы на суперкомпьютеры Windows протащить?
Нормальному профессионалу наверное должно быть одинаково удобно писать на всех этих языках. Тогда можно будет выбрать под задачу решение. Но такой максимализм как в вашем суждении - это круто..
|
|
adolfus ( Слушатель ) |
| 14 янв 2017 06:44:00 |
Вы не представляете, что такое прикладные задачи. Перечисленные Вами языки даже не упоминаются в процессе формирования ТЗ на разработку более-менее серьезных систем. Просто потому что через 15 лет код, написанный на них, хрен чем соберешь. А на код крестах, написанный в 1998 году я спокойно собираю сегодня и он спокойно отрабатывает на абсолютно другой архитектуре. Но код на жабе, написанный всего 10 лет назад, запустить невозможно было уже через пять лет -- переписывали на крестах. И ходит этот парсер сегодня и под 32 бита, и под 64, под любым линуксом и любыми виндами, а написанный на жабе ходил только под вистой и ни под чем больше.
Классическая прикладная задача средней сложности -- система сбора теоеметрии с колонны на нефтеперегонном заводе. Или система сбора телеметрии с турбины ТЭЦ или парогенератора. Система анализа телеметрии за несколько лет и прогнозирования состояния той же турбины -- задача уже высокой сложности, в том числе и вычислительной. Система управления аэродромным хозяйством -- очень сложная система. Я даже предположить не могу, что можно написать на диезе или жабе, разве сто магазин какой-нибудь или курсач по хелловорду.
|
|
Yuri__1964 ( Слушатель ) |
| 14 янв 2017 07:00:53 |
Цитата: adolfus от 14.01.2017 03:44:00
А в чём проблема написать систему управления аэродромным хозяйством на C#?
|
|
adolfus ( Слушатель ) |
| 14 янв 2017 08:17:24 |
Прежде всего в том, что нет стандарта на C#. Мало того, нет даже вменяемых спецификаций, относительно которых была бы уверенность, что они будут кем-то поддерживаться. Аналогично с жавой -- постоянно что-то меняется и код, написанный пять-семь лет назад, уже не ходит без того, чтобы в нем не ковыряться.
Одним словом, нет стабильности.
В то же время код на си, написанный в 80-х годах, я откомпилирую и соберу современным gcc под любую архитектуру, включая шиндовсы любого разлива. Я им откомпилирую и соберу любой работающий код на си и крестах, если он соответсвует тому стандарту, который существовал в момент его написания. Т.е. если код компилировался, собирался и работал десять лет назад, он заработает и сегодня. И это не потому, что gcc такой крутой, а всего лишь потому, что есть стандарт, а те, кто за него отвечает, делают свою работу в части mandatory довольно неплохо. Разработчикам же компиляторов и библиотек, которые есть часть стандарта, остается брать под козырек и только. С диезом и жабой все совершенно по другому.
|
|
Superwad ( Слушатель ) |
| 17 янв 2017 13:20:45 |
Цитата: adolfus от 14.01.2017 03:44:00
Сбор данных - обычная задачка. Самая сложная часть - это непосредственный опрос данных с АЦП, а дальше - элементарно - буфер и запись в БД. Я такое делал на Паскале - как раз часть опроса АЦП была на С++, с которой невозможно было получить данные, пока не приделал костыль. Работало многопоточно и со свистом.
Вообще, самая кошерная постановка задачи - это получить данные и закинуть в БД. Если нужен анализ - ну так строить графики и анализировать проще при работе с БД, чем с обычным файлом, а это значит, что огромных ресурсов памяти не надо при таком подходе. А если набор данных еще и не меняется (структура, так как количество датчиков конечно и постоянно во времени), то динамический буфер памяти с повторным использованием выделенных ячеек памяти очень ускоряет работу. И Паскаль не уступит по скорости работы С++, который будет постоянно гонять выделение и освобождение памяти.
|
|
DarkRaider ( Слушатель ) |
| 18 янв 2017 02:47:00 |
Цитата: Superwad от 17.01.2017 10:20:45
Ну это Вы, любезный, несколько опрометчиво написали. Я понимаю, что работа накладывает отпечаток и эта область Вам ближе, но не стоит быть столь категоричным. Самая сложная часть любой математики - аналитическая и расчётная, даже в случае с БД, анализ данных начинает преподносить сюрпризы при росте размеров входных данных.
Цитата: ЦитатаPSS. Я использую Lazarus потому, что время - деньги. У меня это не основной хлеб, потому сидеть и копаться в С++ коде - мне непозволительная роскошь.
Несмотря на то, что для большей части не системного приклада мне удобней Паскаль, я не склонен столь превозносить Lazarus, там ошибок, пожалуй, поболе чем в тех же Делфях будет, причём спотыкается он иногда на совершенно обыденных вещах. Имхо - что со времён Borland Delphi приходилось в процессе работы баги в vcl или какой нибудь Indy чистить долго и упорно, что сейчас в RAd студио, что в Lazarus - залог "работы как часы" - это долгие часы(если не годы) кропотливой работы по вылизыванию библиотек, дописыванию своего инструментария и оптимизации от проекта к проекту. "Из коробки" часто натыкаешься на некорректную работу. Причём в open source - это, на мой взгляд, в n раз чаще.
|
|
Superwad ( Слушатель ) |
| 20 янв 2017 12:35:20 |
1) Правильные американские программисты столкнулись с проблемой больших данных очень давно и для решения этого вопроса использовали базы данных (SQL сервера). История InterBase как бы про это говорит - там появилась подписка на события (очень полезная вещь!), для лаборатории что снимала показания с датчиков в ячейки можно записывать массивы! Так что от алгоритма обработки многе зависит. А обрабатывать данные из SQL сервера - это уже намного другая по сложности задача. Уже легче.
2) Как то столкнулся подобрать программу для видеомонтажа (смотрел коммерческие). 99 % программ откровенно барахло - не, задачу свою решают, но ресурсов жрут немеряно. И только, Sony Vegas - самая крутая (РЕАЛЬНО КАЧЕСТВЕННО НАПИСАНА!!!) программа, которая рационально используя ресурсы, быстро выполняет поставленные задачи.
А тут ещё народ приводит пример, что для нормальной работы надо вначале переписать с 0 библиотеки для С++. Как бы история создания Qt это подтверждает. Так что не все так однозначно.
Вот про качество кода и и говорю, что в настоящее время это большая проблема. Как платного, так и свободного софта. Да и Lazarus я стал использовать от проблемы кроссплатформенности Delphi. Да, есть вопросы с качеством библиотек в Lazarus, очень не хватает некоторый функций CnPack, но можно писать и на нем неплохие программы. У меня работают. Да и с каждым годом немного подчищают Lazarus.
Большой плюс open source - это если что, можно самому подрихтовать, благо есть исходники...
А если брать Линукс, то на 80 % код написан за деньги...
|
|
ИвaнычЪ ( Слушатель ) |
| 10 янв 2017 13:11:20 |
Цитата: Superwad от 09.01.2017 11:31:44
Если б Вы писали на линуксе и не просто на лине, а под определённый компилятор, а потом свой код попытались бы скомпилить в другом, то навернякак какие нибудь траблы бы выскочили. На винде то же самое. Код от одной студии на другой с траблами компилится или вовсе не компилится! Допиливать по конкретный компилятор/стандарт/мелкомягкие траблы надо, приведение типов и т.д..
Линукс, Виндовс или ещё что - тут без разницы - версия компилятора, компилятор сам важнее. Он компилирует, а не ось.
Помимо этого есть, вестимо , траблы с дровами под операционныес системы. Например относительно недавно нашёл код программы , мне интересной, 3D графики под опенжл стандарта 3.3 - 4 . Только карточка видео у меня была амд/ати, а код заточен был под энфидю. У энвиди отход от строгих стандартов, и код соотв. На моей карте ошибок куча была в винде - никак не смог перепилить(т.е. там просто всё! переписывать надо по уму). К своему удивлению тот же код скомпилил на ёбунте и, о чудо!, заработало как на энвиди. Это траблы драйверов амд/ати. При чём не документированные!!!!
Сам Си, Си++ тут ни при делах.
|
|
adolfus ( Слушатель ) |
| 10 янв 2017 19:20:35 |
Цитата: ИвaнычЪ от 10.01.2017 10:11:20
Если писать в рамках стандарта, то риск нарваться на проблемы с переносом на другую платформу минимальный. Проблемы возникают там, где специально делается все, чтобы чтобы держать разработчиков на коротком поводке непереносимости кода. В настоящее время основным источником принципиальной непереносимости является работа с файловой системой. Интерфейс, благодаря qt и wxwindows, выскочил из этого капкана. Что касается файловой системы, то проблема имеет место лишь при портировании кода из виндовс в линукс. Но можно просто забить на visual c и работатьс любым другм компилятором, благо их есть. Тем более, что visual c -- самый убогий и глючный среди всех.