Здравствуйте, CreatorCray, Вы писали:
S>>Постоянно. По крайней мере для того, чтобы unit-тесты писать часто приходится фрагменты туда-сюда перекидывать. CC>А переиспользовать никак?
Преиспользовать что?
CC>>>Это делается не в каждом .cpp а в общем .h S>>Тогда это второй словарь. Кому-то, видимо, нужна дополнительная ментальная нагрузка. CC>Да просто не надо себе в голову заталкивать мегадлинные имена совсем, они всё равно туда плохо помещаются.
Имена всегда можно подсмотреть в документации. И нормальное длинное имя легче запомнить, чем короткое, но ненормальное. Из недавнего: были имена Tuple и Tuples.
CC>Ну и запоминать их тоже нафиг надо, для этого есть intellisense
Если intellisense нужен только для того, чтобы узнать, что где-то Tuples означает TupleVector, то нафиг.
S>>Потом я начинаю в своих кусках кода заменять его на FmtDetector, а работающий над другими кусками Вася Пупкин заменяет его на format_prober. CC>См выше про единый .h
Ну так для вас уже авторы библиотеки/компонента уже сделали общий .hpp-файл, где все однозначно.
Но, видимо, у этого .hpp-файла есть один фатальный недостаток (с).
S>>Пока что это лучшее из имеющегося. CC>Он же и худший.
Вменяемая альтернатива для C++ (и для Си впридачу)?
S>>Это были проблемы не с using-ом, а с желанием ввести свои собственные имена. CC>Имена вводятся через typedef а не через using.
Через using вводить удобнее. Особенно для чего-то связанного с шаблонами. Какие-то вещи через typedef получаются через жопу или в принципе не получаются. Так что остается только повторить -- typedef уже устаревшее говно мамонта.
S>>Мне уж показалось, что CreatorCray начал читать что ему пишут и думать над написанным. Но нет, ошибся. CC>Я так понимаю раз ты опять резко ломанулся в кусты — ты с написанным согласен но признать это не в состоянии.
Нет, с мозгами у вас все еще проблемы. Поэтому повторю еще раз: если кто-то меняет одно имя на другое только по соображениям эстетических пристрастий (например, делает PascalCase имя вместо snake_case) -- то это клиника. Об этом и был пример.
Ситуация с длинными именами пространств имен и типов в них принципиально иная. И общего хорошего решения здесь нет, грабли обнаруживаются у всех способов как-то это исправить.
Здравствуйте, so5team, Вы писали:
S>Имена всегда можно подсмотреть в документации.
И?
Читать код в которых между длиннющими именами не видно кода — это та ещё пытка.
S>И нормальное длинное имя легче запомнить, чем короткое, но ненормальное.
Речь про назначение коротких и нормальных имён вместо ненормально длинных.
Куда лучше имя "Hubert Blaine Wolfeschlegelsteinhausenbergerdorff" чем "Adolph Blaine Charles David Earl Frederick Gerald Hubert Irvin John Kenneth Lloyd Martin Nero Oliver Paul Quincy Randolph Sherman Thomas Uncas Victor William Xerxes Yancy Zeus Wolfeschlegelsteinhausenbergerdorffwelchevoralternwarengewissenhaftschaferswessenschafewarenwohlgepflegeundsorgfaltigkeitbeschutzenvorangreifendurchihrraubgierigfeindewelchevoralternzwolfhunderttausendjahresvorandieerscheinenvonderersteerdemenschderraumschiffgenachtmittungsteinundsiebeniridiumelektrischmotorsgebrauchlichtalsseinursprungvonkraftgestartseinlangefahrthinzwischensternartigraumaufdersuchennachbarschaftdersternwelchegehabtbewohnbarplanetenkreisedrehensichundwohinderneuerassevonverstandigmenschlichkeitkonntefortpflanzenundsicherfreuenanlebenslanglichfreudeundruhemitnichteinfurchtvorangreifenvorandererintelligentgeschopfsvonhinzwischensternartigraum Sr."
Оба имени — реальные имена реального человека.
CC>>Ну и запоминать их тоже нафиг надо, для этого есть intellisense S>Если intellisense нужен только для того, чтобы узнать, что где-то Tuples означает TupleVector, то нафиг.
TupleVector это не длинное имя.
mdx::expression_tree::abstract_cell_provider_uptr, mdx::expression_tree::cell_providers::distinct — вот эти уже надо укорачивать. Они плохо читаются.
S>Ну так для вас уже авторы библиотеки/компонента уже сделали общий .hpp-файл, где все однозначно.
И там алиасы их портянок в читаемые краткие имена?
Сомневаюсь.
S>>>Пока что это лучшее из имеющегося. CC>>Он же и худший. S>Вменяемая альтернатива для C++ (и для Си впридачу)?
Любая автогеренённая документация говно по определению.
Пример хорошей документации — старый MSDN
S>Нет, с мозгами у вас все еще проблемы.
Отложи зеркало в сторону, потом сам с собой побеседуешь.
S>делает PascalCase имя вместо snake_case
Это ты сам себе придумал и сам с собой споришь. Я говорю про алиасы на трёхэтажные имена во вложенных namespaces
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
S>>Имена всегда можно подсмотреть в документации. CC>И?
И: если имена из кода у вас в голове не задерживаются, то всегда можно подсмотреть в документации.
CC>Читать код в которых между длиннющими именами не видно кода — это та ещё пытка.
ХЗ, у вас, видимо, какие-то собственные привычки.
Код, в котором все символы однозначно идентифицируются отлично читается. Причем вне зависимости от того, делается ли это в IDE, в Midnight Commander или даже через less в ssh-сесси.
S>>И нормальное длинное имя легче запомнить, чем короткое, но ненормальное. CC>Речь про назначение коротких и нормальных имён вместо ненормально длинных.
Тут бы вам привести определение "ненормального длинного", чтобы критерии были понятны.
CC>Куда лучше имя "Hubert Blaine Wolfeschlegelsteinhausenbergerdorff"
Что-то ваша логика не сработала, "Wolfeschlegelsteinhausenbergerdorff" слишком длинное и нечитаемое. Но почему-то на более короткое не заменили.
CC>mdx::expression_tree::abstract_cell_provider_uptr, mdx::expression_tree::cell_providers::distinct — вот эти уже надо укорачивать. Они плохо читаются.
Это "mdx::expression_tree::abstract_cell_provider_uptr" плохо читается? Как-то мало вы видели по жизни.
S>>Ну так для вас уже авторы библиотеки/компонента уже сделали общий .hpp-файл, где все однозначно. CC>И там алиасы их портянок в читаемые краткие имена? CC>Сомневаюсь.
Включили бы мозги (если бы было что), не пришлось бы делать неверные предположения и затем сомневаться в них же.
S>>Вменяемая альтернатива для C++ (и для Си впридачу)? CC>Любая автогеренённая документация говно по определению. CC>Пример хорошей документации — старый MSDN
Так пользоваться-то чем? "Имя, сестра, имя!" (с)
S>>делает PascalCase имя вместо snake_case CC>Это ты сам себе придумал и сам с собой споришь. Я говорю про алиасы на трёхэтажные имена во вложенных namespaces
Тут же все ходы записаны. Мои слова (без купюр, весь абзац):
> Одно дело, когда using делается чтобы скрыть детали реализации (типа на этой платформе у нас ssize -- это int32, а на этой int64). Другое дело когда объявляется ICellProvider вместо abstract_cell_provider просто потому, что кого-то тошнит от snake_case.
И вот ко второму предложению из него вы попробовали прицепить совсем другой кейс:
S>Другое дело когда объявляется ICellProvider вместо abstract_cell_provider просто потому, что кого-то тошнит от snake_case.
А как насчёт ICellProvider вместо some_fancy_lib_name_because_we_liked_the_word_we_found_in_the_dictionary...
И если для вас одно как-то увязывается с другим, то у вас с головой проблемы (что, в общем-то, давно очевидно).
Здравствуйте, Alekzander, Вы писали:
A>https://github.com/carbon-language/carbon-lang?tab=readme-ov-file
A>Обсуждали уже?
А что тут обсуждать очередная попытка сделать вундер вафлю. Все понимают что C++ это титаник трындец. И хотят сделать лучше, но никто не может ясно объяснить как это лучше. Даже явно сформулировать, что их не устраивало. В результате наблюдаем построение того же что и было с косметические изменения. И в итоге получаем ничем не примечательный язык, который без финансирования в пиар (как у раста) со временем просто загнётся. И carbon не первый такой язык.
Здравствуйте, so5team, Вы писали:
S>Тут бы вам привести определение "ненормального длинного", чтобы критерии были понятны.
CC>>mdx::expression_tree::abstract_cell_provider_uptr, mdx::expression_tree::cell_providers::distinct — вот эти уже надо укорачивать. Они плохо читаются.
S>Что-то ваша логика не сработала, "Wolfeschlegelsteinhausenbergerdorff" слишком длинное и нечитаемое. Но почему-то на более короткое не заменили.
Он сам решил сократить своё имя именно так. Можешь пойти его откопать и лично предъявить претензии.
S>Это "mdx::expression_tree::abstract_cell_provider_uptr" плохо читается? Как-то мало вы видели по жизни.
Это УЖЕ плохо читается. С тем, что всегда можно сделать хуже, вроде как никто не спорил..
CC>>Любая автогеренённая документация говно по определению. CC>>Пример хорошей документации — старый MSDN S>Так пользоваться-то чем? "Имя, сестра, имя!" (с)
Документацию следует писать руками. Машинно сгенерённое годится для машины, человеки хотят человеческое изложение.
S>>>делает PascalCase имя вместо snake_case CC>>Это ты сам себе придумал и сам с собой споришь. Я говорю про алиасы на трёхэтажные имена во вложенных namespaces S>Тут же все ходы записаны. Мои слова (без купюр, весь абзац):
Вот твои слова, без купюр, весь абзац
S>Нет, с мозгами у вас все еще проблемы. Поэтому повторю еще раз: если кто-то меняет одно имя на другое только по соображениям эстетических пристрастий (например, делает PascalCase имя вместо snake_case) -- то это клиника. Об этом и был пример.
Моя очередь: из каких глубин собственной задницы ты вытащил эстетику и PascalCase?
S>И вот ко второму предложению из него вы попробовали прицепить совсем другой кейс:
Я скопипастил предложенное тобой короткое имя (ICellProvider) и привел пример длинного имени, которым надо заменять короткое, которое я написал в предложеном тобой же стиле. Твой abstract_cell_provider был скопипащен и удлиннён, с сохранением оригинального змеевидного стиля твоего примера.
Так что сгребай свой паскаль и своих змей и заталкивай себе обратно откуда ты их вытащил, шпециалист по головам ты наш, не умеющий читать.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, kov_serg, Вы писали:
_>А что тут обсуждать очередная попытка сделать вундер вафлю.
Скорее очередная попытка сделать свой преферанс с куртизанками от тех, кто ниасилил то, что уже есть. Ну или нашёл фатальный недостаток.
_>Все понимают что C++ это титаник трындец.
Нет, совсем не все понимают что ты тут хочешь сказать.
Разьясняй.
_> И хотят сделать лучше, но никто не может ясно объяснить как это лучше.
Да потому что не хотят они сделать лучше. Они хотят запилить себе новую цацку.
_>И в итоге получаем ничем не примечательный язык, который без финансирования в пиар (как у раста) со временем просто загнётся. И carbon не первый такой язык.
Правильно. Ибо цель всех этих новоязов совсем не практическая а околоакадемическая.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
S>>Тут бы вам привести определение "ненормального длинного", чтобы критерии были понятны. CC>
CC>>>mdx::expression_tree::abstract_cell_provider_uptr, mdx::expression_tree::cell_providers::distinct — вот эти уже надо укорачивать. Они плохо читаются.
Так критерии где? Пока что a) примеры и b) личное мнение. Вам кажется, что их надо укорачивать, но это вам кажется.
S>>Что-то ваша логика не сработала, "Wolfeschlegelsteinhausenbergerdorff" слишком длинное и нечитаемое. Но почему-то на более короткое не заменили. CC>Он сам решил сократить своё имя именно так. Можешь пойти его откопать и лично предъявить претензии.
Вы привели этот пример. Если он не подтверждает вашу логику про "короткое и читаемое", то он бесполезен.
S>>Это "mdx::expression_tree::abstract_cell_provider_uptr" плохо читается? Как-то мало вы видели по жизни. CC>Это УЖЕ плохо читается.
Ясно, понятно.
CC>Документацию следует писать руками.
Ясно, понятно.
S>>>>делает PascalCase имя вместо snake_case CC>>>Это ты сам себе придумал и сам с собой споришь. Я говорю про алиасы на трёхэтажные имена во вложенных namespaces S>>Тут же все ходы записаны. Мои слова (без купюр, весь абзац): CC>Вот твои слова, без купюр, весь абзац CC>
S>>Нет, с мозгами у вас все еще проблемы. Поэтому повторю еще раз: если кто-то меняет одно имя на другое только по соображениям эстетических пристрастий (например, делает PascalCase имя вместо snake_case) -- то это клиника. Об этом и был пример.
CC>Моя очередь: из каких глубин собственной задницы ты вытащил эстетику и PascalCase?
А ведь вы совсем плохи: я вам два раза написал, что если новые имена вводятся только потому, что старые не нравятся (а это и есть эстетика), то это клиника. Яркий пример клиники -- замена snake_case на PascalCase просто потому, что кому-то PascalCase нравится, а snake_case не нравится. Т.е., PascalCase -- это пример замены по эстетическим причинам.
Когда вы говорите, что вам abstract_cell_provider_uptr не нравится -- это та же самая эстетическая причина. И ведете себя как капризный ребенок, типа "Ну, мам, почему так длинно, я хочу короче!"
CC>Я скопипастил предложенное тобой короткое имя (ICellProvider) и привел пример длинного имени
Вы выдумали какой-то собственный пример и попытались привязать его к совсем другому кейсу. Я вам говорил про замену имен по исключительно эстетическим соображениям. Вы подняли тему про слишком длинные имена. И связали одно с другим, хотя я говорил лишь про эстетику.
Что и заставляет меня говорить о том, что вы не умеете читать и не вдумываетесь в то, что вам пишут. И это еще усугубляется тем, что ваше мнение единственно верное априори.
CC>Так что сгребай свой паскаль и своих змей и заталкивай себе обратно откуда ты их вытащил, шпециалист по головам ты наш, не умеющий читать.
Мозги сперва где-нибудь одолжите, чтобы советы другим давать.
Здравствуйте, kov_serg, Вы писали:
_>А что тут обсуждать очередная попытка сделать вундер вафлю. Все понимают что C++ это титаник трындец. И хотят сделать лучше, но никто не может ясно объяснить как это лучше. Даже явно сформулировать, что их не устраивало. В результате наблюдаем построение того же что и было с косметические изменения. И в итоге получаем ничем не примечательный язык, который без финансирования в пиар (как у раста) со временем просто загнётся. И carbon не первый такой язык.
Я могу! Я МОГУУУУУ!!!!
Сделайте как дотнет, только C++! Без виртуальной машины, с простыми взаимовызовами, но с большой богатой унифицированной библиотекой функционала (а не: "Это есть в бусте, а он почти стандартная библиотека... Ах, не работает? Что ж вы хотите, он же не стандартная библиотека!"), с лямбдами и LINQ'ом (в форме функций), с адекватными названиями. Ну и так далее.
И самое главное: все, кто доволен нынешними плюсами, пусть сидят в своей будке и наслаждаются тем, что они построили, их слушать вообще не надо.
Здравствуйте, CreatorCray, Вы писали:
_>>Все понимают что C++ это титаник трындец. CC>Нет, совсем не все понимают что ты тут хочешь сказать. CC>Разьясняй.
Очень больщой, избыточно сложный и ни разу не направленный на прикладные задачи. Некоторые вещи вообще сделаны противоестественным способом. Вообще не понимаю как в здравом уме такое в стандарт запихали.
Я про указатели pointer provenance и тому подобные заебоны, где внутренности компилятора выворачивают наружу.
CC>Правильно. Ибо цель всех этих новоязов совсем не практическая а околоакадемическая.
Для экспериментов с языком, нужен простой легко модифицируемый язык. В "C" был препроцессор, но вместо его развития, накрутили шаблонов и понеслось.
Вместо того что бы выкинуть это всё и сделать дополнительную фазу синтеза кода, продолжают нагораживать constexpr, концепты и другие бесполезные вещи.
Нормальные люди уже давно бы озаботились разделением одного от другого, но только не в плюсах. Тут принято всё смешивать и называть это zero-cost.
Здравствуйте, Alekzander, Вы писали:
A>Сделайте как дотнет, только C++!
А зачем вам замена C++, если уже есть C#, F#, Java, Scala, Kotlin, Go и даже Haskell с OCaml-ами?
A>Без виртуальной машины, с простыми взаимовызовами, но с большой богатой унифицированной библиотекой функционала (а не: "Это есть в бусте, а он почти стандартная библиотека... Ах, не работает? Что ж вы хотите, он же не стандартная библиотека!"), с лямбдами и LINQ'ом (в форме функций), с адекватными названиями. Ну и так далее.
A>Сделайте как дотнет, только C++! Без виртуальной машины, с простыми взаимовызовами,
Вот как раз виртуальная машина в C++ не помешала бы. С помощью её можно было бы отлавливать огромное количество UB и другие извращения моделировать которых физически нет в реальном железе, но которое заложено в стандарт (причем это можно было бы делать динамически, аля fuzzing)
Здравствуйте, so5team, Вы писали:
S>А зачем вам замена C++, если уже есть C#, F#, Java, Scala, Kotlin, Go и даже Haskell с OCaml-ами?
К сожалению, виртуальная машина: а) даёт слишком большой контроль владельцу (санкции и пр.), б) создаёт слишком много проблем для кросс-платформенности (до сих пор вздрагиваю, когда вспоминаю Java-приложения под Windows).
A>>Без виртуальной машины, с простыми взаимовызовами, но с большой богатой унифицированной библиотекой функционала (а не: "Это есть в бусте, а он почти стандартная библиотека... Ах, не работает? Что ж вы хотите, он же не стандартная библиотека!"), с лямбдами и LINQ'ом (в форме функций), с адекватными названиями. Ну и так далее.
S>Rust же.
В Rust'е многого не хватает, чтобы называться "как дотнет, только c++". Зато много лишнего, типа паранойи. Хотя, конечно, кроме Rust'а сейчас в этой нише никого другого просто нет.
Здравствуйте, kov_serg, Вы писали:
_>Вот как раз виртуальная машина в C++ не помешала бы. С помощью её можно было бы отлавливать огромное количество UB и другие извращения моделировать которых физически нет в реальном железе, но которое заложено в стандарт (причем это можно было бы делать динамически, аля fuzzing)
Представляю себе этого монстра. От создателей the Стандарта.
Хотя, конечно, как идея *компилируемая* виртуальная машина, свободная, собираемая для каждого проекта — я так себе представляю идеальную виртуальную машину С++ — это неплохая идея!
UB же от оптимизации сильно зависит, вряд-ли получится.
_>и другие извращения моделировать которых физически нет в реальном железе, но которое заложено в стандарт (причем это можно было бы делать динамически, аля fuzzing)
Здравствуйте, so5team, Вы писали:
S>За такое нужно отрывать руки. Как я понимаю, корни в том, что Rust начал делать OCaml-ер (т.е. человек наглухо ударенный функциональщиной). Отсюда и угребищные Rust-овые сокращения вроде fn или mut.
Не надо тут на OCaml катить
У него во первых в полтора раза длиннее не fn а fun, а во вторых это не аналог fn из раста, а обозначение лямбды, а обычные функции, как и любые другие переменные объявляются просто через let. Ну и в ML языках лямбды из-за каррирования используется намного реже чем в современных императивных языках.
A>Сделайте как дотнет, только C++! Без виртуальной машины, с простыми взаимовызовами, но с большой богатой унифицированной библиотекой функционала (а не: "Это есть в бусте, а он почти стандартная библиотека... Ах, не работает? Что ж вы хотите, он же не стандартная библиотека!"), с лямбдами и LINQ'ом (в форме функций), с адекватными названиями. Ну и так далее.
D в самом начале как-раз по этому пути шел (вместо шарпа правда ява была, но тогда и дотнет только и появился), но не получилось почему-то.
Здравствуйте, so5team, Вы писали:
S>Если делается новый язык, то почему бы сразу не сделать и удобный для пользователей синтаксис, и при этом легкий для парсинга?
Самый удобный для парсинга forth, но для чтения ну так себе. Хотя те же tl или list на удивление могут быть очень выразительными.
Здравствуйте, Alekzander, Вы писали:
A>Сделайте как дотнет, только C++! Без виртуальной машины, с простыми взаимовызовами, но с большой богатой унифицированной библиотекой функционала
Ну т.е. ты просишь просто написать большую библиотеку/framework.
И самое смешное, что все, кто умеет в С++ так для себя и поступили. На уровне компании или даже на персональном.
Работает офигенно, но есть нюанс — её надо написать и поддерживать. Так же как МС написал и поддерживает .NET FW
Вопрос в том, кто, а главное почему, станет вкладывать такое колво усилий и денег в подобный проект, и отдавать его бесплатно? Плюс переубеждать людей пересесть на него с их собственных, идеально подогнанных их под практические задачи.
Дохлый номер, как по мне.
У МС вышло потому что они выкатили язык СРАЗУ вместе с большим FW (без которого сам C# нахрен не был кому либо нужен и потому не взлетел бы), и потому там просто не было надобности делать свои.
A>Это есть в бусте, а он почти стандартная библиотека...
Буст увы, превратился уж совсем в лютое говно.
A>И самое главное: все, кто доволен нынешними плюсами, пусть сидят в своей будке и наслаждаются тем, что они построили, их слушать вообще не надо.
Дюд, самое смешное то, что все кто наслаждаются С++ вкупе с построенной на нём инфраструктурой под свои проекты, про твои невзгоды даже не подозревают и живут горя не знаючи.
Это ты носишься и хватаешься за всякие чужие обломки, в надежде что кто то за тебя (а главное совершенно безДвозДмезДно (С) ) сделает тебе хорошо, вместо того чтоб построить себе щасте своими руками.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
