Здравствуйте, lpd, Вы писали:
lpd>>>Ну вот джава как была в бэкенде, там и есть, без вариадиков и rai. S>>Ну, да потеснить С++ она не может. lpd>Ну вообще немало десктопных приложений c GUI написаны на джаве + Android, хотя это и два недоразумения. Но C++-то джаву/C# не потеснил никак за все годы.
Здравствуйте, scf, Вы писали:
scf>Как человек, которого когда-то уговорили уйти с плюсов на яву и который очень навряд ли вернется: scf>- библиотеки и управление зависимостями. Для C/С++ есть всё, но найти, подключить и начать использовать чужие библиотеки — нетривиально.
Во как, на джаве оказывается всё просто?
scf>- бедная стандартная библиотека. Хочется нормальную юникодную строку с поддержкой кодировок, регулярок и богатого набора операций.
Юникодная строка — есть. Поддержка кодировок — а зачем она именно в языке? Ругулярки — есть, операций полно
scf>Хочется качественные многопоточные коллекции.
Хочется — сделай. Мне вот — не хочется. Вот совсем не нужно мне это.
scf>Хочется нормальные функции для работы со временем с поддержкой часовых поясов. и т.д. и т.п.
Зачем это в языке? Мне, например, это никогда не нужно было
scf>- феерическая сложность языка и сложность написания качественного (устойчивого к утечкам памяти и exception-safe) кода
Сказки от неосиляторов
scf>- значительно меньшая терпимость программы к ошибкам программиста — где managed язык отделается exception-ом, программу на C++ лучше прибить. Это ограничивает применимость в серверных приложениях
Только некорректная программа на C++ просто не соберётся, а на каком-нибудь питоне через год выстрелит и всё повалит
scf>- типы ошибок, которых нет в managed языках: порча памяти, утечки памяти
Не используй сырую память. Я забыл, когда это делал в последний раз. Даже под контроллеры это очень редко нужно
scf>- менее развитый тулинг для отладки, логгирования и обнаружения проблем
Я неделю вкуривал, как нормально логи на джаве настроить. Тулинг такой тулинг
Здравствуйте, Somescout, Вы писали:
J>>Мои 5 копеек про достоинства C++ J>>Возможность работать на системах с очень ограниченными ресурсами, вроде микроконтроллеров. Яву вы туда не запихнете.
S>Если не ошибаюсь, J2ME и NetCompact позволяли работать на очень слабых системах. А на совсем слабых возможности c++ точно не нужны (если каждая типизация шаблона будет создавать отдельный шмат кода — то в микросистемах оно только вредит).
Здравствуйте, ononim, Вы писали:
scf>>Хочется качественные многопоточные коллекции. O>Берем обычный качественный set, оборачиваем операции с ним mutex-ом и получаем качественный многопоточный set.
Нет, так ты получишь тормозное говно как в ранних Java.
M>Научи, как писать на джаве под STM
Вроде и коммерческие и платные java-фреймворки под stm в наличии. И .net там есть, я с малым на stm32f4 c экранчиком, что-то пилил очень давно, когда эта плата была типа крутой. stm-ки всё-таки довольно мощные процы, не микроконтроллеры.
Здравствуйте, hi_octane, Вы писали:
M>>Научи, как писать на джаве под STM _>Вроде и коммерческие и платные java-фреймворки под stm в наличии. И .net там есть, я с малым на stm32f4 c экранчиком, что-то пилил очень давно, когда эта плата была типа крутой. stm-ки всё-таки довольно мощные процы, не микроконтроллеры.
На самых жирных — оперативы целый метр.
Ну, вообще интересно даже глянуть, ссылок не помнишь?
Здравствуйте, andyp, Вы писали:
A>Неправильная прога. Правильная выводит ответ на вопрос о смысле жизни, вселенной и всего такого, а эта в два раза недотягивает.
Какая, интересно, редиска подняла холивар двухлетней давности. Совсем люди затосковали с этими карантинами
--
Не можешь достичь желаемого — пожелай достигнутого.
- Язык designed by committee. Одна история с > > vs >> в темплейтах чего стоит.
— Дико медленный компилятор из-за особенностей дизайна языка.
— Сообщения об ошибках часто неинформативные и труднопониманиемые
— Препроцессор делаающий принципиально невозможным создание универсальных средств рефакторинга и анализа кода, доступные для более простых языков. Неуниверсальные средства рефакторинга и анализа кода чудовищно сложно писать, требуют от их авторов уровня программирования "бог".
— Из-за вынужденной необходимй поддержки старого кода и C, нет понятие "deprecated language feature" — в итоге есть несколько способов сделать одно и то же, каждый из них по-своему плохой. Одних официальных смартпойнтеров понаделали столько, что хоть вешайся.
— Отсутствие или бедность хороших базовых библиотек. Например абстракции "строка", которая универсально принималась бы, просто нет — есть char *, wchar_t *, char [], std::string, std::wstring и это если не смотреть на boost. В итоге куча проблем с интеграцией сторонних библиотек между собой на ровном месте, т.к. базовые вещи каждый изобретает сам.
— отсутсвие стандарта на ABI
Здравствуйте, Ночной Смотрящий, Вы писали:
BFE>>C++ — язык сложный, не все могут его осилить. НС>Да да, любимый аргумент верующих в С++. Хорош тем, что им можно обосновать любое плюсовое уродство.
Здравствуйте, B0FEE664, Вы писали:
BFE>Ага. Все так говорят, кто осилить не смог.
Ну я осилил. Но потом вырос и мой максимализм сошел на нет, теперь хочется больше велью толкать. Особенно когда сначала написал экстремально умную модель данных на плюсовых шаблонах, а потом увидел глупую реализацию на java, которая на практике оказалась удобнее в использовании.
Здравствуйте, scf, Вы писали:
BFE>>Ага. Все так говорят, кто осилить не смог.
scf>Ну я осилил. Но потом вырос и мой максимализм сошел на нет, теперь хочется больше велью толкать. Особенно когда сначала написал экстремально умную модель данных на плюсовых шаблонах, а потом увидел глупую реализацию на java, которая на практике оказалась удобнее в использовании.
Модель данных — это абстрактное, самодостаточное, логическое определение объектов, операторов и прочих элементов, в совокупности составляющих абстрактную машину доступа к данным, с которой взаимодействует пользователь. Эти объекты позволяют моделировать структуру данных, а операторы — поведение данных.
Исходя из этого определения я не понимаю какое отношение могут иметь шаблоны предназначенные для создания объектов внутри программы к данным которые лежат вне программы. Это же разные сущности.
Здравствуйте, rg45, Вы писали:
R>ибо организовать RAII, равнозначный плюсовому, невозможно, пользуясь недодеструкторами этих языков.
Ну во-первых managed тут не помеха, и C++/CLI тому пример. А во-вторых это еще большой вопрос что лучше, неявные плюсовые деструкторы или явный и хорошо видимый шарповский using. Сделали, кстати, в шарпе юсинг в плюсовом стиле, ан на практике большинство в него потыкало и отказалось, ибо видимость скоупа оказалась важнее пары лишних фигурных скобок.
Здравствуйте, rg45, Вы писали:
R>Третья проблема, использую сишарпный аналог defere-а — using. Много ли найдется разработчиков C#, которые скажут сходу, какой из следующих вариантов является правильным
Второй. И тот, который не зная что там внутри скажет что первый — либо джун, либо профнепригоден.
R>И даже на этом веселуха еще не заканчивается — обязательно ведь найдется грамотей, который позовет Dispose
Ты предлагаешь такому дать в руки С++? Рили?
R>И подобные проблемы неминуемо возникают везде, где ресурс выделяется провайдером,
А точно возникают? У меня вот очередной проект сейчас — полтора года живет, пару десятков разработчиков разной квалификации. Знаешь сколько раз был забыл юсинг? Ни разу. Хотя утечки памяти были и не раз.
Здравствуйте, rg45, Вы писали:
R>2. Криворукий юзер может тупо забыть написать "using"
А еще криворукий программист может забыть в смартпоинтер завернуть указатель или еще чего. Вероятность чего выше, и что более разрушительно по последствиям?
И переносимость у него такая, что Си не не снилась.
