Здравствуйте, push, Вы писали:
V>>Так я как раз нахожусь ровно там, где нужен программист. V>>И я хорошо понимаю, что мне, как программисту, надо от стандарта и ОБЯЗАТЕЛЬНЫХ в рантайме базовых либ. P>Да понял я. Ты походу даже половины STL никогда не использовал.
Увы, рантайм-либа одна на весь STL для самых актуальных на сегодня компиляторов.
P>Ясен пень, что когда человек чем-то не пользуется — то оно ему и не надо. Потому ты и против новых либ.
Я как раз не против новых либ, а очень даже за.
Я против пихать всё в одну либу, как ты настаиваешь.
А как только (если) либ становится больше одной, то уже малость однофигственно — входит ли эта либа в стандарт языка, в платформу или просто популярна (как тут выразился один из коллег — "промышленный стандарт де-факто").
P>А я думаю, что ж не получается объяснить то человеку очевидные вещи.
Поверхностность она такая, угу.
Не заметил еще, что ты в каждый момент времени согласен рассматривать лишь один из аргументов против, но никогда не совокупность их?
Отсюда возникает то самое хождение по-кругу, бо тебе надо напоминать те вещи, которые ты рад сразу же забыть, спустя буквально пару сообщений. ))
P>А всё оказывается просто. Ведь как объяснить — если человек дальше носа и не заглядывает в профессиональном плане?
Тоже верно. Начни хотя бы на пол-шишечки заглядывать дальше носа. И увидишь, что на сегодняшний момент для С/С++ есть прорва либ под любые направления. Проникнись тем, что столь плотного покрытия либами буквально произвольных направлений на сегодня не наблюдается ни для одного другого существующего языка, бо каждый другой язык — обязательно нишевый. И только С/С++ универсальные.
Здравствуйте, push, Вы писали:
V>>Система логгирования обычно плотно завязана на инфраструктуру конкретного приложения, т.е. даже на банальный способ получения экземпляра общего логгера или протягивания локального .... P>Я всё понял) Ты походу просто не имеешь достаточного опыта и не видел как оно должно быть.
Жесть.
Лучший способ защиты — это нападение?
Ты хоть понял, что тебе было сказано? Или оно не натянулось на твой личный опыт?
P>Видимо тебя без присмотра оставили на проекте и ты нагородил такого, что теперь считаешь, что логгирование — это сложно. Ну что я могу сказать — полистай хотя бы опенсорсные проекты для общего развития. Говнокода там много, но иногда попадаются нормальные проекты.
Да листаем мы опенсорсные проекты. Даже лучшие из них. В нашей области они сливают по эффективности примерно в 10 раз. Как раз лаборатория Интел замерами занимается. ))
Во многих опенсорсных проектах не считается зазорным получать, например, экземпляр логгера по имени из глобального синхронизируемого контейнера. Более того, унутре или прямо в публичном АПИ эти логгеры оперируют каким-нить shared_ptr, т.е. каждое получение экземпляра логгера и его освобождение дополнительно дёргает систему подсчёта ссылок на тяжеловесных атомарных interlocked-операциях, что в отсутствии конфликтов по эффективности равно двойной блокировке. Ну т.е. в наилучшем сценарии. А так-то при плотном многопоточном логгировании вся многопоточная приложуха начинает тормозить аккурат на логгере, бо все потоки на ём сталкиваются. А потом выскакивают некоторые особо шумные деятели и с пеной у рта доказывают, что "ваш С++ тормозит". )) В этом месте разрешается ржать в голос, кста, бо С++ уж точно тут не причём. А вот разработчики навроде тебя — очень даже причём. Вредят карме языка.
P>Во первых, пока ты доведёш буст до вменяемого состояния (начиная из подьема логгеров от конф. файлов) — я уже накидаю каркас половины приложения.
Так ты бустовскую библиотеку логгирования не смотрел еще? ))
P>Во вторых, почитай за самые основы — особенно что за зверь такой "переиспользование кода" — для чего оно нужно как этим пользоваться.
Ну так переиспользуй, какие проблемы?
Тем С++ и хорош, что позволяет совмещать запчасти от совершенно разных библиотек.
Бери форматтер от одной либы, вывод в консоль от другой, ротацию файла от третьей и чтение конфигов от 4-й.
Это нормально и займёт недолго.
А свой "каркас половины приложения", выполненный за это же время (пару часов на свою либу логгирования, которую ты можешь переиспользовать в десятках проектов) ты можешь смело выкинуть, бо это не каркас, а так — игрушки/эксперименты, это менее 0.01% от всей трудоёмкости среднего проекта. Ну и, повторюсь, если тебе логгер нужен более одного раза, то можно один раз ему уделить, таки, внимание. Не зря даже в дотнете нет единой системы логгирования. Их там несколько встроенных подсистем логгирования и еще несколько популярных либ сверху. ))
P>Я не вижу смысла тебе что-то рассказывать, когда ты даже основ не знаешь, не понимаешь принципов разработки.
Ты и не можешь мне ничего рассказать. По всем конкретным аргументам ты слился, тебе ответить нечего. Поэтому, перешёл к абстрактным.
Но ты же за слова не отвечаешь, верно? Т.е. не готов сравнить хотя бы даже разные способы получения экземпляра логгера (по причине чего ты сейчас налил столько бессмысленной воды)? И уж тем более не готов обсуждать схему асинхронного логгирования, я правильно тебя понимаю? Т.е., судя по тону первого абзаца в твоём посте, такой схеме нет места в твоей реальности, верно? ))
Здравствуйте, vdimas, Вы писали:
V>Жесть. V>Лучший способ защиты — это нападение? V>Ты хоть понял, что тебе было сказано? Или оно не натянулось на твой личный опыт?
Видишь ли, по всем твоим коментам можно сделать только один вывод — либо ты троль, либо не в теме.
V>Так ты бустовскую библиотеку логгирования не смотрел еще? ))
Да походу ты не смотрел. Чтобы довести её до юзабельного состояния (а не proof of concept) нужно поприседать. Более того, судя по другим бустовским либам — никто её в самом бусте дорабатывать дальше не будет.
V>Ну так переиспользуй, какие проблемы? V>Тем С++ и хорош, что позволяет совмещать запчасти от совершенно разных библиотек. V>Бери форматтер от одной либы, вывод в консоль от другой, ротацию файла от третьей и чтение конфигов от 4-й. V>Это нормально и займёт недолго. V>Ну и, повторюсь, если тебе логгер нужен более одного раза, то можно один раз ему уделить, таки, внимание.
Во-первых, нечего переиспользовать, с таким подходом нужно (именно нужно, а не можно) дописывать как ты дальше правильно и подмечаешь.
Во-вторых, то что тебе нужно дописывать самые базовые вещи — это и есть проблема плюсов.
V>Ты и не можешь мне ничего рассказать. По всем конкретным аргументам ты слился, тебе ответить нечего. Поэтому, перешёл к абстрактным.
OMG, у тебя ещё не было конкретных аргументов, все "аргументы" не в кассу. Обсуждать твои, не относящиеся к теме проблемы разработки вообще не интересно, учитывая что таких проблем у остальных не возникает.
Здравствуйте, vdimas, Вы писали:
V>Увы, рантайм-либа одна на весь STL для самых актуальных на сегодня компиляторов.
Ну я так и понял.
А в чём собственно проблема?
V>Я как раз не против новых либ, а очень даже за.
О как, но доказывал мне обратное.
V>Я против пихать всё в одну либу, как ты настаиваешь. V>А как только (если) либ становится больше одной, то уже малость однофигственно — входит ли эта либа в стандарт языка, в платформу или просто популярна (как тут выразился один из коллег — "промышленный стандарт де-факто").
Почему против пихания всё в одну — из-за деплоя?
Ну, я не настаиваю, чтобы всё обязательно было в одной либе. Я настаиваю, чтобы оно всё было описано в стандарте. А уж каким образом — одной, или сотней либ — уже не так важно.
Не предоставлять из коробки базовый функционал, не говоря уже про удобство использования — это нонсенс в наше время.
V>Не заметил еще, что ты в каждый момент времени согласен рассматривать лишь один из аргументов против, но никогда не совокупность их? V>Отсюда возникает то самое хождение по-кругу, бо тебе надо напоминать те вещи, которые ты рад сразу же забыть, спустя буквально пару сообщений. ))
У тебя все аргументы не по теме. Вот комент, на который отвечаю — один из тех, которые чудом оказались по теме.
Здравствуйте, push, Вы писали:
P>Видишь ли, по всем твоим коментам можно сделать только один вывод — либо ты троль, либо не в теме.
Либо ты не в состоянии воспринимать инфу от коллег.
V>>Так ты бустовскую библиотеку логгирования не смотрел еще? )) P>Да походу ты не смотрел. Чтобы довести её до юзабельного состояния (а не proof of concept) нужно поприседать.
Но я говорил о вполне конкретных вещах, а ты опять отвечаешь какой-то херней.
V>>Ну так переиспользуй, какие проблемы? V>>Тем С++ и хорош, что позволяет совмещать запчасти от совершенно разных библиотек. V>>Бери форматтер от одной либы, вывод в консоль от другой, ротацию файла от третьей и чтение конфигов от 4-й. V>>Это нормально и займёт недолго. V>>Ну и, повторюсь, если тебе логгер нужен более одного раза, то можно один раз ему уделить, таки, внимание. P>Во-первых, нечего переиспользовать
Странно. Другим есть.
P>с таким подходом нужно (именно нужно, а не можно) дописывать как ты дальше правильно и подмечаешь.
Под конкретную специфику? — несомненно.
Это верно для любого языка, если ты прямо отказываешься от третьестороннего готового логгера.
Тогда ты его собираешь сам из различных "запчастей".
P>Во-вторых, то что тебе нужно дописывать самые базовые вещи — это и есть проблема плюсов.
В других языках дописывать надо больше в твоём сценарии.
Похоже, тебе просто не нравится твоя работа.
V>>Ты и не можешь мне ничего рассказать. По всем конкретным аргументам ты слился, тебе ответить нечего. Поэтому, перешёл к абстрактным. P>OMG, у тебя ещё не было конкретных аргументов, все "аргументы" не в кассу.
Это не тебе решать, в кассу или нет.
Были предъявлены вполне конкретные технические аргументы и были заданы вопросы по существу.
Просто они тебе не удобны и ты предпочитаешь повторять самого себя, хотя тебе уже оппонировали.
Это даже не трольство, а просто глупость, роспись в нубстве.
P>Обсуждать твои, не относящиеся к теме проблемы разработки вообще не интересно, учитывая что таких проблем у остальных не возникает.
"Не возникают" или "не были обнаружены" — сильно разные вещи.
Анализировать предметную область, ставить задачи ты не можешь.
Мог бы — не занимался всей этой ерундой.
Потому что, по-сути, ты даже сформулировать свои претензии толком не в состоянии.
Стоит перейти к обсуждению конкретики — ты сразу сливаешь.
Наверно поэтому тебя тянет на рассуждения "об общем и прекрасном".
Скучно.
Здравствуйте, push, Вы писали:
V>>Я как раз не против новых либ, а очень даже за. P>О как, но доказывал мне обратное.
Покажи где?
Я был против пихать логгер прямо в STL.
Бо это идиотизм, разумеется.
V>>А как только (если) либ становится больше одной, то уже малость однофигственно — входит ли эта либа в стандарт языка, в платформу или просто популярна (как тут выразился один из коллег — "промышленный стандарт де-факто"). P>Почему против пихания всё в одну — из-за деплоя?
А зачем вообще динамические библиотеки существуют?
Почему бы не оформить вообще всё в одну библиотеку?
Что там у нас насчёт coupling и сohesion в нашем IT?
P>Ну, я не настаиваю, чтобы всё обязательно было в одной либе. Я настаиваю, чтобы оно всё было описано в стандарте. А уж каким образом — одной, или сотней либ — уже не так важно.
А в каком языке логгер описан в его стандарте?
P>Не предоставлять из коробки базовый функционал, не говоря уже про удобство использования — это нонсенс в наше время.
Ну так примеры будут или балабол?
V>>Не заметил еще, что ты в каждый момент времени согласен рассматривать лишь один из аргументов против, но никогда не совокупность их? V>>Отсюда возникает то самое хождение по-кругу, бо тебе надо напоминать те вещи, которые ты рад сразу же забыть, спустя буквально пару сообщений. )) P>У тебя все аргументы не по теме.
Аргументы по теме, просто тебе они не нравятся, т.е. ты слабый оппонент.
Здравствуйте, vdimas, Вы писали:
P>>Видишь ли, по всем твоим коментам можно сделать только один вывод — либо ты троль, либо не в теме. V>Либо ты не в состоянии воспринимать инфу от коллег.
Держки — http://lurkmore.to/_/1830#mws_bPiNHEO узнаёшь себя?))))
V>>>Так ты бустовскую библиотеку логгирования не смотрел еще? )) P>>Да походу ты не смотрел. Чтобы довести её до юзабельного состояния (а не proof of concept) нужно поприседать. V>Но я говорил о вполне конкретных вещах, а ты опять отвечаешь какой-то херней.
Во-во, всякую хню от тебя только и слышно. Сначала ляпнуть чушь, а потом всячески уводить тему в сторону.
P>>с таким подходом нужно (именно нужно, а не можно) дописывать как ты дальше правильно и подмечаешь. V>Под конкретную специфику? — несомненно. V>Это верно для любого языка, если ты прямо отказываешься от третьестороннего готового логгера. V>Тогда ты его собираешь сам из различных "запчастей".
OMG, я уже понял твоё мнение, что написать стандартную библиотеку чего-либо невозможно в принципе. Но вот если не добавлять её в стандарт — то магическим образом написать получается. А также — всё уже в плюсах написано и ничего писать не надо, но если рассматривать конкретный проект — всё надо писать заново.
Другими словами твои "аргументы" это либо тролинг либо шиза. Но как вариант я рассматриваю вопиющий непрофессионализм.
Остаётся только угарать над С++ комьюнити — топикстартер получается прав на 100%.
P>>Во-вторых, то что тебе нужно дописывать самые базовые вещи — это и есть проблема плюсов. V>В других языках дописывать надо больше в твоём сценарии. V>Похоже, тебе просто не нравится твоя работа.
В других языках всё в шоколаде по сравнению с плюсами в их области применения.
Критика плюсов в их текущем состоянии просто незбежна.
P>>OMG, у тебя ещё не было конкретных аргументов, все "аргументы" не в кассу. V>Это не тебе решать, в кассу или нет.
V>"Не возникают" или "не были обнаружены" — сильно разные вещи.
Да-да, я уже понял, что плюсы доступны только посвящнным — остальные по обпределению не умеют)
V>Потому что, по-сути, ты даже сформулировать свои претензии толком не в состоянии.
Серьезно? Ну перечитай мой первый комент. Что тут формулировать?
Основная проблема — отсутствие стандартной инфраструктуры языка и невероятно медленное (ну просто микроскопическое) развитие.
Но критику комента ты по сути не можешь сформулировать толком. Всё время получается ровно два варианта:
1) мне оно не надо/я этим не пользуюсь — значит никому не надо/никто не пользуется
2) невозможно написать стандартную библиотеку чего либо в принципе
Здрасте, приехали. Ты всю тему доказываешь, что невозможно что-либо добавить в стандартную библиотеку, так как невозможно написать стандартную библиотеку чего-либо в принципе.
V>А зачем вообще динамические библиотеки существуют? V>Почему бы не оформить вообще всё в одну библиотеку? V>Что там у нас насчёт coupling и сohesion в нашем IT?
Ну, я не против, чтобы поставлялись наборы библиотек. Хотя с другой стороны — те же редистры, фреймворки ставятся пачками. Если в системе больше 1 приложения — то оно всё будет нужно. Для embeded софта по хорошему вообще своя либа нужна.
V>А в каком языке логгер описан в его стандарте?
В любом есть в стандартных средствах.
P>>Не предоставлять из коробки базовый функционал, не говоря уже про удобство использования — это нонсенс в наше время. V>Ну так примеры будут или балабол?
Здравствуйте, push, Вы писали:
V>>А в каком языке логгер описан в его стандарте? P>В любом есть в стандартных средствах.
Т.е., привести пример не можешь, ЧТД.
P>>>Не предоставлять из коробки базовый функционал, не говоря уже про удобство использования — это нонсенс в наше время. V>>Ну так примеры будут или балабол? P>К примеру, возьми любой язык из большой тройки.
VS2012
MTD>Будто STL не такая. Те же аллокации на каждый чих, например, возможность перевести число в строку в выделенный буфер только в С++17 добавили. Мапе дать буфер и сказать его использовать из коробке тоже нельзя.
Здравствуйте, Timonn24, Вы писали:
T>inline string to_string(int _Val) T> { // convert int to string T> char _Buf[2 * _MAX_INT_DIG];
T> _CSTD _TOSTRING(_Buf, "%d", _Val); T> return (string(_Buf)); T> }
T>VS2012
MTD>>Будто STL не такая. Те же аллокации на каждый чих, например, возможность перевести число в строку в выделенный буфер только в С++17 добавили. Мапе дать буфер и сказать его использовать из коробке тоже нельзя.
То что ты начал изучать С++ похвально. Осталось научится правильно задавать вопросы, если что-то не понятно. Конкретно в твоем примере нет возможности создать строку in place, если не разобрался что делает код или неизвестен какой-либо термин — спрашивай, постараюсь помочь.
Здравствуйте, push, Вы писали:
P>В других языках всё в шоколаде по сравнению с плюсами в их области применения.
Вот именно что "в области их применения", т.е. в некоей узкой нише. ))
А С/С++ позиционируется немножко наоборот — эти языки "оставляют широко раскрытой дверь" для частностей платформ, для которых именно на этих языках пишут все остальные узконишевые языки/платформы.
Ты вот там рядом спрашивал, а почему же алгоритмы и контейнеры включить в стандарт можно, а логгер нельзя? Ответ очевиден — потому что алгоритмы и контейнеры слабо зависят (или не зависят вовсе) от конкретных платформ, поверх которых работает С++.
И про thread я тоже уже отвечал более чем доступно — пока не умерли своей смертью кучи экзотических платформ, куда пихали С++, реализовать некую универсальную функциональность над потоками в рамках стандарта было объективно сложно. Например, это не имело смысла еще в середине нулевых, когда в ходу было сразу несколько диалектов EC++. Потому что в ходу еще полно было платформ с вычурной реализацией многозадачности, например, сугубо кооперативной моделью с отсутствующими атомарными операциями (load/store/cas/swap). Или, того хуже, различные потоки могли обмениваться данными только через "трубу", т.е. через очередь байт. Многопоточных-то моделей де-факто было изобретено много. Ты смотрел когда-нибудь на потоковую модель первых (тех самых легендартных) поколений компьютеров Cray? Вот будет время — посмотри. Как ты там собрался реализовывать ТАКУЮ модель в стандарте языка С++?
Повторюсь, на сегодня ситуация такова, что весь этот туман более-менее рассосался. Т.е. нижележащие платформы разделились на два непересекаемых подмножества: на которых использование С++ не имеет смысла (типа Arduino/AVR, PIC, x51, Forth-процессоры, оптические, параллельные массивы навроде GPU, ИИ-процессоры и т.д.) и на которых возможна его реализация в современном (как минимум) стандарте (т.е. "универсальные" навроде MIPS/Alpha/Alchemy, x86/x64, IA64, ARM32/ARM64 и т.д.).
Итого, сегодня нет такого бесконечного градиента платформ, одно существование которых делало внесение неких платформенно-зависимых вещей в стандарт чистой воды профанацией.
И это же является ответом насчёт копирования файлов с колбэком о прогрессе — потому что такой функциональности нет не то, что в большинстве платформ, а строго наоборот — эта функциональность уникальна лишь для одного сочетания программной платформы и файловой системы. Потому что по-хорошему для этой функциональности надо рассматривать CopyFileTransacted/MoveFileTransacted, чтобы при отмене операции всё именно что отменялось, а не оставляло после себя коровьи лепешки по всему диску.
Ну а логгер в стандарте — это вообще гимн идиотизму. ))
Скажи, среди кучи имеющихся современных библиотек логгирования ты так и не смог выбрать себе подходящую?
А если смог, то не составило бы тебе труда предложить какую-нибудь из них в кач-ве кандидата в стандарт и объяснить почему именно её?
P>Критика плюсов в их текущем состоянии просто незбежна.
Критика критике рознь.
Каждый раз, когда я пытаюсь перевести твою критику в конструктивное русло, ты устраиваешь клоунаду, опять и снова улетая в облака абстракций, т.е. наглухо теряя связь с реальностью.
Ты не ответил ты пока ни на один конкретный вопрос. Двойка тебе по итогам обсуждения.
V>>"Не возникают" или "не были обнаружены" — сильно разные вещи. P>Да-да, я уже понял, что плюсы доступны только посвящнным — остальные по обпределению не умеют)
"Остальные" — это не только ты и тебе подобные. Согласно современной статистике на C/C++ пишет примерно в 5 раз больше программистов, чем на C#. Так вот, даже среди программистов на C# настольо упоротых и плохо понимающих, откуда у современного положения вещей растут ноги — их резкое меньшинство, разумеется. Упоротых всегда резкое меньшинство, ес-но, просто они самые громкие и создают информационного шума больше всех. Как раз RSDN в этом смысле — лакмусовая бумажка. Достаточно тут собраться одновременно упоротым в количестве 3-4 человек, и сразу получается как в том анекдоте про украинцев — уже партизанский отряд, уже они на голубом глазу начинают вещать от имени "всей индустрии".
Боюсь, ты плохо представляешь себе, как подобная троица смотрится в глазах десятков тысяч остальных читателей RSDN.
(да, обычно их 3-е активных каждый божий раз, когда поднимаются срачи, прямо число заколдованное, ы-ы-ы, иногда подключается на полшишечки 4-й, поэтому я обычно пользуюсь выражением "три с половиной человека" для описания этого странного феномена)
V>>Потому что, по-сути, ты даже сформулировать свои претензии толком не в состоянии. P>Серьезно? Ну перечитай мой первый комент. Что тут формулировать?
Это тебе стоило бы перечитать ответы, данные тебе. Потому что эти ответы связаны с тем, что ты писал. Потому что и контраргументы и уточняющие вопросы в наличии. А твои ответы — не связаны от слова никак. Ты как с 0-ля каждый раз пишешь, отсюда ноль продвижения и ходьба по-кругу.
Вот смог бы ты ответить на контраргументы и уточняющие вопросы, тогда, глядишь, постепенно и обозначилась бы осмысленная формулировка твоих претензий. Ну а нет, так нет.
P>Основная проблема — отсутствие стандартной инфраструктуры языка и невероятно медленное (ну просто микроскопическое) развитие.
"Стандартная инфраструктура языка" — сильно разное понятие с т.з. программистов на разных языках. Например, для Джавы, где интероп отсутствует как таковой, "стандартная инфраструктура" представляется эдакой вещью в себе, где "за МКАД-ом жизни нет". Если не напишешь на С/С++ для Джавы вспомогательную для интеропа функциональность — вот и нет никакой инфраструктуры.
И на дотнете ситуация не сильно ушла в сторону. Более-менее интероп прямо ср-вами языка возможен только OLE-совместимых АПИ: ф-ий, интерфейсов и лейаута типов данных (структур). Шаг вправо-влево и начинаются сложности — оперируешь через IntPtr как адресом и начинаешь ручками отсчитывать смещения (часто двигаясь по графу) для доступа к данным. Т.е. система типов умывает руки, программист начинает работать вместо компилятора. Такого кошмара даже программисты голого С не видят уже 40 лет. Опять рука-лицо.
В этом смысле "инфраструктура языка С++" — это сплав выразительных ср-в самого языка с легкостью доступа на самый низкий уровень платформы, поверх которой он работает (т.е. система типов продолжает работать и все выразительные ср-ва тоже). И с такой постановкой вопроса, заметь, индустрия не спорит. Но ты пытаешься. ))
P>Но критику комента ты по сути не можешь сформулировать толком. Всё время получается ровно два варианта: P>1) мне оно не надо/я этим не пользуюсь — значит никому не надо/никто не пользуется
Брехня. Было сказано об отсутствии необходимости прописывать логгер в стандарте и было 100 раз объяснено — почему. Просто ты игноришь неудобные тебе аргументы.
P>2) невозможно написать стандартную библиотеку чего либо в принципе
И это брехня. Вернее, это твои слова, которые ты всё время пытаешься приписать оппонентам. Похоже, спорить с реальными оппонентами тебе тяжело, зато выдумать себе чучело и "победить" его — вот тут доо-о-о...
Здравствуйте, vdimas, Вы писали:
V>на которых использование С++ не имеет смысла (типа Arduino/AVR)
На AVR использование плюсов как раз имеет очень много бенефитов. Как тебе реализация КА через шаблонную магию, например? Алгоритмы те же прекрасно работают. Динамической памяти нет, ну и хрен с ней.
Раскрою свои соображения насчёт логгера (бо меня утомило твоё хождение по-кругу, наводящие вопросы ты игноришь, к сути мы так никогда не доберёмся, очевидно).
================
Любая реализация чего-либо должна начинаться с концепции.
Например, когда концепции работы с потоками более-менее оформились в тех самых "платформах общего назначения", т.е. когда были набиты все шишки (на семафорах, например, которые были признаны небезопасными для прямого использования), т.е. когда были обкатаны хорошие и плохие практики, тогда и родилась реализация этой концепции.
Или, например, вопрос версионности ПО. MS изобрела офигенную штуку для преодоления "dll hell" — это технология "side by side" — SxS.
К сожалению, остальные платформы еще не созрели, у них еще происходит тот самый "dll hell" — абсолютно все unix-платформы, где пытаются с этим бороться менее продвинутыми ср-вами, например через вербальные соглашения о т.н. "semantic versions". С высоты птичьего полёта — это ха-ха три раза, но индустрия пока спасается тем что есть, как грится.
Так вот. Я не могу, разумеется, спорить с тем, что в области логгирования рано или поздно может родиться некая общепризнанная концепция. Пусть она будет сложна, многопланова, но она должна в любом случае созреть. А сейчас, блин, вовсю еще идут жаркие споры о том (прости хосподя), какой уровень логгирования должен быть более verbosity — DEBUG или TRACE, и вообще, насколько обосновано обозначать уровни логгирования в виде упорядоченного множества?
Т.е. пока мест индустрия "ищет себя" в этом плане. В некоторых логгерах и даже платформенных АПИ происходят компромиссы, например, где уровень логгирования кодируется через битовые поля: часть полей отвечают за упорядочивание множества уровней логгирования (вернее, их групп), а часть битовых полей отводится под неупорядоченное мн-во уровней логгирования внутри группы (например, уровни DEBUG и TRACE могут представляться эдакими независимыми "битовыми флагами" внутри своей "группы").
Кароч, в этой предметной области стоит только ногтём подцепить и хорошо видно, что в плане концепций еще даже конь не валялся.
А раз у индустрии на данный момент нет общепризнанной концепции/модели некоей функциональности, то не может быть и заказа на реализацию того, чего нет.
Здравствуйте, vdimas, Вы писали:
V>Или, например, вопрос версионности ПО. MS изобрела офигенную штуку для преодоления "dll hell" — это технология "side by side" — SxS. V>К сожалению, остальные платформы еще не созрели, у них еще происходит тот самый "dll hell" — абсолютно все unix-платформы, где пытаются с этим бороться менее продвинутыми ср-вами, например через вербальные соглашения о т.н. "semantic versions". С высоты птичьего полёта — это ха-ха три раза, но индустрия пока спасается тем что есть, как грится.
Ты всерьез про манифесты? Посмотри на NixOS с менеджером пакетов Nix. SxS рядом не валялся. Этом, можно сказать, динамически загружаемые библиотеки как статически слинкованные. Проблема не решается, появляется проблема хаоса из очень мало отличающихся версий либ. Один ад заменили другим адом.
Здравствуйте, landerhigh, Вы писали:
V>>на которых использование С++ не имеет смысла (типа Arduino/AVR) L>На AVR использование плюсов как раз имеет очень много бенефитов. Как тебе реализация КА через шаблонную магию, например? Алгоритмы те же прекрасно работают. Динамической памяти нет, ну и хрен с ней.
Да там помимо отсутствия new, есть еще куча приколов:
1. Стек данных и стек возврата независимы;
2. Стек возвратов аппаратный, стек данных — сугубо эмулируемый программный.
Т.е., реализация той самой "раскрутки стека" будет тяжелым мероприятием в том смысле, что подготовить десткрипторы фреймов стеков перед вызовом каждой ф-ии — это хана производительности. Итого RAII не имеет смысла, как и new.
А если взять PIC или x51, то там тоже в наличии лишь стеки возвратов, причём, глубиной всего 8. ))
В некоторых архитектурах стеки можно переключать (т.н. банки стеков).
Например, обработчик прерываний может переключиться на свой банк стеков.
Прикладная программа в этой схеме располагает глубиной стека аж 7, бо еще один уровень надо оставлять для обработчика прерываний. ))
Кароч, там куда ни ткни — овчинка выделки не стоит.
Здравствуйте, vdimas, Вы писали:
V>1. Стек данных и стек возврата независимы; V>2. Стек возвратов аппаратный, стек данных — сугубо эмулируемый программный.
Это всего лишь особенности.
V>Т.е., реализация той самый "раскрутки стека" будет тяжелым мероприятием в том смысле, что подготовить десткрипторы фреймов стеков перед вызовом каждой ф-ии — это хана производительности. Итого RAII не имеет смысла, как и new.
Какой смысл о RAII вообще начинать говорить, если динамической памяти нет?
V>А если взять PIC или
Зачем их брать, если для них компилятора плюсов даже нет?
Здравствуйте, fin_81, Вы писали: V>>Или, например, вопрос версионности ПО. MS изобрела офигенную штуку для преодоления "dll hell" — это технология "side by side" — SxS. V>>К сожалению, остальные платформы еще не созрели, у них еще происходит тот самый "dll hell" — абсолютно все unix-платформы, где пытаются с этим бороться менее продвинутыми ср-вами, например через вербальные соглашения о т.н. "semantic versions". С высоты птичьего полёта — это ха-ха три раза, но индустрия пока спасается тем что есть, как грится. _>Ты всерьез про манифесты?
Я про версионность с токенами.
В манифесте опционально указаны другие зависимости, тоже с токенами.
И/или своя "полная" версия.
Что такое "токен"? Он был введен для определения бинарной совместимости.
Например, бинарник версии "3.0" с токеном "А" удовлетворит затребованную зависимость "2.0 A", но её не удовлетворит другой бинарник "2.0 B".
Ведь именно поэтому в Linux невозможно сосуществование бинарников от разных сборок, что эти бинарники несовместимы (конфликтуют), хотя у них одинаковые или совместимые версии. Если бы ввести SxS в Linux, то можно было бы на одной системе иметь пакеты от разных сборок без всяких конфликтов, как это происходит в Windows.
_>Посмотри на NixOS с менеджером пакетов Nix.
Те же самые проблемы, которые решаются через ональную огороженность от других сборок линухов и даже от собственных сборок (разумеется!), которые имеют другую версию. ))
Трэш и угар, как по мне, но индустрия этим живёт сегодня.
_>SxS рядом не валялся.
Мде?
_>Этом, можно сказать, динамически загружаемые библиотеки как статически слинкованные.
Да это вообще не важно. Смотри в суть вещей. В линухах до сих пор ниасили link-time code generation, поэтому запросто, например, могут позволять себе подставлять статические библиотеки для динамических зависимостей. Рука-лицо, не? ))
_>Проблема не решается, появляется проблема хаоса из очень мало отличающихся версий либ. Один ад заменили другим адом.
Ну ты бы копнул SxS, там немного совсем.
Это не пакетный менеджер ни в одном из мест.
Это скромная такая, малюсенькая подсистема управления зависимостями.
ЛЮБОЙ адекватный виндовый пакетный менеджер должен сидеть поверх этой базы.
Здравствуйте, landerhigh, Вы писали:
L>Какой смысл о RAII вообще начинать говорить, если динамической памяти нет?
Как это нет? Память есть.
Зависит от конкретной аппаратной конфигурации.
Где-то 128 байт встроенного ОЗУ, где-то килобайты встроенного, а где-то можно подключить "большое" внешнее ОЗУ.
Т.е., вполне себе используют менеджеры памяти, когда это необходимо.
У меня был когда-то самописный даже для 512-ти байт ОЗУ, бо сами данные порой имеют динамическую природу.
V>>А если взять PIC или L>Зачем их брать, если для них компилятора плюсов даже нет?
Ну вот я их и взял, чтобы показать, почему там не плюсов. ))
Но С там есть.
Здравствуйте, vdimas, Вы писали:
V>Как это нет? Память есть.
Динамической в том смысле, в котором она присутствует на "больших" компах, там нет. И, что характерно, обычно и не надо.
V>Зависит от конкретной аппаратной конфигурации. V>Где-то 128 байт встроенного ОЗУ, где-то килобайты встроенного,
V>а где-то можно подключить "большое" внешнее ОЗУ.
Это ж не ОЗУ в прямом смысле этого слова.
V>Т.е., вполне себе используют менеджеры памяти, когда это необходимо. V>У меня был когда-то самописный даже для 512-ти байт ОЗУ, бо сами данные порой имеют динамическую природу.
Подобные "менеджеры памяти" иногда приходится и при разработки для полноценных PC изобретать
V>>>А если взять PIC или L>>Зачем их брать, если для них компилятора плюсов даже нет? V>Ну вот я их и взял, чтобы показать, почему там не плюсов. ))
