Здравствуйте, Marty, Вы писали:
M>Для обывателя это примерно одно и то же
Кто именно здесь обыватель — Вы, я, или типичный программист для AVR?
M>через много лет после того, как появились плюсики, писать на них под ардуинку научили даже домохозяек. А на сишечке или на питоне — писать под ардуинку как-то не особо домохохяек получилосьнаучить.
Насколько я знаю, домохозяйки пишут для Arduino исключительно простенькие скетчи, пользуясь крайне примитивным подмножеством C++ — примерно на уровне бейсика. Это как про забивающего микроскопом гвозди говорить, что он "занимается микроскопией".
M>их вполне можно было использовать для любых низкоуровневых задач. Просто раньше их надо было уметь немного лучше готовить.
Чтоб использовать плюсы для серьезных низкоуровневых задач в самом начале 90-х, их нужно было готовить столько, что быстрее и проще было писать на C. Тогда даже в "C с классами" были подводные камни вроде порядка вызова конструкторов/деструкторов, тонкостей преобразования типов при выборе перегруженных функций и т.п., а уж шаблоны только-только появились, и оптимизации для похожего кода практически не было.
M>и на плюсах можно написать кривой и тормозной софт. Как и на любом другом языке
Парадигма плюсов этому очень способствует. Я не раз слышал в свой адрес упреки в том, что якобы "пищу не на плюсах", ибо использую их "не в соответствии с парадигмой". Но я свободно могу послать любого автора такого упрека, и продолжать дальше писать, как считаю нужным, но большая-то часть софта делается корпоративно. И наверху обычно сидят идеологи, которые говорят всем: "все должно быть кошерно". Там, где типичный сишник обошелся бы небольшой функцией, а то и вовсе макросом, такие идеологи постановляют разработать отдельный класс, сделать для него спецификацию интерфейса, предусмотреть, чтобы класс можно было использовать в гипотетических ситуациях и т.п. Там, где напрашивается сугубо локальное решение, они требуют придумать самостоятельную сущность в парадигме ООП. В итоге получается код, который, грубо говоря, чтобы сложить два и два, создает объекты "два" и "два", ставит их в очередь к объекту "калькулятор", посылает тому сигнал, что нужно провести вычисление, и ждет результата. В какой-то момент исполнители перестают понимать грандиозный замысел идеологов, и начинают плодить отсебятину. В итоге получается очередной монстр, а в его проблемах обвиняют язык.
M>а что восьмидесятые?
То, что C долгое время удавалось развиваться в стиле "если это можно сделать просто, давайте так и сделаем", а C++ с почти самого начала тянули на себя минимум три группы: любители простых и внятных языков типа C, любители тяжеловесных языков типа PL/1 или Algol-68, и любители функциональных языков. Пока то, что все они натолкали в язык на первых порах, более-менее не устаканилось, использовать его для серьезных долгоживущих проектов, не имея собственного компилятора, было рискованным делом.
M>Да ваще насрать.
Ну вот — Вам насрать на 30%, кому-то — на 70%, а кому-то и на 300%, ведь пипл хавает. В Штатах производителям автомобилей когда-то тоже было насрать на расход в 25 литров на сотню, а потом времена изменились, и японцы, которых тогда никто не воспринимал всерьез, внезапно отжали изрядную долю рынка.
M>Особенно, если чтобы сэкономить эти 30%, мне надо будет жмыхаться на чистой сишечке в 10-20 раз дольше.
Вам кто-то предлагает жмыхаться на чистой сишечке?
Re[23]: Можно ли сделать универсальный шаблон для разных комб
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Кто именно здесь обыватель — Вы, я, или типичный программист для AVR?
По тношению к AVR — я типичный обыватель, так как кроме как в ардуинской студии ничего под них не писал. Когда заинтересовался поплотнее — сразу на STMки пересел и реальные задачи
ЕМ>Насколько я знаю, домохозяйки пишут для Arduino исключительно простенькие скетчи, пользуясь крайне примитивным подмножеством C++ — примерно на уровне бейсика. Это как про забивающего микроскопом гвозди говорить, что он "занимается микроскопией".
Я, как домохозяйка, писал вполне не приметивные скетчи
ЕМ>Чтоб использовать плюсы для серьезных низкоуровневых задач в самом начале 90-х, их нужно было готовить столько, что быстрее и проще было писать на C.
Только не говори, что тебе 60+. Иначе — ты застал примерно тоже, что и я. А в 95ом я учился в техникуме на первом курсе, и старшекурсники бегали и кричали (по поводу выхода Turbo/Borland C++ 3 — не помню, вроде было и то и то, и разное, но могу с Turbo C/Borland C путать — на Турбо Си пописал уже в более зрелом возрасте) — так вот, кричали, что это огонь и пипец какой прорыв
ЕМ>Тогда даже в "C с классами" были подводные камни вроде порядка вызова конструкторов/деструкторов, тонкостей преобразования типов при выборе перегруженных функций и т.п., а уж шаблоны только-только появились, и оптимизации для похожего кода практически не было.
Да не было ничего такого особенно подводного, я на BC++3.1 немало кода наколбасил. Всё что было — оно и сейчас практически такое же. И с шаблонами было нормально, и STL уже была, но да, про SFINAE я тогда не слышал. И с качеством кода было норм (по скорости, баги кодогенератора тогда встречались чаще)
M>>и на плюсах можно написать кривой и тормозной софт. Как и на любом другом языке
ЕМ>Парадигма плюсов этому очень способствует. Я не раз слышал в свой адрес упреки в том, что якобы "пищу не на плюсах", ибо использую их "не в соответствии с парадигмой". Но я свободно могу послать любого автора такого упрека, и продолжать дальше писать, как считаю нужным, но большая-то часть софта делается корпоративно. И наверху обычно сидят идеологи, которые говорят всем: "все должно быть кошерно". Там, где типичный сишник обошелся бы небольшой функцией, а то и вовсе макросом, такие идеологи постановляют разработать отдельный класс, сделать для него спецификацию интерфейса, предусмотреть, чтобы класс можно было использовать в гипотетических ситуациях и т.п. Там, где напрашивается сугубо локальное решение, они требуют придумать самостоятельную сущность в парадигме ООП. В итоге получается код, который, грубо говоря, чтобы сложить два и два, создает объекты "два" и "два", ставит их в очередь к объекту "калькулятор", посылает тому сигнал, что нужно провести вычисление, и ждет результата. В какой-то момент исполнители перестают понимать грандиозный замысел идеологов, и начинают плодить отсебятину. В итоге получается очередной монстр, а в его проблемах обвиняют язык.
Так ты и обвиняешь. Почему на чистой сишечке нельзя такой фуеты наворотить? GObject'ы видел? А если покажу?
M>>а что восьмидесятые?
ЕМ>То, что C долгое время удавалось развиваться в стиле "если это можно сделать просто, давайте так и сделаем", а C++ с почти самого начала тянули на себя минимум три группы: любители простых и внятных языков типа C, любители тяжеловесных языков типа PL/1 или Algol-68, и любители функциональных языков. Пока то, что все они натолкали в язык на первых порах, более-менее не устаканилось, использовать его для серьезных долгоживущих проектов, не имея собственного компилятора, было рискованным делом.
И что? Мысль куда-то потерялась
M>>Да ваще насрать.
ЕМ>Ну вот — Вам насрать на 30%, кому-то — на 70%, а кому-то и на 300%, ведь пипл хавает. В Штатах производителям автомобилей когда-то тоже было насрать на расход в 25 литров на сотню, а потом времена изменились, и японцы, которых тогда никто не воспринимал всерьез, внезапно отжали изрядную долю рынка.
Прикинь, я вообще на плюсиках себе ни в чем не отказываю, размер аппы уже за два метра перевалил, и я таки думаю отжать некоторую долю того рынка, куда прицелился
На жиэс в электроне наверное за пару месяцев можно было бы сделать, я уже больше 4х пилю, но размер как дистра, так и по ОЗУ был бы в лучшем случае раз в 20 больше.
Писал бы на жиэс — уже бы начал отжимать рынок, но плохонько. На плюсах расчитываю отжать больше. И даже 300% сгенерированного кода меня не пугает. Всего-то шесть-семь метров вместо двух. Меня больше пугает проблема, что дистр размером в 5-10 метров будут считать "несолидным", что может отпугнуть некоторую часть пользователей.
M>>Особенно, если чтобы сэкономить эти 30%, мне надо будет жмыхаться на чистой сишечке в 10-20 раз дольше.
ЕМ>Вам кто-то предлагает жмыхаться на чистой сишечке?
Напрямую — нет. Но я не вижу проблемы в "бесовских" шаблонах, которые ты так не любишь. И если эти шаблоны мне экономят время — то я буду их использовать.
Более того. Не всегда обязательно даже понимать досконально, как оно работает внутри, особенно — если просто пользоваться. Я как-то перепилил и немало дополнил под себя одну большую шаблонную либу на C++0x03, так и не поняв до конца, как оно там всё работает Сейчас бы, наверное, разобрался бы, но лень. Работает — и ладно
А если проблема в том, что у тебя плюсики старые — то и на них можно сделать свои traits для конвертации, делов на 10 минут, и без всяких залезаний в дибуны плюсиков, банальными специализациями (тут только надо, чтобы базовая реализация ломала компиляцию, и добавлять специализации по мере надобности)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я хорошо помню, какими уродливыми и тормозными они были еще на стыке 80-х и 90-х. Если какой-то софт был толстым и/или тормозным, и при этом не был написан на каком-нибудь FoxPro или Clipper, он чаще всего был написан на плюсах.
Простите что вмешиваюсь в ваш спор, но это все происходило в СССР? И много вы софта на C++ видели в СССР на стыке 80-х и 90-х? На какой платформе?
В то, что в СССР в 1989-м или 1990-ом многие пробовали Prolog поверю, а вот в то, что пробовали использовать C++, да еще чтобы и софт на нем был массовым... Не припоминаю такого.
Re[24]: Можно ли сделать универсальный шаблон для разных комб
Здравствуйте, Marty, Вы писали:
M>Только не говори, что тебе 60+.
55.
M>в 95ом я учился в техникуме на первом курсе
А я занимаюсь программированием с 1980-го. С 1982-го — на ассемблерах и в многопоточках, с 1985-го — под ядра ОС.
M>старшекурсники бегали и кричали (по поводу выхода Turbo/Borland C++ 3 — не помню, вроде было и то и то, и разное, но могу с Turbo C/Borland C путать — на Турбо Си пописал уже в более зрелом возрасте) — так вот, кричали, что это огонь и пипец какой прорыв
Так и у нас кричали — "виртуальное наследование, шаблоны, оптимизация, все дела!". А вместе с этим страдали, что совместимость плохая: у BC одни особенности, у MS — другие, у Watcom — третьи, и за пределами "C с классами" начиналось хождение по граблям. А навороченные кусты из шаблонов, которые тогда как раз входили в моду, при тогдашней скорости компилировались чертовски медленно, и выдержать это могли лишь сугубые энтузиасты, которым шашечки были важнее, чем ехать.
M>Да не было ничего такого особенно подводного, я на BC++3.1 немало кода наколбасил.
Переносить под другие компиляторы пробовали?
M>И с качеством кода было норм (по скорости, баги кодогенератора тогда встречались чаще)
С качеством кода, как такового, по скорости в C++ никогда не было проблем — ни один мало-мальски вменяемый компилятор неспособен породить код, который невозможно контролировать. Дело, повторяю, в парадигме программирования. В чистом C зависимость объема кода от объема исходников линейная, если не используются совсем уж навороченные макросы. Поэтому типичный сишник более-менее представляет, какой прирост объема кода и накладных расходов даст тот или иной прирост объема исходников. В C++ за счет метапрограммирования зависимость может быть хоть экспоненциальной. Большинство примеров вида "смотрите, какая у нас навороченная конструкция, и какой эффективный получился код" либо были тщательно выверены, либо просто удачно совпали с возможностями оптимизации. Когда на C++ вместо программирования начинают "записывать алгоритм средствами языка", на выходе могут получиться излишки по объему и задержкам в сотни, тысячи и более процентов. Пока кому-то не придет в голову запустить профилирование, посмотреть ассемблерный листинг, "поковырять MAP-файл", все будут считать, что так и надо — "работает же".
Одним из хороших примеров такого подхода был Turbo Vision, из которой потом сделали Object Windows, а у MS — MFC. Со стороны исходников и документации все красиво и кошерно — "всё есть объект", везде динамическая память и полиморфизм, обработка событий вешается куда угодно и т.п. Простые приложения на них выглядели действительно просто и изящно, работали быстро, наводя на мысли, что так будет всегда. Но, по мере роста объема исходников, внутренних связей и усложнения взаимодействий, накладные расходы росли лавинообразно. Какой-нибудь чисто косметической правкой можно было легко получить кратный рост тормозов, и приходилось долго прослеживать цепочки своих и внутренних зависимостей, в которых и сами разработчики ориентировались с трудом.
M>Почему на чистой сишечке нельзя такой фуеты наворотить?
Можно, конечно, я тоже знаю примеры. Но и там это возможно в основном за счет подхода — "пишем на C в стиле <язык/технология, которые считаем крутыми>". То есть, сперва на C нужно создать "инфраструктуру", "экосистему" в нужном стиле, а затем уже начать комбинировать полученные "кубики".
На C++ же это легко достигается использованием языка в рамках его официальной парадигмы. Прочитав у Страуструпа про "не платить за то, что не используется", народ воображает, что это будет обеспечиваться само, неким волшебным образом, пока они будут наворачивать все более и более сложные метаконструкции. А поскольку этим занимаются чуть менее, чем все, то сравнение своих результатов с результатами коллег не позволяет предположить, что кто-то делает что-то не так.
M>я не вижу проблемы в "бесовских" шаблонах, которые ты так не любишь.
Я их люблю в той части, в которой они позволяют программировать обобщенно — за то, для чего они и создавались. А за то, что на их побочках успела вырасти целая отрасль технологии, я не люблю ни их, ни тех, кто это продвигает.
M>Работает — и ладно
Вполне себе годный девиз для наколенных поделок. Для промышленных — так себе.
Re[2]: Можно ли сделать универсальный шаблон для разных комбинаций whar_t и char
Здравствуйте, Marty, Вы писали:
M>это не решение твоей проблемы?
Я ее уже решил через костыльный struct, специализацией которого задается промежуточный тип. Но от того, что у меня получилось, этот метод не стал менее костыльным.
Re[22]: Можно ли сделать универсальный шаблон для разных комб
Здравствуйте, so5team, Вы писали:
S>в конце 1980-х вы уже были не в СССР?
Нет, я был в СССР. СССР был вовсе не так сильно изолирован от остального мира, как принято считать в некоторых кругах. У тех, кто работал в крупных НИИ и ВЦ, был доступ практически ко всей технической литературе, которая печаталась на Западе. Ленты и диски с новым софтом оттуда привозили регулярно, а дальше они уже расходились по стране. А в начале 80-х появились цифровые каналы между крупными научными центрами, софт стали качать по ним.
ЕМ>>А я занимаюсь программированием с 1980-го.
S>С 12-ти лет?
Да.
S>А на каких платформах можно было использовать многопоточность в 1982-1985гг?
На БЭСМ-6, на PDP-11 (под RSX-11M). С настоящей железной многопроцессорностью и истинным параллелизмом (у нас стояло три БЭСМ-6, объединенных в сеть) я тогда особо не связывался, но и там, и там была отличная многозадачность, межпроцессная синхронизация, асинхронные события и все остальное, что к этому прилагается.
Re[25]: Можно ли сделать универсальный шаблон для разных комб
Здравствуйте, Евгений Музыченко, Вы писали:
S>>в конце 1980-х вы уже были не в СССР?
ЕМ>Нет, я был в СССР. СССР был вовсе не так сильно изолирован от остального мира, как принято считать в некоторых кругах. У тех, кто работал в крупных НИИ и ВЦ, был доступ практически ко всей технической литературе, которая печаталась на Западе. Ленты и диски с новым софтом оттуда привозили регулярно, а дальше они уже расходились по стране. А в начале 80-х появились цифровые каналы между крупными научными центрами, софт стали качать по ним.
Речь же не о литературе, а о программах. И, поскольку вы сравнивали с FoxPro и Clipper, то речь уже о x86 и MS-DOS (или клоны MS-DOS). На рубеже 80-х и 90-х просто под MS-DOS на C++ возможностей попрограммировать было совсем не много. Zortech C++ -- это 1988-ой, Borland C++ 1.0, емнип, 1990-й. А ведь нужно успеть на них еще и что-то запрограммировать.
Собственно, я к тому, что именно на рубеже 80-х и 90-х софта на C++, с которым вы могли бы столкнуться, было совсем совсем мало. Даже странно, что вы вообще с ним столкнулись.
ЕМ>>>А я занимаюсь программированием с 1980-го.
S>>С 12-ти лет?
Это была какая-то спецшкола, кружок/факультатив, возможность программировать у родителей на работе?
ЕМ>Да.
S>>А на каких платформах можно было использовать многопоточность в 1982-1985гг?
ЕМ>На БЭСМ-6, на PDP-11 (под RSX-11M). С настоящей железной многопроцессорностью и истинным параллелизмом (у нас стояло три БЭСМ-6, объединенных в сеть) я тогда особо не связывался, но и там, и там была отличная многозадачность, межпроцессная синхронизация, асинхронные события и все остальное, что к этому прилагается.
Эээ... Как бы многопроцессорность, многопроцессность и многопоточность -- это разные вещи. Именно многопоточность (а не многопроцессность) вроде бы в середине 1980-х только-только начиналась. Могу сильно ошибиться, но вроде как в SunOS. Затем уже она появилась в OS/2, WinNT и в виде POSIX Threads (но это уже 1990-е).
Re[25]: Можно ли сделать универсальный шаблон для разных комб
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Да не было ничего такого особенно подводного, я на BC++3.1 немало кода наколбасил.
ЕМ>Переносить под другие компиляторы пробовали?
Пробовал. Но, с учетом того, что на вткоме я прогал уже под dos4gw с его честными 32мя битами, из-под доса с его сегментами при переносе приходилось повозится. Но в целом — ничего страшного
M>>И с качеством кода было норм (по скорости, баги кодогенератора тогда встречались чаще)
ЕМ>Одним из хороших примеров такого подхода был Turbo Vision, из которой потом сделали Object Windows, а у MS — MFC. Со стороны исходников и документации все красиво и кошерно — "всё есть объект", везде динамическая память и полиморфизм, обработка событий вешается куда угодно и т.п. Простые приложения на них выглядели действительно просто и изящно, работали быстро, наводя на мысли, что так будет всегда. Но, по мере роста объема исходников, внутренних связей и усложнения взаимодействий, накладные расходы росли лавинообразно. Какой-нибудь чисто косметической правкой можно было легко получить кратный рост тормозов, и приходилось долго прослеживать цепочки своих и внутренних зависимостей, в которых и сами разработчики ориентировались с трудом.
Сказки какие-то
ЕМ>Я их люблю в той части, в которой они позволяют программировать обобщенно — за то, для чего они и создавались. А за то, что на их побочках успела вырасти целая отрасль технологии, я не люблю ни их, ни тех, кто это продвигает.
Здравствуйте, Евгений Музыченко, Вы писали:
M>>это не решение твоей проблемы?
ЕМ>Я ее уже решил через костыльный struct, специализацией которого задается промежуточный тип. Но от того, что у меня получилось, этот метод не стал менее костыльным.
А, ну то есть вместо библиотечного ты свой traits наколбасил. Ну, если ты в 0x03их живешь — норм. Я только в упор не могу понять, с какого перепуга это является, по твоему мнению, костылём.
Здравствуйте, Евгений Музыченко, Вы писали: ЕМ>На БЭСМ-6, на PDP-11 (под RSX-11M). С настоящей железной многопроцессорностью и истинным параллелизмом (у нас стояло три БЭСМ-6, объединенных в сеть)
А под чем оно (железо) работало?
Здравствуйте, so5team, Вы писали:
S>Речь же не о литературе, а о программах. И, поскольку вы сравнивали с FoxPro и Clipper, то речь уже о x86 и MS-DOS (или клоны MS-DOS).
Так я и не говорил, что это хоть как-то относилось к СССР.
S>я к тому, что именно на рубеже 80-х и 90-х софта на C++, с которым вы могли бы столкнуться, было совсем совсем мало.
Верно, мало. Первым делом вспоминается Turbo Vision, который был прямо напоказ набит демонстрациями ООП. Еще вроде бы на C++ стали писать старшие версии Norton Utilities, в которых был навороченный интерфейс, но это не точно.
S>Именно многопоточность (а не многопроцессность) вроде бы в середине 1980-х только-только начиналась.
Я так написал потому, что нынче большинство знает только за многопоточность. А по сути, какая разница? Параллелизм — он и в Африке параллелизм, что несколько потоков в одном контейнере-процессе, что несколько независимых процессов с общей памятью. Основные-то принципы те же. А многопоточность в рамках одного процесса тогда делали вручную — или полностью своими силами, или с помощью системных средств вроде виндовых fibers.
Re[27]: Можно ли сделать универсальный шаблон для разных комб
Здравствуйте, Carc, Вы писали:
C>>>А под чем оно (железо) работало?
ЕМ>>В каком смысле "под чем"? C>ОС
Если Вы про группу БЭСМ-6, то основной ОС был ДисПак, к которому было прикручено несложное сетевое расширение (которым, однако, мало кто пользовался). Поверх ДисПака стояла Дубна, но в качестве "мониторной системы", а не полноценной ОС — примерно так же, как первые версии винды поверх доса. Позже к ДисПаку, не имевшему собственной ФС, прикрутили архивно-файловую систему АрФа. Дальнейшей эволюции я уже не застал.
Re[27]: Можно ли сделать универсальный шаблон для разных комб
ЕМ>Я так написал потому, что нынче большинство знает только за многопоточность. А по сути, какая разница? Параллелизм — он и в Африке параллелизм, что несколько потоков в одном контейнере-процессе, что несколько независимых процессов с общей памятью. Основные-то принципы те же. А многопоточность в рамках одного процесса тогда делали вручную — или полностью своими силами, или с помощью системных средств вроде виндовых fibers.
Если что, файберы в винду завезли довольно недавно, как бы не в W2K, если не в XP
