Re[14]: Поугараем над С++ комьюнити?
От: Pzz Россия https://github.com/alexpevzner
Дата: 27.10.17 06:46
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, Pzz, Вы писали:


Pzz>>Достаточно натянутая аналогия. Если уж на то пошло, шуруп — это язык программирования, а любой достаточно адекватный редактор текстов — это шуроповерт с регулируемым усилием.

CC>Редактор текста это простая отвёртка.
CC>Нормальный же IDE даёт тебе всю нужную информацию прямо по месту, без необходимости пользоваться поиском и менять для этого контекст.

Простая отвертка — это нотепад.

В студию, кстати, редактор текста-то забыли положить. Очень увлеклись токарно-ткацким станком с ЧПУ.

Pzz>>Ну вообще-то, C++ компилируется аццки долго.

CC>Меньше буста класть надо и будет компилироваться довольно таки быстро.

У меня не буст, а Qt. Если бы не Qt, вообще в гробу бы я видел весь этот C++

Pzz>> Даже по сравнению с C, не говоря уж о языках, которые действительно быстро компилируются.

CC>С быстро компилируется но кошмарно медленно и многословно пишется.

Я не сказал бы, что C++ лаконичнее C. Скорее, наоборот. Раза в два.
Re[15]: Поугараем над С++ комьюнити?
От: CreatorCray  
Дата: 27.10.17 08:03
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Простая отвертка — это нотепад.

Нотепад это обломок пластикового ножа которым пытаются выкрутить slot head screw.

Pzz>В студию, кстати, редактор текста-то забыли положить. Очень увлеклись токарно-ткацким станком с ЧПУ.

О чём ты?

Pzz>Я не сказал бы, что C++ лаконичнее C. Скорее, наоборот. Раза в два.

Промышленно пишу на обоих около- и просто системщину всякую. С кошмарно многословен.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[3]: Поугараем над С++ комьюнити?
От: CreatorCray  
Дата: 27.10.17 08:03
Оценка:
Здравствуйте, MTD, Вы писали:

MTD>не приводя никаких аргументов.

Аргументы в КСВ? Серьёзно?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[7]: Поугараем над С++ комьюнити?
От: AlexGin Беларусь  
Дата: 27.10.17 11:33
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>Вы связей не видите. C++ базоый инструмент для остальных остальных инструментов сборки. И если он перестаёт где-то работать все остальные через некоторое время тоже престают работать на данной платформе.


Да, базовый инструмент.
Но ведь никто же не переносил WinAPI в стандарт C++
Так почему же он не должен работать, если у end-user-а стоит Windows XP?
Я ведь не говорю про разработчика, у него (для работы с современной MSVC) дложна быть минимум Windows 7 (SP1).

_>А если еще создаются дополнительные плюшка сторонние либы постепенно переходят на новые версии C++. Остальные по зависимостям от этих либ тоже начинает не поддерживать нужную платформу. Так что не только причем, C++ очень хороший рычаг.


Это рычаг, чтобы девелоперы переходили на современные версии Windows. Конечные пользователи могут сидеть и под Windows XP.

AG>Современные диски уже не превый год как могут хранить терабайты.

_>Это развращает. Взлянуть на браузеры или на visual studio этож позор. Далеко ходить не надо в эксплорере при нажатии правой кнопки мыши проискожит лютое мракобесие пред тем как откроется менюшка

Нет, это НЕ РАЗВРАЩАЕТ. Это просто приучает думать масштабнее и не экономить на спичках.
Насчёт указанных тобой выше современных приложений: IMHO на технике более-менее современной они работают вполне адекватно и даже комфортно.
Речь даже не о топовых компах, а об обычном ширпотребе, который ещё не успел морально, да и физически, устареть.

AG>Время 40-мегабайтных русских AT — давно прошло.

_>Всякие arduino негодуют.

А кто утверждает, что на эти самые arduino надо тащить всё?
Там, при нормальной разработке, должен быть минимальный run-time, а всё остальное — на верхнем уровне (рабочая станция).
Re[16]: Поугараем над С++ комьюнити?
От: Pzz Россия https://github.com/alexpevzner
Дата: 27.10.17 11:36
Оценка:
Здравствуйте, CreatorCray, Вы писали:

Pzz>>В студию, кстати, редактор текста-то забыли положить. Очень увлеклись токарно-ткацким станком с ЧПУ.

CC>О чём ты?

О том, что собственно редактор текста в студии — паршивый.

Pzz>>Я не сказал бы, что C++ лаконичнее C. Скорее, наоборот. Раза в два.

CC>Промышленно пишу на обоих около- и просто системщину всякую. С кошмарно многословен.

Я тоже много на чем пишу, и все промышленно. И тем не менее, остаюсь при своем мнении. C многословен, C++ еще многословнее.

Кстати, слишком лаконичные языки тоже не шибко удобны. Достаточно вспомнить APL, как пример терминально лаконичного языка.
Re[4]: Поугараем над С++ комьюнити?
От: Pzz Россия https://github.com/alexpevzner
Дата: 27.10.17 11:40
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Любое ABI+рефлексия прибивает оптимизации на корню.

V>Т.е., надо одновременно выкатывать как рефлексию ср-вами языка, так и способы ею не пользоваться. Дотнет шел к этому более десятка лет, для будущих стандартов С++ такое тоже готовят.

Непонятно, почему наличие в бинарнике отдельной статической секции, в которую компилятор положит информацию об использованных в программе типах, убъет всю оптимизацию на корню. Собственно, даже секция такая есть, debug info называется, осталось договориться об общепринятом интерфейсе к ее содержимому.
Re[5]: Поугараем над С++ комьюнити?
От: push  
Дата: 27.10.17 13:55
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Ты хочешь странного. Если хочешь язык встроенный в платформу — бери C#


Я хочу элементарного — хоть какой-то инфраструктуры, чай не в 90х уже живём.

CC>Наверное потому, что программу пишешь ты, а не компилер.


И что, я должен делать за него его работу?

P>>Ну да, то-то его всё время правят от стандарта к стандарту. Осталось, чтобы ещё везде в шаблонах поддерживался и будет ок.

CC>Чот я не помню чтоб с ним на практике какие то проблемы были.
CC>Как только он появился я прошёлся по коду и везде где от него и decltype была польза — повставлял. Завелось сразу, работало как обещали.

Я не о том. Его понемногу добаляют, когда-то добавят во все места (посмотри, например чем auto c++11 отличается от auto c++17). Направление правильное — заставить компилер выполнять свою работу, а вот почему надо ждать н-лет для очевидной штуки мне так и не ясно.
Re[5]: Поугараем над С++ комьюнити?
От: push  
Дата: 27.10.17 14:08
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Т.е. предполагается добавить это всё в поставку компилятора? ) Естественно в виде статических библиотек, скомпилированных под все поддерживаемые данным компилятором архитектуры процессора? Так и представил себе в будущем предложение скачать компилятор C++ в сотню гигабайт... А уж какой размер и разносторонность команды, разрабатывающей такую стандартную библиотеку, будет...


Предлагается поставлять как и std либу. По поводу видов компиляции — всё уже сделано Microsoft в msvs — просто передрать оттуда.
По поводу размера — то, к примеру, сколько там .Net весит? Не так уж и много.
По поводу размера команды — очень небольшая. По сути вся работа уже сделана в сторонних либах и других языках. Чтобы передрать это оттуда с адаптацией под плюсы не потребуется ни много людей, ни много времени. К примеру ментейнеры сейчас просто копируют boost практически без изменений. И у меня большие вопросы по этому поводу — раз делают один в один, то чем занимаются в остальное время, что новые стандарты нужно ожидать годами?
Re[6]: Поугараем над С++ комьюнити?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.10.17 14:21
Оценка:
Здравствуйте, push, Вы писали:

P>Здравствуйте, alex_public, Вы писали:


_>>Т.е. предполагается добавить это всё в поставку компилятора? ) Естественно в виде статических библиотек, скомпилированных под все поддерживаемые данным компилятором архитектуры процессора? Так и представил себе в будущем предложение скачать компилятор C++ в сотню гигабайт... А уж какой размер и разносторонность команды, разрабатывающей такую стандартную библиотеку, будет...


P>Предлагается поставлять как и std либу. По поводу видов компиляции — всё уже сделано Microsoft в msvs — просто передрать оттуда.

P>По поводу размера — то, к примеру, сколько там .Net весит? Не так уж и много.
Ну можно еще сюда добавить и .Net Natve, там считай тот же компилятор, что и C++ только со сборкой мусора
и солнце б утром не вставало, когда бы не было меня
Re[5]: Поугараем над С++ комьюнити?
От: push  
Дата: 27.10.17 14:23
Оценка: :)
Здравствуйте, vdimas, Вы писали:

V>Это единственный способ хоть как-то двигать технологии.

V>Любой стандарт — это смерть разума.

Это верно только для cutting-edge. И тут как раз стандартизация невозможна. Предлагаеся же стандартизация для базовых, устоявшихся вещей. В наше время это уже дико, когда их нет в стандартных инструментах.

V>Потому что это именно и твоя задача тоже — разрабатывать прикладные библиотеки, если ты С++ программист. Например, наша контора живёт разработками библиотек. И таких полно.


Мне более интересно не библиотеки писать, а прикладной софт. И тут, особенно когда нужно возвращаться после C# на плюсы — то отсутствие комфорта особо ощутимо. Особенно на контрасте, когда понимаешь насколько просто это может быть, а вместо — приходится принимать кучу телодвижений.
Re[6]: Поугараем над С++ комьюнити?
От: vdimas Россия  
Дата: 27.10.17 14:55
Оценка: +1
Здравствуйте, push, Вы писали:

V>>Это единственный способ хоть как-то двигать технологии.

V>>Любой стандарт — это смерть разума.
P>Это верно только для cutting-edge. И тут как раз стандартизация невозможна. Предлагаеся же стандартизация для базовых, устоявшихся вещей.

Такая стандартизация для устоявшихся и востребованных вещей есть.
Всё остальное — cutting-edge.
Т.е. не включается в стандарт по причине своей активной разработки в настоящее время.


P>В наше время это уже дико, когда их нет в стандартных инструментах.


Дико, когда кто-то не в курсе самих обсуждаемых технологий, но громко высказывается.

Есть прикольное фундаментальное противоречие для технологий навроде аудио-видео. Суть в том, что в одной системе может существовать более одной технологии одного вида. Например, в современных Windows их минимум 4 одновременных технологии аудио в наличии и порядка 4-5 графических технологий. В Linux одновременно живёт 2-3 технологии аудио и столько же графических. Но в язык нельзя включать ни одну из них. Потому что которые уже устоялись, те уже включать поздно, бо этими технологиями для разработки новых приложений не пользуются. А которые находятся в активной разработке, те нельзя включать в стандарт именно по причине активности разработки.


P>Мне более интересно не библиотеки писать, а прикладной софт. И тут, особенно когда нужно возвращаться после C# на плюсы — то отсутствие комфорта особо ощутимо. Особенно на контрасте, когда понимаешь насколько просто это может быть


Я тебе гарантирую, что ты вааще нифига не понимаешь. Чтобы что-то понять, открой рефлектор и посмотри, как много лишних телодвижений делается в дотнете для общения со многими нейтивными технологиями. Напротив, в нейтиве 90% всего того, что происходит в дотнете, банально не надо — пользуйся напрямую. Всё как раз-таки проще на порядки. И у тебя граф обработки данных подчиняется нейтивной же архитектуре (диктуется ею). Слабость же дотнета в том, что он часто пытается "транслировать" графы обработок данных друг в друга, отсюда имеем все эти пляски с контекстом синхронизации и жуткой неэффективностью IO.

Твоё ощущение дискомфорта связано с тем, что ты привык иметь всё необходимое в поставке с фреймворком. Но ты даже не в курсе, где живёт SDK под твой же фреймворк, верно? По-сути, твой каминг-аут именно об этом — о твоей панике, когда нужно попользовать системные SDK или скачать и подключить третьестороннию либу. ИМХО, уважающему себя разработчику в этом месте должно быть стыдно. Тут уже надо прикрыться ветошью и не отсвечивать, а не кричать о своих фобиях на весь интернет. Совсем совесть потеряли, смотрю. ))


P>а вместо — приходится принимать кучу телодвижений.


До NuGet в дотнете нужно было предпринимать столько же телодвижений. Откуда я заключаю, что ты в профессии относительно недавно. А со своим уставом в чужой монастырь не лезут. Пришёл в наш программерский коллектив, изволь соответствовать. Потому что получается так, что ты еще не смотрел даже на пакетные менеджеры под Linux. Потому что NuGet пока не дотягивает до современного удобства линуховых пакетных менеджеров, но изо всех сил пытается. ))

Для нейтива под Windows можно пользовать в том числе NuGet для пакетирования. Но всё более популярным под винды становится шоколадка — калька с линуховых пакетных менеджеров.
Re[6]: Поугараем над С++ комьюнити?
От: vdimas Россия  
Дата: 27.10.17 15:00
Оценка:
Здравствуйте, push, Вы писали:

P>По поводу размера команды — очень небольшая. По сути вся работа уже сделана в сторонних либах и других языках. Чтобы передрать это оттуда с адаптацией под плюсы


С какой еще адаптацией, если наоборот — сторонние либы как раз на С++ сделаны?


P>не потребуется ни много людей, ни много времени. К примеру ментейнеры сейчас просто копируют boost практически без изменений.


Смишно. До того, как объекты из Boost.Thread попали в стандарт, они пережили 4 (ЧЕТЫРЕ, Карл!!!) серьёзные смены архитектуры. И вот когда процесс смен архитектур превратился в затухающий, тогда и добавили наработки в стандарт.


P>И у меня большие вопросы по этому поводу — раз делают один в один, то чем занимаются в остальное время, что новые стандарты нужно ожидать годами?


Я же говорю, ты в профессии недавно.
Четыре, Карл!
Re[7]: Поугараем над С++ комьюнити?
От: MTD https://github.com/mtrempoltsev
Дата: 27.10.17 15:23
Оценка:
Здравствуйте, vdimas, Вы писали:

V>С какой еще адаптацией, если наоборот — сторонние либы как раз на С++ сделаны?


Вот это реально смешно. Что объединяет эти либы: libcurl, openssl, icu, zlib, ffmpeg, openal? Хмм, все это индустриальный стандарт и все они написаны на С. А что же предложило С++ комьюнити в качестве альтернативы? Вопрос риторический.
Re[8]: Поугараем над С++ комьюнити?
От: vdimas Россия  
Дата: 27.10.17 15:56
Оценка:
Здравствуйте, MTD, Вы писали:

MTD>Вот это реально смешно. Что объединяет эти либы: libcurl, openssl, icu, zlib, ffmpeg, openal? Хмм, все это индустриальный стандарт и все они написаны на С. А что же предложило С++ комьюнити в качестве альтернативы? Вопрос риторический.


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

Только все-равно нелепость выходит. Неужели ты не в курсе про устоявшийся отродясь способ взаимодействия С/С++?
libcurl -> www.curlpp.org
icu -> Boost.Locale
zlib -> Boost iostream zlib filters
OpenGL, OpenAL, OpenES -> OpenGL++, OpenAL++, OpenES++
ffmpeg -> ffmpeg DirectShow filter
Re[9]: Поугараем над С++ комьюнити?
От: MTD https://github.com/mtrempoltsev
Дата: 27.10.17 16:13
Оценка:
Здравствуйте, vdimas, Вы писали:

V>То вам подавай навороченный С++


Ты меня с кем-то путаешь. Я ценю простоту, удобство, надежность.

V>то приводите в пример проекты на С


Я их привел по одной причине — это индустриальный стандарт, на С++ нет ничего подобного, что идет вразрез с твоими словами, что все либы есть на С++.

V>не под все архитектуры процов существуют компиляторы с навороченного С++.


Давай больше конкретики, а то опять начинается разговор про сферического коня в вакууме. Кстати, отличный С++ фреймворк — Qt работает на самых разных железках, даже с древними компиляторами.

V>Забавно, как по мне, на голубом глазу выдвигать противоречивые требования и смотреть на оппонентов — как они будут реагировать на такой беспредел.


Ты сам с собой заговорил?

V>Только все-равно нелепость выходит. Неужели ты не в курсе про устоявшийся отродясь способ взаимодействия С/С++?

V>libcurl -> www.curlpp.org
V>icu -> Boost.Locale
V>zlib -> Boost iostream zlib filters
V>OpenGL, OpenAL, OpenES -> OpenGL++, OpenAL++, OpenES++
V>ffmpeg -> ffmpeg DirectShow filter

Обертки, обертки, обертки, причем местами делающие хуже и добавляющие своих глюков. Где плюсовые проекты такой-же зрелости? Вот так и выходит, что на С++ мы только и заняты тем, что одно оборачиваем в другое.
Re[9]: Поугараем над С++ комьюнити?
От: so5team https://stiffstream.com
Дата: 27.10.17 16:33
Оценка:
Здравствуйте, vdimas, Вы писали:

V>icu -> Boost.Locale


Дык сам ICU же на C++ написан, о чем речь вообще?
Re: Поугараем над С++ комьюнити?
От: PM  
Дата: 27.10.17 17:25
Оценка: +2
Здравствуйте, MTD, Вы писали:

MTD>...


MTD>Посмотрев любой мастер класс по плюсам уже через пять минут ловишь себя на мысли — да все упоролись, то что на других языках делается не задумываясь тут предмет для получасового обсуждения. Вот не самый упоротый случай:


MTD>https://www.youtube.com/watch?v=83ci6JeZIG4&amp;list=PLgsLnJ-wgYTZRDRK3jrSOoarFg0ART6Ea&amp;index=10


А вы точно смотрели конференции по другим языка/технологиям? Там точно также обсуждают очередной новый single page application framework, или (о чудо!) появление констант в языке.

MTD>Чувак на полном серьезе рассказыват, что вместо того чтобы пилить класс строк для того чтобы сравнивать строки независимо от регистра, можно написать класс-свойство, который передать в шаблон стандартной строки и который будет переводить строки в нижний регистр перед тем как положить в память, ну и потом можно эти строки сравнивать. Друг, ты совсем что-ли? Может лучше просто написать функцию (а лучше чтобы она была в стандартной библиотеке) compareCaseInsensitivity? Это и проще и в коде сразу понятно, что происходит


Я видео не смотрел, но по слайдам там только половина презентации про char_traits. Может быть вы слишком продвинуты в С++, и многие в аудитории той презентации могли просто не читать Exceptional C++, про решение одной из задач и рассказывает докладчик.

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

Короче, мой месседж — я не понял над чем надо угорать.

MTD>Короче, мой месседж — С++ маргинализируется и становится убежищем фриков, на интересы инженеров там положили болт.


Ок. Тогда можно вопрос: какой бы вы выбрали язык для реализации нового проекта с требования кросс-платфроменности и высокой производительности? Скажем, игры-стрелялки от первого лица для PS4/XBox One/PC, или базы данных для новой соцсети, или системы управления автомобилем?
Re[2]: Поугараем над С++ комьюнити?
От: MTD https://github.com/mtrempoltsev
Дата: 27.10.17 17:41
Оценка:
Здравствуйте, PM, Вы писали:

PM>Ок. Тогда можно вопрос: какой бы вы выбрали язык для реализации нового проекта с требования кросс-платфроменности и высокой производительности? Скажем, игры-стрелялки от первого лица для PS4/XBox One/PC, или базы данных для новой соцсети, или системы управления автомобилем?


С++ конечно. Язык нормальный, тут у меня нет вопросов (по большей части), мне нездоровая движуха вокруг него не нравится.
Re[17]: Поугараем над С++ комьюнити?
От: CreatorCray  
Дата: 27.10.17 18:20
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>>>В студию, кстати, редактор текста-то забыли положить. Очень увлеклись токарно-ткацким станком с ЧПУ.

CC>>О чём ты?
Pzz>О том, что собственно редактор текста в студии — паршивый.
А что там не так то? Вот искренне непонятно.

Pzz>И тем не менее, остаюсь при своем мнении.

Dixi then.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[5]: Поугараем над С++ комьюнити?
От: CreatorCray  
Дата: 27.10.17 18:20
Оценка: +1
Здравствуйте, Pzz, Вы писали:

Pzz>Непонятно, почему наличие в бинарнике отдельной статической секции, в которую компилятор положит информацию об использованных в программе типах, убъет всю оптимизацию на корню.

Не это убивает производительность, а изменения в бинаре, которые позволят к любому из этих типов снаружи в любой момент доступаться.

Pzz> Собственно, даже секция такая есть, debug info называется, осталось договориться об общепринятом интерфейсе к ее содержимому.

Ты давно пробовал дебажить релизный бинарь с этими символами?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.