Случилось очередное ничем ни примечательное событие:
Rust включён в число основных языков для разработки платформы Android.
Думаю для котлина это фсё. А ведь пару лет назад я помню разговоры о том что котлин будущее андроида.
Здравствуйте, varenikAA, Вы писали:
AA>Случилось очередное ничем ни примечательное событие: AA>Rust включён в число основных языков для разработки платформы Android. AA>Думаю для котлина это фсё. А ведь пару лет назад я помню разговоры о том что котлин будущее андроида.
Здравствуйте, varenikAA, Вы писали:
AA>Случилось очередное ничем ни примечательное событие: AA>Rust включён в число основных языков для разработки платформы Android. AA>Думаю для котлина это фсё.
Это для С++ все. Котлин единственный живой язык для ЖВМ, нужен безотносительно Андроида.
Здравствуйте, GarryIV, Вы писали:
GIV>Это для С++ все. Котлин единственный живой язык для ЖВМ, нужен безотносительно Андроида.
Там груви, скала, кложур, цейлон, фантом. а вот котлин как раз делал ставку на андроид(со слов товарища).
Здравствуйте, varenikAA, Вы писали:
GIV>>Это для С++ все. Котлин единственный живой язык для ЖВМ, нужен безотносительно Андроида. AA>Там груви, скала, кложур, цейлон, фантом.
В говне недостатка нет.
В Android безопасная работа с памятью обеспечивается в уже поддерживаемых языках Kotlin и Java, но они не подходят для разработки системных компонентов из-за больших накладных расходов. Rust даёт возможность добиться производительности близкой к языкам C и С++, что позволяет использовать его для разработки низкоуровневых частей платформы и компонентов для взаимодействия с оборудованием.
Здравствуйте, varenikAA, Вы писали:
AA>Случилось очередное ничем ни примечательное событие: AA>Rust включён в число основных языков для разработки платформы Android. AA>Думаю для котлина это фсё. А ведь пару лет назад я помню разговоры о том что котлин будущее андроида.
Вы немного путаете. Rust используется для разработки самого Android,
можно назвать условно это SDK — набор библиотек, сервисов и т.к. которые состовляют
собственно Android, а Kotlin используется как язык для разработки конечных приложений
под Android. Это как с C# например, комплиятор C# и .NET VM и много еще чего связанного с
ним пишут на C++, но ведь на популярность и востебованность C# это особо не влияет.
Здравствуйте, varenikAA, Вы писали:
AA>Случилось очередное ничем ни примечательное событие: AA>Rust включён в число основных языков для разработки платформы Android. AA>Думаю для котлина это фсё. А ведь пару лет назад я помню разговоры о том что котлин будущее андроида.
Так Котлин, судя по наблюдениям, не только для Андроида используется, но и в бизнесе: для JEE-приложений (в основном для микросервисов). Разве там он умирает?
Z>под Android. Это как с C# например, комплиятор C# и .NET VM и много еще чего связанного с Z>ним пишут на C++, но ведь на популярность и востебованность C# это особо не влияет.
Уже лет 7 как компилятор C# написан на C#. И "много ещё чего" тоже переписано на C# из-за распространения .NET Core на другие платформы. Нейтив код живёт в основном там, откуда его убрать просто невозможно.
Здравствуйте, Zhendos, Вы писали:
Z>ним пишут на C++, но ведь на популярность и востебованность C# это особо не влияет.
на плюсах писать без подготовки невозможно, на расте если есть опыт в бейсике хотя бы разобраться в разы проще.
Здравствуйте, gyraboo, Вы писали:
G>Так Котлин, судя по наблюдениям, не только для Андроида используется, но и в бизнесе: для JEE-приложений (в основном для микросервисов). Разве там он умирает?
его использовали из-за тяжбы гугла с ораклом. котлин был страховкой.
на днях гугл выиграл тяжбу.
но и это не все.
В качестве примера на вскидку https://lib.rs/crates/stretch
Цели
High performance
Cross platform
Small binary size
И кто по вашему станет писать тормозную апликуху на котлине(который только взлетает, но еще не взлетел), если можно на расте ракету сделать.
Здравствуйте, varenikAA, Вы писали:
G>>Так Котлин, судя по наблюдениям, не только для Андроида используется, но и в бизнесе: для JEE-приложений (в основном для микросервисов). Разве там он умирает?
AA>его использовали из-за тяжбы гугла с ораклом. котлин был страховкой. AA>на днях гугл выиграл тяжбу. AA>но и это не все. AA>В качестве примера на вскидку AA>https://lib.rs/crates/stretch AA>Цели AA>High performance AA>Cross platform AA>Small binary size AA>И кто по вашему станет писать тормозную апликуху на котлине(который только взлетает, но еще не взлетел), если можно на расте ракету сделать.
Всё бы хорошо, но вот тут на форуме писали, что серьезные программы на Расте писать тяжело, начинается коллапс головного мозга из-за сложности языка и избыточности конструкций. Сам на Расте не писал, так что мнения не имею, осуждать Пастернака почём зря не хочу.
Здравствуйте, varenikAA, Вы писали:
Z>>ним пишут на C++, но ведь на популярность и востебованность C# это особо не влияет. AA>на плюсах писать без подготовки невозможно, на расте если есть опыт в бейсике хотя бы разобраться в разы проще.
Наверное я очень плохой программист, т.к. просто взять и начать писать на Rust у меня не выходит
Здравствуйте, gyraboo, Вы писали:
G>Всё бы хорошо, но вот тут на форуме писали, что серьезные программы на Расте писать тяжело, начинается коллапс головного мозга из-за сложности языка и избыточности конструкций. Сам на Расте не писал, так что мнения не имею, осуждать Пастернака почём зря не хочу.
Думаю тут дело в том, что многие приходят в раст из NRE мира и когда видят что например файл возвращает Ok(file) или Error то это непривычно не более, нужно лишь встроить эти абстракции в мозг.
так то вообще перелистывая журналы 10-летней давности вижу все одну и туже тенденцию — разворот в сторону ФП.
Вчера в докладе на дотнексте промелькнула ссылка https://www.blazorfluentui.net/ ФМ от микрософта на их же технологии!
Жуть просто.
И все упирается в язык которой может прекрасен, но реализация прибита к VM NET и похоже лучше не будет с производительностью.
у раста только один конкурент: D.
и еще не факт кто в итоге выживет.
ведь в D тоже есть ФП:
int apply(int function(int) pure fun , int value)
{
return fun(value);
}
int addOne(int a) pure
{
return a + 1;
}
int main()
{
return apply(&addOne, 1);
}
В си оно правда тоже было, но ди попытка найти баланс между железом и софтом в виде делегатов и защиты(pure)
int apply(int (*fun) (int), int value)
{
return (*fun)(value);
}
int addOne(int a)
{
return a + 1;
}
int main()
{
return apply(&addOne, 1);
}
Здравствуйте, kaa.python, Вы писали:
KP>Наверное я очень плохой программист, т.к. просто взять и начать писать на Rust у меня не выходит
Для любого ЯП нужна задача, ведь это инструмент.
Будет возможность: попробуйте. Или хотя бы повторите игру гусь из раста-книги. отнимет полчаса от силы.
Тут конечно плюсы рядом не стояли. одна настройка окружения рабочего для проекта отнимет минимум полдня
Здравствуйте, varenikAA, Вы писали:
AA>Тут конечно плюсы рядом не стояли. одна настройка окружения рабочего для проекта отнимет минимум полдня
Ну это если руки прям из жопы растут, то да, полдня. Если хотя бы в районе пояса, то где-то час. Ну а вообще если человек знает что такое CMake и Conan, то настройка проекта с практически любым набором библиотек делается за 3-5 минут.
Здравствуйте, kaa.python, Вы писали:
KP>Ну это если руки прям из жопы растут, то да, полдня. Если хотя бы в районе пояса, то где-то час. Ну а вообще если человек знает что такое CMake и Conan, то настройка проекта с практически любым набором библиотек делается за 3-5 минут.
Черный пояс по плюсам?
Уважаю!
Здравствуйте, kaa.python, Вы писали:
KP>Ну это если руки прям из жопы растут, то да, полдня. Если хотя бы в районе пояса, то где-то час. Ну а вообще если человек знает что такое CMake и Conan, то настройка проекта с практически любым набором библиотек делается за 3-5 минут.
Под Линуксом может быть, но врядли. Только apt install build-essential libboost-all-dev cmake git etc будет дольше идти. А многие библиотеки ещё и самому собирать надо, потому что или версии не те, или дефолтные сборки не с теми флагами сделаны.
Здравствуйте, Nuzhny, Вы писали:
N>Под Линуксом может быть, но врядли. Только apt install build-essential libboost-all-dev cmake git etc будет дольше идти. А многие библиотеки ещё и самому собирать надо, потому что или версии не те, или дефолтные сборки не с теми флагами сделаны.
Мне кажется немного странным учитывать время установки компилятора и CMake во времени создания проекта.
Собирать что-то самому есть используешь Конан надо только если у тебя какие-то хитрые флаги. Тот-же Буст это просто одна строка в conanfile. Один в один как с requirement.txt
Ну и да, само собой по Линуксом или Маком. Что там в стане виндузятников я смутно представляю. Мир кликателей мышой довольно специфичен.
Здравствуйте, kaa.python, Вы писали:
KP>Ну это если руки прям из жопы растут, то да, полдня. Если хотя бы в районе пояса, то где-то час. Ну а вообще если человек знает что такое CMake и Conan, то настройка проекта с практически любым набором библиотек делается за 3-5 минут.
А если человек не знает, что такое make и autotools, то настройка проекта так и не будет сделана вообще.
Здравствуйте, kaa.python, Вы писали:
KP>Ну и да, само собой по Линуксом или Маком. Что там в стане виндузятников я смутно представляю.
А там всё до безобразия просто — вижуалку поставил и тыкай в проект. Под маком по нормальному то же самое — XCode и проект.
Это только если проект луноходы начинали там вша и червие, куча зависимостей которые надо откуда то из жопы вынуть, скриптота на пяти языках + двух версиях питона, не совместимых друг с дружкой, и прочие прелести дендрофекальной наколенной разработки.
KP> Мир кликателей мышой довольно специфичен.
Это скорее про макось, в которой без мыши вообще никак, даже ОС не поставить.
Здравствуйте, Слава, Вы писали:
С>А если человек не знает, что такое make и autotools, то настройка проекта так и не будет сделана вообще.
Я проектов под make уже очень давно не видел.
Здравствуйте, CreatorCray, Вы писали:
С>>А если человек не знает, что такое make и autotools, то настройка проекта так и не будет сделана вообще. CC>Я проектов под make уже очень давно не видел.
Здравствуйте, CreatorCray, Вы писали:
CC>А там всё до безобразия просто — вижуалку поставил и тыкай в проект.
А как оно со сторонними библиотеками дружится? Знаю про vcpkg, но с ним не так просто, когда надо работать с разными версиями библиотек. Например, на недавней CppRussia чувак из Nvidia рассазывал, как надо захачить vcpkg, чтобы это побороть. Ещё хуже, намного хуже, чем самому всё делать.
Здравствуйте, gyraboo, Вы писали:
AA>>Случилось очередное ничем ни примечательное событие: AA>>Rust включён в число основных языков для разработки платформы Android. AA>>Думаю для котлина это фсё. А ведь пару лет назад я помню разговоры о том что котлин будущее андроида.
G>Так Котлин, судя по наблюдениям, не только для Андроида используется, но и в бизнесе: для JEE-приложений (в основном для микросервисов). Разве там он умирает?
Он в бэкэнде редко используется, там в основном Java, насколько я знаю. Реально много он в Андроиде используется. Впрочем оттуда он никуда уже не денется, это всё болтовня.
Здравствуйте, kaa.python, Вы писали:
KP>Ну это если руки прям из жопы растут, то да, полдня. Если хотя бы в районе пояса, то где-то час. Ну а вообще если человек знает что такое CMake и Conan, то настройка проекта с практически любым набором библиотек делается за 3-5 минут.
Только сколько лет вам понадобилось чтобы достичь такого совершенства?
Здравствуйте, varenikAA, Вы писали:
AA>Думаю для котлина это фсё. А ведь пару лет назад я помню разговоры о том что котлин будущее андроида.
Во первых, Котлин это настоящее андроида. Во вторых, ты попробуй пописать на Rust и Kotlin, посмотри на чем у тебя быстрее и комфортнее будет получаться. Уверяю, что не на Rust. У Rust другая ниша — всякие низкоуровневые штуки с минимальным оверхедом, и эта ниша весьма и весьма узкая, разработка ОС как раз в нее впихивается. И в третьих, даже для бекенда все больше компаний используют Kotlin, по крайней мере мне периодически такие вакансии присылают, да я и сам backend сейчас пилю именно на Kotlin.
Здравствуйте, varenikAA, Вы писали:
AA>Только сколько лет вам понадобилось чтобы достичь такого совершенства?
Это сильно не совершенство, постигается легко если разработчик хоть чуть-чуть инфраструктурой интересуется. Ну вот сколько надо времени что бы осилить вот такое руководство и потом базируясь на нем создать проект?
Здравствуйте, kaa.python, Вы писали:
KP>Это сильно не совершенство, постигается легко если разработчик хоть чуть-чуть инфраструктурой интересуется. Ну вот сколько надо времени что бы осилить вот такое руководство и потом базируясь на нем создать проект?
А почему, кстати, conan, а не vcpkg? Казалось бы у него больше пакетов на порядок, наисан на С++, ничего стороннего тянуть не надо...
Здравствуйте, Nuzhny, Вы писали:
N>А почему, кстати, conan, а не vcpkg? Казалось бы у него больше пакетов на порядок, наисан на С++, ничего стороннего тянуть не надо...
С точки зрения корпоративного пользователя у Конана очень удобные репозитории и хорошая интеграция с Jenkins. Для домашних проектов он тоже удобнее, как минимум на Linux, т.к. пакеты в vcpkg иногда кривые. Я там как-то банально не мог найти без ошибок собранного Буста
Кстати про написан на C++. На Linux это часто минус, т.к. хз будет ли рантайм совместим. Обрати внимание как эта радость устанавливается на Linux. Так что для Linux я всегда предпочитаю на Python написанные средства автоматизации.
Здравствуйте, Artifact, Вы писали:
A>Какие же выводы делает Гугл? Во всём конечно же виноват язык программирования, а никак не их "светлые" головы. У меня просто нет слов.
А вот если бы тебя позвали, то все было бы по-другому?
Совершенно правильный вывод. Вывод, что во всем виноваты люди совершенно бесполезный. Так можно было и дальше ассемблера не ходить.
Здравствуйте, Nuzhny, Вы писали:
N> Знаю про vcpkg, но с ним не так просто, когда надо работать с разными версиями библиотек. Например, на недавней CppRussia чувак из Nvidia рассазывал, как надо захачить vcpkg, чтобы это побороть. Ещё хуже, намного хуже, чем самому всё делать.
Я не заморачивался, всё что было надо ставил руками.
Здравствуйте, kaa.python, Вы писали:
KP>Кстати про написан на C++. На Linux это часто минус, т.к. хз будет ли рантайм совместим.
Потому правильный софт всё что можно собирает статически а что нельзя — несёт с собой.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, kaa.python, Вы писали:
KP>>Кстати про написан на C++. На Linux это часто минус, т.к. хз будет ли рантайм совместим. CC>Потому правильный софт всё что можно собирает статически а что нельзя — несёт с собой.
Правильный софт ставиться менеджером пакетов из репозитория.
Здравствуйте, kaa.python, Вы писали:
KP>Правильный софт ставиться менеджером пакетов из репозитория.
Правильный софт не нужно устанавливать. Максимум должно быть ридми с описание что должно быть еще доступно на системе.
Когда еще был совсем зеленый считал установщики священной коровой, а потом прозрел.
Вот на дня тестил софт. версия портабл — распаковал и запустил. запустилась.
работает идеально. правда зачем-то без разрешения C:\temp создала
и в автозагрузку прописалась(за такое надо наказывать, и так полно непонятных файлов на диске).
Причем написана явно на нативном чем-то.
менеджер пакетов нужен для домене когда безопасность это ответственность администратора домена
и только он должен иметь право установить программу.
Здравствуйте, elmal, Вы писали:
E>Во первых, Котлин это настоящее андроида. Во вторых, ты попробуй пописать на Rust и Kotlin,
Пробовал, после изучения F# не вызывает никаких проблем, достаточно понимать разницу между инструкцией и выражением.
серьезно. На ютубе есть лекции по расту.
Главная фишка из первой лекции что раст предоставляет отличные абстракции бесплатно.
Там он правда со скалой сравнил, но тем не менее.
Это типичный бред который может придти только в больной мозг виндузятников. Ну да, ведь это невероятно увлекательно помнить что и куда ты распаковал что бы потом не забыть это нечто обновлять, а уж коли захочешь удалить то лизаить по машине и смореть что там и где валяется
Здравствуйте, kaa.python, Вы писали:
KP>Это типичный бред который может придти только в больной мозг виндузятников. Ну да, ведь это невероятно увлекательно помнить что и куда ты распаковал что бы потом не забыть это нечто обновлять, а уж коли захочешь удалить то лизаить по машине и смореть что там и где валяется
Здравствуйте, Artem Korneev, Вы писали:
AK>Ну так наверное потому и присылают, что:
Не поэтому. Я резюме лет 5 не обновлял, у рекрутеров резюме совсем без экзотики.
Здравствуйте, CreatorCray, Вы писали:
CC>У меня либо вижуалка либо xcode, так что всё там
Т.е. у тебя проект можно собрать только с одной кошерной IDE?
Здравствуйте, kaa.python, Вы писали:
KP>Ну а вообще если человек знает что такое CMake и Conan, то настройка проекта с практически любым набором библиотек делается за 3-5 минут.
Проблема в том, что CMake толком не знает практически никто, т.к. это такие знания, которые нужны раз в полгода, а убогий синтаксис CMake и нелогичность крайне способствуют тому, что мозг старается выкинуть остатки знаний как можно скорее. В итоге в большистве случаев когда возникает задача типа "как же мне наследовать параметры компиляции" используется первое найденое на SO решение, которое обычно устаревшее и кривое.
CMake лучше чем ничего и задачу любую решить может, но это боль и уродство. Я бы променял все фичи С++14/17/21 на нормальную стандартную систему сборки.
Здравствуйте, Skorodum, Вы писали:
S>Т.е. у тебя проект можно собрать только с одной кошерной IDE?
Часто можно и без IDE, достаточно компилятора с утилитами и SDK с библиотеками.
Ну и никто не запрещает IDE экспортировать проект в тот же CMake-овский файл, или что там сейчас модно
Или еще проще — а что ему (или мне) помешает и далее пользоваться той кошерной IDE
Здравствуйте, Skorodum, Вы писали:
S>CMake лучше чем ничего и задачу любую решить может, но это боль и уродство. Я бы променял все фичи С++14/17/21 на нормальную стандартную систему сборки.
Да я как бы на 100% согласен что CMake — это кривое говно. Только проблема в том, что это кривое говно лучшее что есть в мире C++ для сборки на сегодня
Здравствуйте, kaa.python, Вы писали:
KP>Да я как бы на 100% согласен что CMake — это кривое говно. Только проблема в том, что это кривое говно лучшее что есть в мире C++ для сборки на сегодня
qbs лучше, но не взлетел. build2 говорят не плохой, но тоже вряд ли уже взлетит.
Здравствуйте, Skorodum, Вы писали:
S>qbs лучше, но не взлетел. build2 говорят не плохой, но тоже вряд ли уже взлетит.
Еще есть https://bazel.build. Сам пока с ним не работал, но восторги слышал. Правда что build2, что qbs, что bazel не поддерживаются нормально IDE... и сразу "Привет Vim!". Не то что бы я не люблю Vim, но современный CLion всё же удобнее.
Здравствуйте, pagid, Вы писали:
P>Часто можно и без IDE, достаточно компилятора с утилитами и SDK с библиотеками.
Можно. Следующий шаг использовать кросслатформенные (почти стандартные) утилиты а-ля CMake. Ч. и Т.Д.
P>Ну и никто не запрещает IDE экспортировать проект в тот же CMake-овский файл, или что там сейчас модно
Религия мешает:
1. Это нарушение DRY
2. Ненужный шаг: сборка получается 3-х ступенчатой, соответсвенно вероятность и сложность проблем растет.
3. Любой проект на CMake выглядит ужасно, экспортированный будет ужас-ужас-ужас.
P>Или еще проще — а что ему (или мне) помешает и далее пользоваться той кошерной IDE
Ничего. Только это не гибко и не стандартно со всеми вытекающими последствиями.
В случае Студийных солюшенов еще добавляется неудобоство просмотра изменений. Даже самый плохой CMakelists.txt лучше сгенеренного машиной XML.
Что там XCode к счастью не знаю.
Здравствуйте, Skorodum, Вы писали:
S>Можно. Следующий шаг использовать кросслатформенные (почти стандартные) утилиты а-ля CMake. Ч. и Т.Д.
Цель этого шага?
S>2. Ненужный шаг: сборка получается 3-х ступенчатой, соответсвенно вероятность и сложность проблем растет. S>3. Любой проект на CMake выглядит ужасно, экспортированный будет ужас-ужас-ужас.
Так он обычно и ненужный, но если уж очень хочется...
S>Ничего. Только это не гибко и не стандартно со всеми вытекающими последствиями.
Гибкость она нужна только когда нужна, иначе это не гибкость, а избыточное усложнение. А насчет стандарта, то наверно стоит название этого стандарта узнать и организацию его принявшую, затем можно пообсуждать пользу от его использования.
Здравствуйте, kaa.python, Вы писали:
KP>Еще есть https://bazel.build. Сам пока с ним не работал, но восторги слышал. Правда что build2, что qbs, что bazel не поддерживаются нормально IDE... и сразу "Привет Vim!".
QtCreator поддерживает qbs
KP>Не то что бы я не люблю Vim, но современный CLion всё же удобнее.
Вроде сейчас все системы сборки и IDE движутся в сторону [url=https://www.jetbrains.com/help/clion/compilation-database.html], так что скоро наступит светлое совместимое будущее.
Здравствуйте, pagid, Вы писали:
P>Цель этого шага?
Поддержка разработки на любой платформе
P>Так он обычно и ненужный, но если уж очень хочется...
"Обычно" это если мир ограничен разработкой на одной платформе, под одну платформу и одним компилятором. В таком мире можно и С++ не пользоваться очень часто.
P>Гибкость она нужна только когда нужна, иначе это не гибкость, а избыточное усложнение.
А я соглсен. Только вот в С++ мире эта гибкость чаще нужна, чем не нужна.
P>А насчет стандарта, то наверно стоит название этого стандарта узнать и организацию его принявшую, затем можно пообсуждать пользу от его использования.
Тут разговор про то, что более стандартно (распространенно). CMake более стандартент чем солюшены.
Здравствуйте, Skorodum, Вы писали:
CC>>У меня либо вижуалка либо xcode, так что всё там S>Т.е. у тебя проект можно собрать только с одной кошерной IDE?
Собрать то можно чем угодно, а вот разработка в IDE на порядки удобнее.
Тот же xcodebuild коммандлайновый но проект понимает ничуть не хуже.
Здравствуйте, Skorodum, Вы писали:
S>Следующий шаг использовать кросслатформенные (почти стандартные) утилиты а-ля CMake. Ч. и Т.Д.
Нафига?
P>>Или еще проще — а что ему (или мне) помешает и далее пользоваться той кошерной IDE S>Ничего. Только это не гибко и не стандартно со всеми вытекающими последствиями.
А нахрена все эти навороты в зоопарке? KISS никто не отменял.
S>В случае Студийных солюшенов еще добавляется неудобоство просмотра изменений.
В новой студии стало хуже, в старой прекрасно было видно что поменялось, просто потому что XML там был человекочитаемый.
S>Что там XCode к счастью не знаю.
Там всё совсем плохо в плане понять чтож оно поменяло то.
Да и в принципе даже старая вижуалка с ассистом кроет новый хэкод как бык овцу практически во всём касательно продуманности и удобства.
Здравствуйте, Skorodum, Вы писали:
P>>Цель этого шага? S>Поддержка разработки на любой платформе
А нахрена?
S>"Обычно" это если мир ограничен разработкой на одной платформе
Что в большинстве случаев так.
S> под одну платформу и одним компилятором. В таком мире можно и С++ не пользоваться очень часто.
В таком мире как раз С++ приносит одно удовольствие
P>>Гибкость она нужна только когда нужна, иначе это не гибкость, а избыточное усложнение. S>А я соглсен. Только вот в С++ мире эта гибкость чаще нужна, чем не нужна.
Да вот как то нет.
Пишется продукт, у продукта есть требования, в том числе по платформе. Просто так на многоплатформу писать — пустая трата Вилли стоя в гамаке на лыжах.
S>Тут разговор про то, что более стандартно (распространенно).
Unknown definition
Здравствуйте, CreatorCray, Вы писали:
S>>Поддержка разработки на любой платформе CC>А нахрена?
Чтобы не делать несколько конфигураций. Кажется, что затачиваться под одну платформу чуть ли не сложнее, чем под несколько. Даже когда у меня была разработка windows only, я с радостью перешёл на CMake. А потом стало ещё проще: внезапно кто-то говорит: "А давай запустим проект на nvidia jetson!" И требуется минимум работы, чтобы CMake адаптировать под это дело.
Здравствуйте, varenikAA, Вы писали:
AA>Вчера в докладе на дотнексте промелькнула ссылка https://www.blazorfluentui.net/ ФМ от микрософта на их же технологии! AA>Жуть просто. AA>И все упирается в язык которой может прекрасен, но реализация прибита к VM NET и похоже лучше не будет с производительностью.
PJ>А вот если бы тебя позвали, то все было бы по-другому?
А почему ты так уверен, что нет?
PJ>Совершенно правильный вывод. Вывод, что во всем виноваты люди совершенно бесполезный. Так можно было и дальше ассемблера не ходить.
Все ошибки с памятью, которые можно допустить в C++, давно известны. Неужели так трудно научить своих сотрудников их не делать? Да, лучше, если компилятор будет бить по рукам, если делаешь, что-то нетак. Но в приведённой статье есть более интересный момент
For complex C/C++ code bases, often there are only a handful of people capable of developing and reviewing the fix, and even with a high amount of effort spent on fixing bugs, sometimes the fixes are incorrect.
complex C/C++ code bases — сложный C/C++ код.
there are only a handful of people capable of developing and reviewing the fix — немного людей, кто в состоянии устранить ошибку.
Иными словами гугл подтверждает, что в их коде чёрт ногу сломит.
Насколько мне известно, чтобы из сложного кода сделать код проще, требуется приложить определённые умственные усилия, а не просто поменять язык программирования.
Прежде чем начать читать статью, я пробежал глазами по коду. Первое за что я зацепился было это
if ((size_t)(mDataSource->readAt(*offset, buffer + size, chunk_size))
< chunk_size)
Зачем понадобился каст в size_t? Для любого опытного С++ программиста любой каст это сразу же намёк, что что-то тут нетак. Что возвращает mDataSource->readAt ? Это int? А если он вернёт -1, а мы это скастим в size_t, мы получим 18446744073709551615 (если это 64 битная платформа). Это точно то, чего добивался автор?
Это реально трудно заметить, или у меня дар божий?
Блин (через "ять"). И откуда только такие дилетанты лезут? Очевидно же, даже не открывая текст статьи, что его добавили в NDK. Туда, где до этого безраздельно царили C и плюсы.
Перефразируя старый баян: Слоны идут на..., а Java и Kotlin живут этажом выше
A>Перевожу: большинство багов с памятью возникает в новом или недавно изменённом коде; примерно 50% багов находится в коде написанном один год назад. A>Что это значит? Это значит, что в старом коде уже без поллитры не разберёшся, и разработчики, не поняв что к чему, делают ошибки.
Ото ж. Давайте, значит, посадим раст-о-манов с красными глазами, и сделаем старый код настолько write–only, чтобы разобраться нельзя было и без цистерны. Добавим побольше ломающих изменений между версиями. И сдобрим отсутствием консорциума, явно писаных стандартов, невменяемой документацией и шибзданутым сообществом, которое будет набигать с криками "так на расте писать нельзя!". Единственным выходом будет всё переписывать к Евгении Марковне, а не разбираться. И по метрикам всё отлично: меньше кода — меньше багов))
Писец, поколение анацефалов. Так помешались на этой безопасности, что, похоже, детей своих будут с рождения в бетон заливать. Чтобы не дай бог не ушиблись от падения, это же тааак опааасно. И жуткую короняяяку не подхватили ненароком, выбежав на улицу.
Здравствуйте, CreatorCray, Вы писали:
CC>Собрать то можно чем угодно
Чем можно собрать студийный солюшн кроме студии и msbuild?
CC>а вот разработка в IDE на порядки удобнее.
Вот. Только IDE разные. У нас разработчики пользуются всеми основными: студией, Vim, CLion, QCreator, на всех трех платформах. И 5-6 разными компиляторами.
Здравствуйте, CreatorCray, Вы писали:
CC>Нафига?
Потому что оно во всём лучше чем решение от МС
CC>А нахрена все эти навороты в зоопарке? KISS никто не отменял.
Потому что твое решение остается простым в очень ограниченном мире: одна платформа, один компилятор, одна IDE и никаких хитрых шагов при сборке. Любой мало-мальский шаг в сторону из этого уютного мирка заканчивается костылями в виде скриптов разной степени кривости.
CC>В новой студии стало хуже, в старой прекрасно было видно что поменялось, просто потому что XML там был человекочитаемый.
"человекочитаемый XML" это какой-то оксюморон. Прочитать-то можно, но нафиг не нужно.
CC>Да и в принципе даже старая вижуалка с ассистом кроет новый хэкод как бык овцу практически во всём касательно продуманности и удобства.
Об XCode вообще хороших отзывов мало
Здравствуйте, CreatorCray, Вы писали:
CC>А нахрена?
А почему нет?
Причин и плюсов много, начиная от требований к продукту и не заканчивая простотой поиска сотрудников (т.к. нет ограничений по IDE и ОС для разработки, что для многих плюсовиков критично и ты сам отлично демонстрируешь).
S>>"Обычно" это если мир ограничен разработкой на одной платформе CC>Что в большинстве случаев так.
А я говорю нет
CC>В таком мире как раз С++ приносит одно удовольствие
Никто не спорит с этим, только такого мало. С++ вообще мало, а такого и того меньше.
CC>Да вот как то нет. CC>Пишется продукт, у продукта есть требования, в том числе по платформе. Просто так на многоплатформу писать — пустая трата Вилли стоя в гамаке на лыжах.
Ты мешаешь в кучу две разные проблемы: поддержка целевых платформ и поддержка платформ для разработки. Про первое без необходимости речь никто не ведет обычно. А второе в ЦПП мире есть из коробки если не завязываться на продукты МС.
S>>Тут разговор про то, что более стандартно (распространенно). CC>Unknown definition
Ок.
Здравствуйте, Artifact, Вы писали:
A>А почему ты так уверен, что нет?
Я уверен? Я спрашиваю. Где-то же этот идеальный программист должен существовать...
PJ>>Совершенно правильный вывод. Вывод, что во всем виноваты люди совершенно бесполезный. Так можно было и дальше ассемблера не ходить. A>Все ошибки с памятью, которые можно допустить в C++, давно известны. Неужели так трудно научить своих сотрудников их не делать? Да, лучше, если компилятор будет бить по рукам, если делаешь, что-то нетак. Но в приведённой статье есть более интересный момент
Да чо уж там, вообще все ошибки давно известны. Надо только писать без них.
A>Иными словами гугл подтверждает, что в их коде чёрт ногу сломит.
Эх, жалко, что нельзя взглянуть на твой совершенный код.
A>Насколько мне известно, чтобы из сложного кода сделать код проще, требуется приложить определённые умственные усилия, а не просто поменять язык программирования.
Это если умственные усилия больше направить некуда. Так случается, что некоторые, еще не познавшие дзен, или которых он уже задолбал, желают не с языком бороться, решая задачи за компилятор, а наоборот — что бы компилятор им помогал.
A>Прежде чем начать читать статью, я пробежал глазами по коду. Первое за что я зацепился было это
Т.е. за какую-то левую фигню, возможно совершенно безопасную, а не за реальный баг, где опытному программисту зацепиться не за что было, там кастов нет...
Здравствуйте, Nuzhny, Вы писали:
N>Чтобы не делать несколько конфигураций.
Какие конфигурации тут имеются в виду?
N> Кажется, что затачиваться под одну платформу чуть ли не сложнее, чем под несколько.
Отнюдь.
Здравствуйте, Skorodum, Вы писали:
CC>>А нахрена? S>А почему нет?
Потому что KISS. Если нет в том реальной необходимости — нехрен париться.
S>Причин и плюсов много, начиная от требований к продукту
Что это за требования к продукту которые хотят чтоб его код можно было писать на зоопарке платформ и тулов?
S> (т.к. нет ограничений по IDE и ОС для разработки, что для многих плюсовиков критично и ты сам отлично демонстрируешь).
Сколько я раз видел случаев когда позволяли писать в чём хочется столько раз что проект что код превращался в говно.
Так что тут категорическое нет и диктатура с расстрелами. Есть единый dev environment, все пишут в нём.
S> А второе в ЦПП мире есть из коробки если не завязываться на продукты МС.
Если не завязываться на нормальные IDE ты хотел сказать. Не, ну можно врукопашную всё фигачить, и считать что этот аскетизм — норма.
Здравствуйте, Skorodum, Вы писали:
CC>>Нафига? S>Потому что оно во всём лучше чем решение от МС
А именно?
CC>>А нахрена все эти навороты в зоопарке? KISS никто не отменял. S>Потому что твое решение остается простым в очень ограниченном мире: одна платформа, один компилятор, одна IDE и никаких хитрых шагов при сборке.
К этому следует стремиться.
S> Любой мало-мальский шаг в сторону из этого уютного мирка заканчивается костылями в виде скриптов разной степени кривости.
Или расстрелами тех, кто полез лепить что то странное.
CC>>В новой студии стало хуже, в старой прекрасно было видно что поменялось, просто потому что XML там был человекочитаемый. S>"человекочитаемый XML" это какой-то оксюморон. Прочитать-то можно, но нафиг не нужно.
Нужно для того, чтобы понять по diff что поменялось. Именно для человека текстовые форматы и придумываются.
Здравствуйте, Skorodum, Вы писали:
CC>>Собрать то можно чем угодно S>Чем можно собрать студийный солюшн кроме студии и msbuild?
Начнём с простого вопроса: зачем?
CC>>а вот разработка в IDE на порядки удобнее. S>Вот. Только IDE разные. У нас разработчики пользуются всеми основными: студией, Vim, CLion, QCreator, на всех трех платформах. И 5-6 разными компиляторами.
Бардак!
Послушай, мне твой сарказм совсем неинтересен. Всё что я хочу, чтобы вещи называли своими именами. Последний раз я тут попытаюсь донести свою мысль. Если ваш код представляет из себя ребус, это ваша вина, а не языка программирования, на котором этот код написан. Люди, которые написали запутанный код на языке А, напишут такой же запутанный код и на языке В. Я считаю, что более правильным путём является повышение профессионального уровня разработчиков.
Здравствуйте, Artifact, Вы писали:
A>Послушай, мне твой сарказм совсем неинтересен. Всё что я хочу, чтобы вещи называли своими именами. Последний раз я тут попытаюсь донести свою мысль. Если ваш код представляет из себя ребус, это ваша вина, а не языка программирования, на котором этот код написан. Люди, которые написали запутанный код на языке А, напишут такой же запутанный код и на языке В. Я считаю, что более правильным путём является повышение профессионального уровня разработчиков.
О, я тоже так всегда считал до тех пор, пока не поработал в одной замечательной американской компании. Вот представь себе, есть команда, которая пишет на плюсах как в старые добрые времена 98 стандарта. К тестам относится приблизительно так же. Учиться не хочет, а уволить по причине "люди-то хорошие" нельзя. Команда, конечно, не вся такая, но изрядная её часть, причём самый активный чувак, взявший на себя роль архитектора, главный говнокодер. И всё было плохо до тех пор, пока не появился в команде один умный человек (этот человек не я, к сожалению) и не сказал "нахер плюсы, пишем на Го". И тут случилась ну просто магия! Язык на столько простой и позволяющий невероятно легко принудить к следованию тем не многим правилам что в нем есть, что команда даже начала писать нормальный код. Ну да, под присмотром, но теперь то почти основная часть этого присмотра автоматизировалась.
Так что, инструмент решает и те же люди что говнокодят на плюсах вполне могут выдать нормальный код на Го. Про Раст не уверен, очень уж сложный язык, тот же уровень сложности что и плюсы. Но так как контроль за соблюдением правил владения из коробки, может тоже хорошая опция. В особо сложных ситуациях, когда у команды руки явно из жопы растут, а машинный код без GC нужен, я бы рискнул, хуже не будет точно.
Здравствуйте, CreatorCray, Вы писали:
CC>Так что тут категорическое нет и диктатура с расстрелами. Есть единый dev environment, все пишут в нём.
Ein Volk, Ein Reich, Ein Führer.
В нормальных компаниях пофиг на чём разработчики пишут. Я уж не говорю о том, что для той же iOS приходится использовать вообще отдельное уродство для сборки.
S>> А второе в ЦПП мире есть из коробки если не завязываться на продукты МС. CC>Если не завязываться на нормальные IDE ты хотел сказать.
А где у MS нормальные IDE? Единственная нормальная IDE для С++ — это CLion.
Здравствуйте, Artifact, Вы писали:
A>Здравствуйте, Poopy Joe, Вы писали:
A>Послушай, мне твой сарказм совсем неинтересен. Всё что я хочу, чтобы вещи называли своими именами.
О, не сомневаюсь. "Назвать" вещи своими именами любят многие. Но, как правило, они же, очень не любят выслушивать выслушивать подобное о себе.
A>Последний раз я тут попытаюсь донести свою мысль. Если ваш код представляет из себя ребус, это ваша вина, а не языка программирования, на котором этот код написан. Люди, которые написали запутанный код на языке А, напишут такой же запутанный код и на языке В. Я считаю, что более правильным путём является повышение профессионального уровня разработчиков.
Тебе надо перейти на брейнфак, ну чисто в целях повышения квалификации!
Здравствуйте, Cyberax, Вы писали:
CC>>Так что тут категорическое нет и диктатура с расстрелами. Есть единый dev environment, все пишут в нём. C>Ein Volk, Ein Reich, Ein Fuhrer.
Я смотрю Ватсон без зигования уже не может
C>В нормальных компаниях пофиг на чём разработчики пишут.
Это выражается в том, что ты можешь для себя лично заколхозить что угодно но всё равно всё должно работать через официальный путь. Как ты будешь это обеспечивать — твои проблемы, но компания не будет устраивать для тебя зоопарк.
C> Я уж не говорю о том, что для той же iOS приходится использовать вообще отдельное уродство для сборки.
Собираю что iOS что все остальные таргеты в одном и том же XCode
CC>>Если не завязываться на нормальные IDE ты хотел сказать. C>А где у MS нормальные IDE?
Вижуалка, старая есессна.
C> Единственная нормальная IDE для С++ — это CLion.
Здравствуйте, CreatorCray, Вы писали:
C>>В нормальных компаниях пофиг на чём разработчики пишут. CC>Это выражается в том, что ты можешь для себя лично заколхозить что угодно но всё равно всё должно работать через официальный путь. Как ты будешь это обеспечивать — твои проблемы, но компания не будет устраивать для тебя зоопарк.
Нет. В нормальных компаниях официальный путь — это pull-requests в Github/Gitlab/whatever. Которые затем строятся через CI и тестируются. Сам CI может достаточно сильно отличаться от окружения разработчика.
А как конкретно формируются PR — это никого особо не интересует. Пусть хоть через модем насвистываются голосом.
C>> Я уж не говорю о том, что для той же iOS приходится использовать вообще отдельное уродство для сборки. CC>Собираю что iOS что все остальные таргеты в одном и том же XCode
А, понятно. Xcode съел моск. Я знаю человека, который в XCode умудрялся собирать для Андроида кросс-билд, но это уже из области глубоких извращений.
CC>>>Если не завязываться на нормальные IDE ты хотел сказать. C>>А где у MS нормальные IDE? CC>Вижуалка, старая есессна.
Нет там ничего особо нормального для современных IDE. Кстати, а как на ней для iOS писать?
Здравствуйте, Cyberax, Вы писали:
C>А, понятно. Xcode съел моск. Ты неотвратимо превращаешься в Артёмку — тот тоже фантазирует с разбросом в пару сотен миль от цели.
Сколько я уже раз тут писал что XCode говно и отстаёт даже от вижуалки 10летней давности, ан нет, чукча не читатель.
C>Нет там ничего особо нормального для современных IDE. Кстати, а как на ней для iOS писать?
А зачем на ней под iOS писать? Я на ней под винду пишу.
Гвозди забиваю молотком, шурупы закручиваю отвёрткой, сверлю сверлом, пилю пилой и в целом использую инструмент наиболее подходящий под задачу.
Здравствуйте, CreatorCray, Вы писали:
C>>А, понятно. Xcode съел моск. CC> Ты неотвратимо превращаешься в Артёмку — тот тоже фантазирует с разбросом в пару сотню миль от цели. CC>Сколько я уже раз тут писал что XCode говно и отстаёт даже от вижуалки 10летней давности, ан нет, чукча не читатель.
Ну так сам противоречишь себе. MSVS не работает на macOS и непригодна для iOS-проектов. Т.е. она невозможна в качестве Ein IDE. А в XCode нельзя писать код для Андроида.
Здравствуйте, Cyberax, Вы писали:
C>Так что нужно мимнимум два окружения.
Таки да.
Под ведро пишут на жабе, под яблоко на свифте.
Это ДВА проекта а не один.
Здравствуйте, varenikAA, Вы писали:
AA>Здравствуйте, Zhendos, Вы писали:
Z>>ним пишут на C++, но ведь на популярность и востебованность C# это особо не влияет. AA>на плюсах писать без подготовки невозможно, на расте если есть опыт в бейсике хотя бы разобраться в разы проще.
В "разы проще" на расте только есть опыт С++. Потому что самые засадные концепции раст — ссылки и время жизни объектов — в С++ точно такие же. И там, где обычный программист ругается "ну чего ж еще этому долбанному компилятору от меня надо?!!", только программист на С++ может сказать "о, ссылочка-то тут подохла бы — спасибо компайлер что заранее предупредил!"
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, CreatorCray, Вы писали:
C>>Так что нужно мимнимум два окружения. CC>Таки да. CC>Под ведро пишут на жабе, под яблоко на свифте. CC>Это ДВА проекта а не один.
Странно. Мы пишем под огрызокОС и Android на C++.
Здравствуйте, Basil2, Вы писали:
B>В "разы проще" на расте только есть опыт С++. Потому что самые засадные концепции раст — ссылки и время жизни объектов — в С++ точно такие же. И там, где обычный программист ругается "ну чего ж еще этому долбанному компилятору от меня надо?!!", только программист на С++ может сказать "о, ссылочка-то тут подохла бы — спасибо компайлер что заранее предупредил!"
Я наверно должен был уточнить, что я имел ввиду именно пользовательское ПО, если не кидаться сразу писать низкоуровневые библиотеки.
А какой-нибудь ui. web или desktop.
Тот же ui webasm через webgl первая загрузка проходит мгновенно в отличии от C#.
а основы раста и системы сборки изучаются в течении пары часов.
Я пробовал изучать плюсы но дальше си не продвинулся. Уж больно много правил в синтаксисе, я уж не говорю про настройку библиотек и различных флагов компиляции.
Т.е. производительность плюсов в расте можно получить за меньшие деньги. намного меньшие. А ведь это и есть цель бизнеса: удешевить стоимость товара.
Покупатель всегда ищет подешевле. В этом проблема рыночного хозяйства.
Здравствуйте, CreatorCray, Вы писали:
CC>Начнём с простого вопроса: зачем?
Начнём с простого вопроса: зачем пользоваться убогими солюшинами, когда даже студия поддерживает CMake?
S>>Вот. Только IDE разные. У нас разработчики пользуются всеми основными: студией, Vim, CLion, QCreator, на всех трех платформах. И 5-6 разными компиляторами. CC>Бардак!
Это гибкость обусловенная необходимостью работы со множеством разных платформ.
Здравствуйте, CreatorCray, Вы писали:
CC>Потому что KISS. Если нет в том реальной необходимости — нехрен париться.
Реальная необходимость возникает сразу за порогом уютного мира Windows-only разработки.
CC>Что это за требования к продукту которые хотят чтоб его код можно было писать на зоопарке платформ и тулов?
Кстати, этот вопрос прекрасная иллюстрация твоего опыта. Про наш проект я недавно подробно писал.
CC>Сколько я раз видел случаев когда позволяли писать в чём хочется столько раз что проект что код превращался в говно.
Анекдотные доказательства...
CC>Так что тут категорическое нет и диктатура с расстрелами. Есть единый dev environment, все пишут в нём.
Когда IDE становится частью требований для разработки это уже серьезный звоночек, что что-то тут неправильно.
CC>Если не завязываться на нормальные IDE ты хотел сказать.
Нет, это ты говоришь и пытаешься приписать свои слова мне. Никто не против студии, я ее переодичеки использую, но, к сожалени, студия не покрывает все случаи. Поэтому практически любой сложный проект не привязан к студии.
CC>Не, ну можно врукопашную всё фигачить, и считать что этот аскетизм — норма.
Ложная дилемма. Разговор не про "не использование" чего-то, а про возможность использования любых удобных и необхимых средств по необходимости.
Здравствуйте, CreatorCray, Вы писали:
CC>Гвозди забиваю молотком, шурупы закручиваю отвёрткой, сверлю сверлом, пилю пилой и в целом использую инструмент наиболее подходящий под задачу.
Не-не-не, ты тут рядом говорил
Здравствуйте, Skorodum, Вы писали:
S>Реальная необходимость возникает сразу за порогом уютного мира Windows-only разработки.
Вот как только она появится, так и будут рассматриваться варианты. Возможно их будет и десяток. Но останется один.
Здравствуйте, pagid, Вы писали:
P>Вот как только она появится, так и будут рассматриваться варианты.
"Как только"... Если вы предполагаете, что такой необходимости нет, то вы сильно ошибаетесь.
Вы (ты и креатор) пытаетесь свой ограниченный use case растянуть на всех, но он в принципе не работает во многих ситуациях. С другой стороны более общее решение будет работать и для вас. Собственно поэтому CMake и поддерживается в студии.
P>Возможно их будет и десяток. Но останется один.
Ну т.е. такой вопрос перед вами пока не встовал и вы его не решали.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Cyberax, Вы писали:
C>>Так что нужно мимнимум два окружения. CC>Таки да. CC>Под ведро пишут на жабе, под яблоко на свифте. CC>Это ДВА проекта а не один.
И у вас две реализации вместо одной?
Здравствуйте, kaa.python, Вы писали:
AA>>Правильный софт не нужно устанавливать. Максимум должно быть ридми с описание что должно быть еще доступно на системе.
AA>>https://docs.microsoft.com/en-us/troubleshoot/visualstudio/general/deploy-aspnet-app-xcopy-command
KP>Это типичный бред который может придти только в больной мозг виндузятников. Ну да, ведь это невероятно увлекательно помнить что и куда ты распаковал что бы потом не забыть это нечто обновлять, а уж коли захочешь удалить то лизаить по машине и смореть что там и где валяется
вот и напиши еще один менеджер обновлений опенсорсный разумеется. чтоб люди могли выбирать же. snap не считается — у него два фатальных недостатка. да и он уже устарел
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, kaa.python, Вы писали:
KP>>Это типичный бред который может придти только в больной мозг виндузятников. Ну да, ведь это невероятно увлекательно помнить что и куда ты распаковал что бы потом не забыть это нечто обновлять, а уж коли захочешь удалить то лизаить по машине и смореть что там и где валяется
CC>Типичный мирок линуксоида: софт валяется в 100500 каталогах разной глубины вложенности.
это только система. приложения в отдельных папках или даже на отдельных разделах.
в винде не лучше. 64х битныая система лежит в system32, а 32х битная — в syswow64
Здравствуйте, VladCore, Вы писали:
VC>вот и напиши еще один менеджер обновлений опенсорсный разумеется. чтоб люди могли выбирать же. snap не считается — у него два фатальных недостатка. да и он уже устарел
Я apt люблю, особенно если aptitude поверх накатить
Здравствуйте, kaa.python, Вы писали:
VC>>вот и напиши еще один менеджер обновлений опенсорсный разумеется. чтоб люди могли выбирать же. snap не считается — у него два фатальных недостатка. да и он уже устарел
KP>Я apt люблю, особенно если aptitude поверх накатить
причем тут ты. софтпосатели не любят apt. в лучшем случае ubuntu lts и дебиан 9 & 10 поддерживают, а sid & bullseye — нет. потому я снап не зря акцентировал. если ты в снап упаковал в пакет, то будет везде работать. с apt так не можуть
Здравствуйте, Skorodum, Вы писали:
CC>>Гвозди забиваю молотком, шурупы закручиваю отвёрткой, сверлю сверлом, пилю пилой и в целом использую инструмент наиболее подходящий под задачу. S>Не-не-не, ты тут рядом говорил
Здравствуйте, Skorodum, Вы писали:
CC>>Потому что KISS. Если нет в том реальной необходимости — нехрен париться. S>Реальная необходимость возникает сразу за порогом уютного мира Windows-only разработки.
Я щас живу в "уютном мире" mac/iOS/watchOS/etc разработки, если ты вдруг пропустил.
CC>>Что это за требования к продукту которые хотят чтоб его код можно было писать на зоопарке платформ и тулов? S>Кстати, этот вопрос прекрасная иллюстрация твоего опыта.
На вопрос то ответь. Финальный ваш продукт это железка с API. В каком месте там у вас необходимость писать код для fw этой железки на зоопарке платформ и тулов?
S> Про наш проект я недавно подробно писал.
Я понимаю конечно что культура стартапов такая что хреначьте как угодно, из любого дендрофекального материала с изолентой, но надо выкатить очень быстро иначе не доживём до зимы.
CC>>Так что тут категорическое нет и диктатура с расстрелами. Есть единый dev environment, все пишут в нём. S>Когда IDE становится частью требований для разработки это уже серьезный звоночек, что что-то тут неправильно.
Требование простое: есть стандарты кода и ему надо следовать.
S>к сожалени, студия не покрывает все случаи.
И какие случаи написания кода она не покрывает?
S>Разговор не про "не использование" чего-то, а про возможность использования любых удобных и необхимых средств по необходимости.
С этим как раз никто не спорит.
Здравствуйте, Skorodum, Вы писали:
CC>>Начнём с простого вопроса: зачем? S>Начнём с простого вопроса: зачем пользоваться убогими солюшинами, когда даже студия поддерживает CMake?
Зачем использовать CMake если работает искаропки?
S>>>Вот. Только IDE разные. У нас разработчики пользуются всеми основными: студией, Vim, CLion, QCreator, на всех трех платформах. И 5-6 разными компиляторами. CC>>Бардак! S>Это гибкость обусловенная необходимостью работы со множеством разных платформ.
Это vim то гибкость?
Ваш продукт — радар, АКА железяка, про какие платформы в процессе разработки идёт речь? Дрова написать — всё равно разные проекты нужны, потому как драйвер под винду и драйвер под мак будут существенно разные внутри. Ну если только у вас львиная доля работы не вынесена в софт в soft-modem стиле, что честно говоря фу.
S>на всех трех платформах.
Это как? FW железки у вас под винду или мак написан?
Здравствуйте, VladCore, Вы писали:
VC>в винде не лучше. 64х битныая система лежит в system32,
Там не "система" лежит а public API. И лежит оно там потому что надо было обеспечить backward compatibility для долбоклюев, которые захардкодили пути с своих поделиях. Когда с 16 на 32 переходили было System и System32.
VC>а 32х битная — в syswow64
Неправильно, syswow64. Потому как это подсистема эмуляции Windows 32 on Windows 64.
Здравствуйте, CreatorCray, Вы писали:
C>>Странно. Мы пишем под огрызокОС и Android на C++. CC>Что именно пишете?
Excel, который может работать с любыми объёмами данных.
Здравствуйте, CreatorCray, Вы писали:
CC>IDE внутри проекта должна быть одна, да. Равно как и оформление кода и прочие мелочи жизни. CC>А не зоопарк в стиле "каждый дрочит как хочет".
Как раз CMake позволяет избежать зоопарка. Все изменения только в CMake, а уж какую кто IDE/редактор выберет — ну так это просто вкусовщина же.
Здравствуйте, VladCore, Вы писали:
VC>причем тут ты. софтпосатели не любят apt. в лучшем случае ubuntu lts и дебиан 9 & 10 поддерживают, а sid & bullseye — нет. потому я снап не зря акцентировал. если ты в снап упаковал в пакет, то будет везде работать. с apt так не можуть
Ну я же не растоман, у которого первая инстинктивная реакция на любое ПО это переписать на Расте
Здравствуйте, Cyberax, Вы писали:
C>>>Странно. Мы пишем под огрызокОС и Android на C++. CC>>Что именно пишете? C>Excel, который может работать с любыми объёмами данных.
На телефоне? С любыми объёмами данных? Странный выбор платформы.
Здравствуйте, CreatorCray, Вы писали:
CC>>>Начнём с простого вопроса: зачем? S>>Начнём с простого вопроса: зачем пользоваться убогими солюшинами, когда даже студия поддерживает CMake? CC>Зачем использовать CMake если работает искаропки?
Conan для зависимостей, запускалка тестов, генерация кода (protobuf),...
S>>Это гибкость обусловенная необходимостью работы со множеством разных платформ. CC>Это vim то гибкость?
Ага.
Здравствуйте, CreatorCray, Вы писали:
CC>>>Что именно пишете? C>>Excel, который может работать с любыми объёмами данных. CC>На телефоне? С любыми объёмами данных? Странный выбор платформы.
Не телефоне в том числе. С любыми разумными — до десятков гигабайт (можно и больше, но вроде никому не нужно пока). Вычисления прозрачно мигрируют между локальными на телефоне/браузере и удалёнными в облаке.
Backend написан на С++ и работает на всём: iOS, Android, WebAssembly, и нативный код на Линуксе. Из всего это зоопарка, кстати, iOS вызывает больше всего геморроя. Так как тамошние уродцы-разработчики ОС плевать хотели на пользователей.
Мы используем все возможные IDE: emacs, vim, MSVS, CLion. И никого это не парит.
Здравствуйте, CreatorCray, Вы писали:
N>>Чтобы не делать несколько конфигураций. CC>Какие конфигурации тут имеются в виду?
По целевой сборке: устройство, ОС, компилятор и т.д. Даже для студий разных версий надо держать дублирующие файлы проектов.
N>> Кажется, что затачиваться под одну платформу чуть ли не сложнее, чем под несколько. CC>Отнюдь.
Мне нет. С содроганием вспоминаю те времена, когда приходилось работать со студией: ставили библиотеки все разрабы с одинаковыми путями, вручную прописывали какие-то пути, где-то вручную (потом автоматизировали) правили файлы проектов. Типа сделали мастер студийными средствами, а на новой студии он уже не работает как надо. Гемор.
Здравствуйте, kaa.python, Вы писали:
VC>>причем тут ты. софтпосатели не любят apt. в лучшем случае ubuntu lts и дебиан 9 & 10 поддерживают, а sid & bullseye — нет. потому я снап не зря акцентировал. если ты в снап упаковал в пакет, то будет везде работать. с apt так не можуть
KP>Ну я же не растоман, у которого первая инстинктивная реакция на любое ПО это переписать на Расте
Здравствуйте, Nuzhny, Вы писали:
N>Даже для студий разных версий надо держать дублирующие файлы проектов.
Зачем держать студии разных версий для одного проекта?
N>Мне нет. С содроганием вспоминаю те времена, когда приходилось работать со студией: ставили библиотеки все разрабы с одинаковыми путями, вручную прописывали какие-то пути, где-то вручную (потом автоматизировали) правили файлы проектов.
Ну дык выж её просто тупо готовить не умели
Здравствуйте, CreatorCray, Вы писали:
N>>Даже для студий разных версий надо держать дублирующие файлы проектов. CC>Зачем держать студии разных версий для одного проекта?
Ну, у тебя идеальный мир, получается. А в моём есть библиотека и есть пользователи. Всех не загонишь в одно IDE одной версии. Я уже не очень хорошо помню то время, но, кажется, новые студии в один прекрасный момент перестали поддерживать WinXP. И даже для сборки под ОС разных версий одного производителя и ОС, и компилятора приходилось собирать зоопарк средств разработки.
CC>Ну дык выж её просто тупо готовить не умели
Может быть. Но факт был фактом — мастер для создания проектов в одной версии студии не работал в другой версии. Поэтому приходилось писать скрипты для генерации проектов самому.
Здравствуйте, Nuzhny, Вы писали:
N>Ну, у тебя идеальный мир, получается. А в моём есть библиотека и есть пользователи.
Т.е. тебе надо поддерживать легаси.
N> Всех не загонишь в одно IDE одной версии.
Ты б уточнял кого ты тут понимаешь под "всех"
N>Поэтому приходилось писать скрипты для генерации проектов самому.
Там в общем то и генерить особо нечего — XML старых студий был простой и понятный.
Здравствуйте, CreatorCray, Вы писали:
CC>У нас нет ничего под ведроид, очевидно.
Кому очевидно? У кого "у нас"? Что-то ты в показаниях запутался. Выше ты пишешь:
Здравствуйте, CreatorCray, Вы писали:
CC>IDE внутри проекта должна быть одна, да.
Кому должна? Креатору?
CC>Равно как и оформление кода и прочие мелочи жизни.
Ты мешаешь в кучу принципиальные вещи и личную вкусовщину. Редактор и отладчик отдельного разработчика других никак не касаются, в отличии от форматирования, политики коммитов и т.п.
CC>А не зоопарк в стиле "каждый дрочит как хочет".
Фу таким быть.
Здравствуйте, CreatorCray, Вы писали:
N>>Ну, у тебя идеальный мир, получается. А в моём есть библиотека и есть пользователи. CC>Т.е. тебе надо поддерживать легаси.
Надо было когда-то. А потом ещё под Линукс для новых клиентов собирать.
N>> Всех не загонишь в одно IDE одной версии. CC>Ты б уточнял кого ты тут понимаешь под "всех"
Всех пользователей программного кода. Он используется так, как им удобно.
N>>Поэтому приходилось писать скрипты для генерации проектов самому. CC>Там в общем то и генерить особо нечего — XML старых студий был простой и понятный.
Все равно это был гемор. CMake решил множество проблем.
Здравствуйте, CreatorCray, Вы писали:
VC>>в винде не лучше. 64х битныая система лежит в system32, CC>Там не "система" лежит а public API. И лежит оно там потому что надо было обеспечить backward compatibility для долбоклюев, которые захардкодили пути с своих поделиях. Когда с 16 на 32 переходили было System и System32.
VC>>а 32х битная — в syswow64 CC>Неправильно, syswow64. Потому как это подсистема эмуляции Windows 32 on Windows 64.
CC>Ты б хоть с базовыми вещами ознакомился сначала
ну вот и начинай разбираться. это же ты про 31:9 про мониторы жёг недавно?
Здравствуйте, CreatorCray, Вы писали:
CC>Я щас живу в "уютном мире" mac/iOS/watchOS/etc разработки, если ты вдруг пропустил.
Манька-величка в гости пришла? Корона голову еще не жмет? Ты что ли воображаешь, что за тобой тут очень пристально следят?
Давай ссылку на пост про работу, профиль на линкедине, а не выпендривайся.
CC>Финальный ваш продукт это железка с API. В каком месте там у вас необходимость писать код для fw этой железки на зоопарке платформ и тулов?
Ну когда попробуешь сделать и продать "железку с API" тогда поймешь
CC>Я понимаю конечно что культура стартапов такая что хреначьте как угодно, из любого дендрофекального материала с изолентой, но надо выкатить очень быстро иначе не доживём до зимы.
Ой сколько гонора...
CC>Требование простое: есть стандарты кода и ему надо следовать.
Вот. Единое кроссплатформенное средство сборки это должно быть стандартом, а IDE — личное предпочтение.
CC>И какие случаи написания кода она не покрывает?
Кодогенирация, использование разных компиляторов, создание пакетов, и т.п. В студии либо очень криво, либо без костылей в виде скриптов не обойтись.
S>>Разговор не про "не использование" чего-то, а про возможность использования любых удобных и необхимых средств по необходимости. CC>С этим как раз никто не спорит.
Так добавь к этому что один и тот же код должен компилироваться и на 8051, и под ARM, и под x86, x64, и под линух и под винду и под еще пару платформ, добавь кодогенерацию, зависимости и т.п. и попробуй сделать это на солюшенах.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Skorodum, Вы писали:
CC>>>Начнём с простого вопроса: зачем? S>>Начнём с простого вопроса: зачем пользоваться убогими солюшинами, когда даже студия поддерживает CMake? CC>Зачем использовать CMake если работает искаропки?
Зачем использовать солюшены, если CMake работает "искаропки"?
S>>>>Вот. Только IDE разные. У нас разработчики пользуются всеми основными: студией, Vim, CLion, QCreator, на всех трех платформах. И 5-6 разными компиляторами. CC>>>Бардак! S>>Это гибкость обусловенная необходимостью работы со множеством разных платформ. CC>Это vim то гибкость?
Ты хочешь свести разговор к священной войне против вима? Ну удачи По существу-то тут тебе возразить нечего.
CC>Ваш продукт — радар, АКА железяка, про какие платформы в процессе разработки идёт речь?
Вроде уже раза 3 писал, разработка идет на всех трёх основных платформах.
CC>Дрова написать — всё равно разные проекты нужны, потому как драйвер под винду и драйвер под мак будут существенно разные внутри.
Представь, не всем железякам нужны "дрова" со стороны ОС...
CC>Ну если только у вас львиная доля работы не вынесена в софт в soft-modem стиле, что честно говоря фу.
Куда она может быть вынесена, если наш сенсор должен пробудить ноут то сна...
CC>Это как? FW железки у вас под винду или мак написан?
FW железки написан под железку и от ОС на хосте напрямую не зависит. И, представь себе, специфичного для ОС драйвера там нет.
Здравствуйте, Skorodum, Вы писали:
CC>>У нас нет ничего под ведроид, очевидно. S>Кому очевидно?
Всем, кроме тебя, очевидно.
S> У кого "у нас"?
В яблоке, очевидно.
S> Что-то ты в показаниях запутался.
Да просто ты читать не умеешь
Здравствуйте, Skorodum, Вы писали:
CC>>Я щас живу в "уютном мире" mac/iOS/watchOS/etc разработки, если ты вдруг пропустил. S>Манька-величка в гости пришла? Корона голову еще не жмет?
Ай дитятко...
S> Ты что ли воображаешь, что за тобой тут очень пристально следят?
Да Артёика забыть не даёт никак
S>Давай ссылку на пост про работу, профиль на линкедине, а не выпендривайся.
Пешком постоишь.
S>Ой сколько гонора...
Это банальный опыт работы в таки выжившем стартапе.
CC>>И какие случаи написания кода она не покрывает? S>Кодогенирация
Наличествует.
S> использование разных компиляторов
Наличествует. Лично юзал от ICC до GCC (BSD kernel)
S> создание пакетов
Каких?
S>Так добавь к этому что один и тот же код должен компилироваться и на 8051, и под ARM, и под x86, x64, и под линух и под винду и под еще пару платформ, добавь кодогенерацию, зависимости и т.п. и попробуй сделать это на солюшенах.
Таки делал. Был у меня проект в котором код собирался и для FW контроллера, для USB dongle в котором была антиукрадайка, и для UI на винде.
Одной кнопкой, в солюшене, да. На выходе был готовый инсталлер который тупо запускаешь и он всё сам делает. Линуха там не было только.
Здравствуйте, Skorodum, Вы писали:
S>Вроде уже раза 3 писал, разработка идет на всех трёх основных платформах. S>FW железки написан под железку и от ОС на хосте напрямую не зависит. И, представь себе, специфичного для ОС драйвера там нет.
Тогда непонятно что вообще надо кроме FW если со стороны хоста ничего не требуется? Т.е. платформа по сути одна, зачем три?
Здравствуйте, VladCore, Вы писали:
VC>>>а 32х битная — в syswow64 CC>>Неправильно, syswow64. Потому как это подсистема эмуляции Windows 32 on Windows 64. CC>>Ты б хоть с базовыми вещами ознакомился сначала VC>ну вот и начинай разбираться. это же ты про 31:9 про мониторы жёг недавно?
Ну т.е. у тебя аргументы кончились и ты включил режим хлебушка.
Здравствуйте, varenikAA, Вы писали:
AA>одна настройка окружения рабочего для проекта отнимет минимум полдня
Если сидеть в консолечке, и забить на отладчик, то минут десять с нуля на набор нескольких команд на установку всего-всего, ну и на создание шаблона проекта.
Здравствуйте, CreatorCray, Вы писали:
VC>>>>а 32х битная — в syswow64 CC>>>Неправильно, syswow64. Потому как это подсистема эмуляции Windows 32 on Windows 64. CC>>>Ты б хоть с базовыми вещами ознакомился сначала VC>>ну вот и начинай разбираться. это же ты про 31:9 про мониторы жёг недавно?
CC>Ну т.е. у тебя аргументы кончились и ты включил режим хлебушка.
т.е. тебе должны аргументы тут предоставлять? два раза? на что?
Здравствуйте, VladCore, Вы писали:
CC>>>>Неправильно, syswow64. Потому как это подсистема эмуляции Windows 32 on Windows 64. CC>>>>Ты б хоть с базовыми вещами ознакомился сначала VC>>>ну вот и начинай разбираться. это же ты про 31:9 про мониторы жёг недавно? CC>>Ну т.е. у тебя аргументы кончились и ты включил режим хлебушка. VC>т.е. тебе должны аргументы тут предоставлять? два раза? на что?
Ладно аргументы, но ты ж вообще тут несвязуху написал
Ты хотел доколупаться на WoW64, тебе объяснили почему там 64 написано, в ответ ты понёс какую то чушь про мониторы
И да, что за моники такие с 31:9?
21:9 существуют, 32:9 тоже.
А 31:9 это прямо как в шутке "где очепятка":
Здравствуйте, CreatorCray, Вы писали:
CC>>>>>Неправильно, syswow64. Потому как это подсистема эмуляции Windows 32 on Windows 64. CC>>>>>Ты б хоть с базовыми вещами ознакомился сначала VC>>>>ну вот и начинай разбираться. это же ты про 31:9 про мониторы жёг недавно? CC>>>Ну т.е. у тебя аргументы кончились и ты включил режим хлебушка. VC>>т.е. тебе должны аргументы тут предоставлять? два раза? на что? CC>Ладно аргументы, но ты ж вообще тут несвязуху написал CC>Ты хотел доколупаться на WoW64, тебе объяснили почему там 64 написано, в ответ ты понёс какую то чушь про мониторы
я теперь доколупался до папок в windows? где? ты ж написал выше что хочешь аргументы? ты запутался опять)
CC>И да, что за моники такие с 31:9? CC>21:9 существуют, 32:9 тоже. CC>А 31:9 это прямо как в шутке "где очепятка": CC>
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, varenikAA, Вы писали:
AA>>одна настройка окружения рабочего для проекта отнимет минимум полдня
TB>Если сидеть в консолечке, и забить на отладчик, то минут десять с нуля на набор нескольких команд на установку всего-всего, ну и на создание шаблона проекта.
Дело не в этом. взять тот же dotnet или скала или нодЖС (все более менее современное).
самое страшное что случится это нужно восстановить зависимости.
По плюсах опыт маленький. делали плагин в визуал студии.
на двух пк. то что работало на одном требовало особых настроек на другом пк.
т.е. реально отличались настройки. объяснить не могу, т.к. я не спец в плюсах.
но вот поверхностное знакомсто с растом не вызывает непоняток. или взять чуть более сложный яп типа ди.
все как в жава. хотя яп основан на компиляции из исходников.
вообщем, думаю найти спеца по плюсам с годами будет все сложней.
Здравствуйте, VladCore, Вы писали:
VC>я теперь доколупался до папок в windows? где? ты ж написал выше что хочешь аргументы? ты запутался опять)
Да вот тут
Здравствуйте, CreatorCray, Вы писали:
CC>Тогда непонятно что вообще надо кроме FW если со стороны хоста ничего не требуется? Т.е. платформа по сути одна, зачем три?
1. Потому что это всего лишь один из вариантов.
2. На хосте алгоритмы легче отрабатывать.
Здравствуйте, CreatorCray, Вы писали:
S>>Кому очевидно? CC>Всем, кроме тебя, очевидно.
Отучаемся говорить за всех. Отучаемся говорить за всех. Отучаемся говорить за всех.
S>> У кого "у нас"? CC>В яблоке, очевидно.
Если тебе так очень хочется, чтобы это было очевидно, то добавь это в подпись.
S>> Что-то ты в показаниях запутался. CC>Да просто ты читать не умеешь
Не перекладывай с больной головы на здоровую.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Skorodum, Вы писали:
CC>>>Я щас живу в "уютном мире" mac/iOS/watchOS/etc разработки, если ты вдруг пропустил. S>>Манька-величка в гости пришла? Корона голову еще не жмет? CC>Ай дитятко...
Так ты разговаривай как взрослый, если хочешь чтобы тебя серьезно воспринимали
S>> Ты что ли воображаешь, что за тобой тут очень пристально следят? CC>Да Артёика забыть не даёт никак
Не стоит ваши отношения экстраполировать на других.
S>>Давай ссылку на пост про работу, профиль на линкедине, а не выпендривайся. CC>Пешком постоишь.
Токсичность у тебя зашкаливает
S>>Ой сколько гонора... CC>Это банальный опыт работы в таки выжившем стартапе.
И ты его экстраполируешь на другую компанию в другой стране? Не очень умно.
CC>>>И какие случаи написания кода она не покрывает? S>>Кодогенирация CC>Наличествует.
Вызывал-то как?
S>> использование разных компиляторов CC>Наличествует. Лично юзал от ICC до GCC (BSD kernel)
И как пути к компиляторам прописываются?
S>> создание пакетов CC>Каких?
Да хоть какой-нибудь MSI и любой линуховый и dmg.
S>>Так добавь к этому что один и тот же код должен компилироваться и на 8051, и под ARM, и под x86, x64, и под линух и под винду и под еще пару платформ, добавь кодогенерацию, зависимости и т.п. и попробуй сделать это на солюшенах.
CC>Таки делал. Был у меня проект в котором код собирался и для FW контроллера, для USB dongle в котором была антиукрадайка, и для UI на винде.
Это 1/10 от перечисленных требований.
CC>Одной кнопкой, в солюшене, да. На выходе был готовый инсталлер который тупо запускаешь и он всё сам делает. Линуха там не было только.
А теперь добавь к этому переносимость между разработчиками на разных ОС.
Здравствуйте, Skorodum, Вы писали:
S>>>Кому очевидно? CC>>Всем, кроме тебя, очевидно. S>Отучаемся говорить за всех. Отучаемся говорить за всех. Отучаемся говорить за всех.
Отучайся.
S>>> Что-то ты в показаниях запутался. CC>>Да просто ты читать не умеешь S>Не перекладывай с больной головы на здоровую.
Отмазки, отмазки
Здравствуйте, Skorodum, Вы писали:
S>Так ты разговаривай как взрослый, если хочешь чтобы тебя серьезно воспринимали
Ты правда думаешь что мне интересны твои претензии?
S>Токсичность у тебя зашкаливает
Грусти
CC>>Это банальный опыт работы в таки выжившем стартапе. S>И ты его экстраполируешь на другую компанию в другой стране? Не очень умно.
Это как то делает твой стартап особенным?
S>Вызывал-то как?
Хоткеями.
S>>> использование разных компиляторов CC>>Наличествует. Лично юзал от ICC до GCC (BSD kernel) S>И как пути к компиляторам прописываются?
ICC сам встраивается, GCC я тупо вынес на buildserver ибо локально строить там было очень долго.
CC>>Каких? S>Да хоть какой-нибудь MSI и любой линуховый и dmg.
MSI делал через WIX, говно то ещё. Маковый DMG это просто disk image, на линуховые не смотрел вовсе.
CC>>Одной кнопкой, в солюшене, да. На выходе был готовый инсталлер который тупо запускаешь и он всё сам делает. Линуха там не было только. S>А теперь добавь к этому переносимость между разработчиками на разных ОС.
Возвращаемся к изначальному вопросу: нафига? Платформы разные, собирать под них надо по разному. Нафига это всё пихать в один проект на всех и потом корячиться пытаясь это всё удержать от разваливания?
Давно уже было выяснено что это тупиковый путь как и любая кроссплатформа.
Здравствуйте, CreatorCray, Вы писали:
VC>>я теперь доколупался до папок в windows? где? ты ж написал выше что хочешь аргументы? ты запутался опять) CC>Да вот тут
VC>>в винде не лучше. 64х битныая система лежит в system32, а 32х битная — в syswow64
нет. это просто факт изложил. а доколупался, как выражаются у вас на раёне, я до тебя.
т.е. тебе должны аргументы тут предоставлять? два раза? на что?
поправь корону а то ты уже в "обосратушки" как выражаются у вас на раёне опустился выползай. мы смотрим 👁👁
VC>>история всё помнит. ты подыши там штоли CC>Пока история помнит только твои обосратушки. CC>Обтекай.
VC>>>в винде не лучше. 64х битныая система лежит в system32, а 32х битная — в syswow64
VC>нет. это просто факт изложил.
Понимание устройства винды у тебя весьма оригинальное.
VC>поправь корону
Твою корону кроме тебя никто больше не видит, так уж ты как нить сам её поправляй.
