Что значит твой вопрос? Уточни, пожалуйста. Как раз "совместимость на уровне исходного кода", позволяет избежать "заниматься выпуском версий под каждую ось"!


Да, STL тоже стандартизирована. Моя фраза этому противоречит?


Почему ты сразу не сказал, что STL и RTL - проблемные компоненты стандартизованного C++ из-за того, что там нет поддержки многопоточности?
Скажи, а все ли ОСи, для которых существуют C/C++ компиляторы поддерживают эту самую многопоточность?
Вообще это вопрос квалификации. Человек не умеющий писать многопоточный безопасный (с точки зрения целостности внутренних данных) код с использованием таких компонент, как STL и/или RTL, вряд ли может быть программистом. Потоки, и механизмы поддержки многопоточных программ - уже очень давно, причем вне зависимости от платформы - базовая часть API.


Безопасность - вопрос культуры программирования, и опять же, квалификации. И на C#, и на Java тоже можно писать убогий код, а потом дебажиться сутками, пытаясь понять, почему "безопасная" программа падает в самых неожиданных местах.


Отсмеялся! ИМХО, это из-за недостаточного понимания "программистами" особенностей и возможностей языка, который они используют. Обычно, люди перешедшие с Паскаля или Бейсика, офигевают от возможностей C/C++, и начинают их использовать где нужно и не нужно, не удосужившись до конца разобраться в деталях работы того или иного механизма C/C++.


Помнится, когда появилась Java, многие издания кричали "Java - убийца C/C++, мощный, безопасный, переносимый"... И что? Многие промышленные проекты до сих пор на С++.
Client-side программирование... Хороший термин. Ты использовал .NET на клиентской части в _крупных_ проектах?

Так он вообще не обладает платформонезависимостью.
От этого еще никто не умирал. Помоему это гораздо лучше, чем псевдосовместимость жабы.
Да, это часть стандартной библиотеки.
В Boost есть.
А чего опровергать-то? Нейтив код пока никуда не ушел. С++ предсказывали смерть еще с выходом жабы, и ниче он пока жив И в память на жабе можно в прямую писать и еще много чего делать, если постараться На wasm.ru статья есть.

Те же яйца, только в профиль. "освой за 21 день С++" ничем не лучше книжки "самоучитель VC++ 2005".

Возьми лучше пару книг Б. Страуструпа, выборочно почитай Д. Кнута. Пользы будет больше.

Holmes А вы читали именно эту книгу? Книга действительно для начинающего весьма хороша. А после неё читать Страуструпа. Читается с куда большим понмианием, чем если начинать изучение с него.

чрез JNI?
Добавлено спустя 4 минуты, 47 секунд

Да только вот когда ты пользуешь чужие либы, то если они написаны на java/.net - это дает большей уверенности в их безопасности. Мало ли криворуких кодеров....

В 95-то... Ну-ну. Тогда бы и я посмеялся.

Я джавист

Ну например утечек памяти на Java точно не будет а это одно из самых распространненых косячеств

Holmes я заметил
Catar Через sun.misc.Unsafe, подробности тут http://wasm.ru/article.php?article=unsjav1
Баги в JDK и JRE разной вроде бы тоже еще не перевелись Нужно использовать либы из доверенных источников, аля Boost.
Не опытный значит из тебя джавист будет Как-то очень уважаемый мною человек, сказал, мол в Java тоже бывают утечки памяти, причем довольно часто и 5 основных разработчиков профайлеров на это кормяться. Не поверил, решил проверить - действительно бывают
Пара линков:
http://www.javaworld.com/javaworld/java ... tip79.html
http://www.adtmag.com/java/articleold.aspx?id=165

2force_sk:
Именно эту - нет, не читал, а читал несколько других книг с аналогичными названиями "изучи что-то_там самостоятельно за 21 день". Они хороши для ознакомления и написания простеньких задач в институт.

Да нет, не мало. Сомневаюсь, что сторонние "java/.net" библиотеки будут выше по качеству, чем C/C++ либы. Под "сторонними библиотеками" я _не_ имею в виду разные поделки бразильских студентов.


Рад за тебя. Думал, ты и на плюсах пишешь, раз с такой легкостью рассуждаешь о STL, RTL, проблемах Си и прочих API.


Кто гарантирует, что их не будет? В одном крупном проекте, где я работал, память с успехом утекала из "безопасного" C#.
Наличие человеческого фактора делает эту самую безопасность условной. Поэтому говорить "утечек памяти ... точно не будет" нужно всегда с оговорками.

Нее, иногда пишу на чистом С. GTK Плюсы были изучены в минимальном варианте так сказать, под nix я тогда еще я не программировал, а изучить MFC банально не успел, тк пришлось спешно изучать Java.

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

Мда. Каюсь о таких тонкостях не знал. Видимо из-за того, что отсутствие утечек в документухе по Java писалось чуть ли никак заповедь. Вообщем, доверяй, но проверяй. Thanks.

Разъясняю. GTK и QT к примеру позволяют обеспечивать оную. Но никто не гарантирует, что под конкретным ядром bla-bla-bla оно соберется. И Makeфайлы немного разные, для разных осей. Использование VM позволяет сбросить ответственность за корректную работу под иной осью с себя на производителя VM. В общем случае (при равном умении) добиться одного и тоже результата можно и так и так (и native код, что естественно, будет быстрее) - но это менее удобно.

если мне память не изменяет, в апплетах это запрещено, ну а application-code - можно тоже запретить

Как я уже постил, это человеческий фактор. Он может быть и негативным и позитивным...


Это немного из другой оперы. Не сильно владею деталями, но, ИМХО, думаю, что такое происходит из-за глобальной несогласованности разработчиков/патчеров/майнтайнеров *nix ОСей. Перевод этой проблемы в плоскость "Использование VM позволяет сбросить ответственность за корректную работу под иной осью с себя на производителя VM", не совсем корректен. Согласен, это разумный и обоснованный подход. Но он требует введения еще одного уровня абстракций, и в данном случае это не есть очень хорошо.

Так речь то о практике. В теории .net тоже кроссплатформеннный - но на практике этого сильно не наблюдается в идеале конечно хватило бы и совместимости на уровне source, но из-за

это труднодостижимо.

Знаешь, кастомеру не скажешь, мол программа работает некорректно, так как Sun ошиблась при реализации VM под вашу платформу Нужно будет выкручиваться, ибо проблема это в первую очередь твоя. С++ и совместимость на уровне исходного кода в данной ситуации дает большую свободу. Хочешь юзать GC? Пожалуйста, уже реализован, или же юзай shared_ptr или еще что. С++ - это не С, он более высокоуровневый и читабелен, содержит куда меньше пресловутых указателей (хотя к слову сказать ничего, ну ничего непонятного или опасного в них нет, нужно просто иногда не программить на автомате, а подумать, как же все-таки и где будет выделена память в конкретной ситуации, и что к чему нужно закастовать ) и т.д. и т.п.
Нет, не из-за этого, а из-за лицензии МС.

Вот поэтому я и считаю что надо учить ООП на C++, чтобы новичок сумел наступить на все возможные грабли и научился думать , а уже потом, если ему будет удобно или просто надо - писать на Java\C#, где можно - ну конечно думать надо везде, но там думать несколько меньше

эээ я немного не понял что именно ты отквотил и на что ответил

Дык я тоже о практике. Проблема описанная тобой сугубо практическая.


Вывод из опыта - у некоторых (я никого конкретно не имею в виду!) напрочь отсутствует часть мозга, которая понимает указатели. Досадно, что некоторые, из этих некоторых, пишут что-то на коммерческой основе.
Ты забыл про самое главное - подумать, где она будет освобождена!
Добавлено спустя 6 минут, 45 секунд

Несогласен! Начинать учить надо с Си, чтобы человек понял некоторые базовые вещи, например, указатели, и привык объявлять переменные не так, как захочет его левая нога, а по-человечески. А потом уж переходить к ООП и, в частности, к C++. Вообще Си, несмотря на много недостатков, дисциплинирует.


А вот с этим - согласен!

дык читай внимательнее - я же написал учить ООП надо с C++. То что ДО этого надо изучить структурное программирование я принимаю по дефолту
Добавлено спустя 1 минуту, 48 секунд
Кстати об удобстве - вот например вот это для меня выглядит ужасно... http://forums.overclockers.ru/viewtopic.php?t=154707

начинать учить надо с INTERCAL )))))))))))))))))
чтобы отсеять всех лишних людей....

Зато работает идеально(я говорю про приведённую ссылку). Тут же приведу живой пример на эту тему(этой прогой пользуется много народа):
#77
Программа открывает файл и с помощью другой консольной проги создаёт другой файл. Т.е. сама программа ничего не делает. Собственно вопрос: зачем тут применили дотнет? Да мне легче воспользоватся сразу консольной прогой(что я в общем-то и делаю) чем ждать 20 секунд запуска такого фронтэнда.

На ассемблере то можно написать тоже самое и чтобы идеально работало. Внимание вопрос: надо ли?
Можете пинать меня, но я считаю что для таких нужнд - gui - либо .net\java со своими фреймворками, либо высокоуровневые либы под C\C++\Дельфи\etc. А то и вовсе visual программирование - кнопочки в билдере мышой растаскивать (хотят тут все зависит от адекватности оного билдера).
Лезть в GDI или Xlib - кому надо тот полезет но это имхо не_есть_употребительный способ gui программирования. Чисто специфические нужды.
Примечание - я не за only программирование методом Button1Click() { } ; я за программирование наиболее удобным методом в каждой конкретной ситуации.


Не скажу за .net, но мой java минивебсервер (обрабатывает GET запросы) с подобным gui целиком грузился за 15 сек на P200.