Re[4]: Переход на Java
От: Аем Вопля  
Дата: 01.03.09 13:49
Оценка:
Согласен, C++ — говно-язык.
Re[5]: Переход на Java
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.03.09 13:54
Оценка: +1
Здравствуйте, Аем Вопля, Вы писали:

АВ>Согласен, C++ — говно-язык.


Речь была не о том, что С++ говно, а о том, что хорошая платформа с языком очень даже связана.
... << RSDN@Home 1.2.0 alpha 4 rev. 1137 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[4]: Переход на Java
От: Cyberax Марс  
Дата: 01.03.09 14:00
Оценка:
Здравствуйте, AndrewVK, Вы писали:

CC>>Вот мне всегда было непонятно, почему в плюс языка всегда пытаются отнести большую стандартную библиотеку?

AVK>Потому что хороший современный язык обязан быть спроектирован в том числе и с учетом простоты и удобства как создания фреймворков, так и их использования. А для С++ даже ABI все никак не устаканят.
Нестабильный ABI в С++ уже перешёл из состояния "бага" в состояние "фича".
Sapienti sat!
Re[5]: Переход на Java
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.03.09 14:09
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Нестабильный ABI в С++ уже перешёл из состояния "бага" в состояние "фича".


Не суть. Это просто пример.
... << RSDN@Home 1.2.0 alpha 4 rev. 1137 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[7]: Переход на Java
От: Пацак Россия  
Дата: 01.03.09 19:34
Оценка:
Здравствуйте, MasterZiv, Вы писали:

MZ>Чтобы в Java НЕ ЖДАЛИ появления RuntimeException, которое по сути своей

MZ>непредсказуемо появляется, -- это новость какая-то.

Пардон, то есть ты хочешь сказать, что RuntimeException в java ждут всегда? Вот это на самом деле новость-то.
Ку...
Re: Переход на Java
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.09 20:48
Оценка: +6
Здравствуйте, opener, Вы писали:

O>Насколько сложно перейти на Java после С++? Проще/сложнее сама жаба по сравнению с С++?


Зависит от головы. Кто-то знает десятки очень разных языков, а кто-то освоил один кое-как и на большее не способен.
Чем больше ты знаешь языков и чем более разнообразны языки которые ты изучил и умеешь применять, тем лучше для тебя и твоего работодателя. Причем совершенно все равно на каком языке ты будешь программировать в ближайшем будущем. Ты все равно будешь мыслить шире.

O>По моим нынешним представлениям вроде проще.


Трикритические размышления ничего не значат. Изучи, а потом рассуждай.

O>И какого тогда хрена у жаба-программистов зарплаты больше?


Хороший С++-программист имеет хорошую зарплату Хороший ява-программист имеет тоже хорошую зарплату. Плохая разплата определяется исключительно двумя факторами:
1. Бездарностью личности.
2. Спросом на программистов в конкретном месте в конкретное время.

Оба фактора при желании поддаются изменению .
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Переход на Java
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 01.03.09 20:57
Оценка:
Здравствуйте, Аем Вопля, Вы писали:

АВ>Я не прав? Если я не прав, зачем тогда ввели ключевое слово using в C#, а? Если и так все «автоматическое»?

using нужен чтобы освобождение ресурсов было детерминированным, в C++ вызов деструкторов детерминирован, а в .NET аналогичный функционал — финализаторы вызывается недетеримровано.

На using встречается не так часто, а основной ресурс, которым требуется управлять в unmanaged среде — память, не требует детерминированного освобождения.
Re[3]: Переход на Java
От: yumi  
Дата: 02.03.09 01:27
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Вот мне всегда было непонятно, почему в плюс языка всегда пытаются отнести большую стандартную библиотеку?

CC>Это конечно плюс, но не самого языка.

А сам язык без библиотек, это ничто, каким бы он ни был крутым, красивым, стройным (ни к одному из них я С++ не отношу ).
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[6]: Переход на Java
От: MasterZiv СССР  
Дата: 02.03.09 08:28
Оценка:
AndrewVK пишет:

> Речь была не о том, что С++ говно, а о том, что хорошая платформа с

> языком очень даже связана.

Кому на C++ нужен этот ABI ?

А С++, извините, был уже, когда вашей Java любимой и в зародыше
не было. И не было бы C++, не было бы и Java, потому как Java
прежде всего им и вдохновлена была.

С++ -- язык другой, и другого времени, того, когда на машине
было 640 килобайт памяти. Так что уж простите старику его
маленькие слабости.
Posted via RSDN NNTP Server 2.1 beta
Re[8]: Переход на Java
От: MasterZiv СССР  
Дата: 02.03.09 08:29
Оценка:
Пацак пишет:

> Пардон, то есть ты хочешь сказать, что RuntimeException в java ждут

> всегда? *Вот это* на самом деле новость-то.
Я имею в виду, что оно всегда может возникнуть. И если ты к нему не
готов, то это уже твоя проблемы.
Posted via RSDN NNTP Server 2.1 beta
Re[7]: Переход на Java
От: samius Россия http://sams-tricks.blogspot.com
Дата: 02.03.09 09:39
Оценка:
Здравствуйте, MasterZiv, Вы писали:

MZ>А С++, извините, был уже, когда вашей Java любимой и в зародыше

MZ>не было. И не было бы C++, не было бы и Java, потому как Java
MZ>прежде всего им и вдохновлена была.
Так можно и до ALGOL-а дойти по индукции, впрочем, возраст языка не относится напрямую к его достоинствам.

MZ>С++ -- язык другой, и другого времени, того, когда на машине

было 640 килобайт памяти.
В то время, да и сейчас, C преобладает над C++, особенно на девайсах с малой памятью.
Re[8]: Переход на Java
От: Ligen Украина http://zone-of-ambiguity.blogspot.com/
Дата: 02.03.09 09:52
Оценка: 1 (1)
D>Распространённое заблуждение. В деструкторе C++ можно разместить процедуры освобождения только для элементарных ресурсов. Прежде всего "чистых" объектов в памяти. Любой ресурс с нетривиальной логикой освобождения, например, распределённая транзакция, и облом-с. Бо из деструктора нельзя нормальным образом передать информацию о возникновении ошибочной ситуации в процессе этого самого освобождения.

Философия С++ заключается в том, чтобы избегать создания объектов с одной лишь нетривиальной логикой удаления. Можно допустить утверждение: у любой разработанной самостоятельной сущности должно быть предусмотрено одно аварийное удаление, корректно работающее и не кидающее исключений. Иначе сущность считается опасной и должна быть завернута в что-то безопасное. Можно делать сколько угодно дополнительных нетривиальных "удалений", никто же не запрещает:


class CSuperResource
{
public:
void SuperMegaSyncStop(ISuperStopHelper * p);
void SuperMegaAsyncStop(some_ref_ptr<IStopObserver> pObserver);
void StopAnyway(); 

~CSuperResource()
{
    StopAnyway(); // но должно быть одно аварийное, иначе  придется ~CSuperResource переносить в private
}

};


Наличие одних лишь "нетривиальных удалений" — не только моветон, но и признак серьезных архитектурных ошибок.
Вот вам простая философская аналогия из мира системного программирования: допустим, вы написали свой аналог TrueCrypt'a, утилиту, которой можно управлять виртуальными шифрованными дисками. Виртуальный диск — это же сложный ресурс? Представим теперь гипотетическую ситуацию, что какой нибудь пользователь сделает mount некоторого виртуального диска с помощью вашей программы, поработает с ним, а unmount сделать не сможет из-за ошибки "нет памяти". Что это значит? Значит программа написана крайне плохо — вы должны были предусмотреть выделение критических необходимых ресурсов при mount'е, а если их нет, отказывать в mount операции, а не в unmount.

D>Кстати, ifstream из Вашего примера, тоже образец нетривиального ресурса. Бо закрытие файла может вызывать ошибочные ситуации. И чтобы их увидеть, потребуется явный вызов rdbuf()->close()


Строго говоря, не может. Ошибка при закрытии хендла означает только одно — его уже закрыли до вас. А "его уже закрыли до вас" в переводе на язык С++, означает "Случилось UB, программа написана некорректно, лучшее что можно сделать, это упасть и собрать дамп".
Viva el Junta Militar! Viva el Presidente!
Re[7]: Переход на Java
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 02.03.09 13:40
Оценка:
Здравствуйте, MasterZiv, Вы писали:

MZ>Кому на C++ нужен этот ABI ?


Тем, кто пишет фреймворки.

MZ>А С++, извините, был уже, когда вашей Java любимой и в зародыше

MZ>не было.

Джава, она не моя и даже не любимая.

MZ> И не было бы C++, не было бы и Java


Это что то меняет?

MZ>С++ -- язык другой, и другого времени, того, когда на машине

MZ>было 640 килобайт памяти. Так что уж простите старику его
MZ>маленькие слабости.

Мы еще технические вопросы обсуждаем или тебе пофлеймить охота?
... << RSDN@Home 1.2.0 alpha 4 rev. 1137 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[8]: Переход на Java
От: MasterZiv СССР  
Дата: 02.03.09 15:27
Оценка:
AndrewVK пишет:

> Мы еще технические вопросы обсуждаем или тебе пофлеймить охота?


Не, не охота. Но не я начинал....
Posted via RSDN NNTP Server 2.1 beta
Re[9]: Переход на Java
От: Пацак Россия  
Дата: 02.03.09 18:50
Оценка:
Здравствуйте, MasterZiv, Вы писали:

>> Пардон, то есть ты хочешь сказать, что RuntimeException в java ждут

>> всегда?
MZ>Я имею в виду, что оно всегда может возникнуть. И если ты к нему не
MZ>готов, то это уже твоя проблемы.

Готов или не готов к нему ты — это вопрос отдельный и вообще говоря философский. А готовность к нему программы в терминах языка выражается в конструкции try ... catch. И практика показывает, что в >90% методов в java RuntimeException никак не ловят и не ждут. Ибо все заранее ожидаемые косяки явно задекларированы через checked-исключения, а отлавливать вариант "случилось ХЗ чего" особого смысла не имеет. Из этого правила лично мне известны только два исключения — вышеописанная обертка вокруг checked при переопределении метода (что само по себе чревато потенциальными граблями) и вывод матершины в лог.
Ку...
Re[9]: Переход на Java
От: drol  
Дата: 02.03.09 20:17
Оценка: -1 :)
Здравствуйте, Ligen, Вы писали:

L>Философия С++ заключается в том, чтобы избегать создания объектов с одной лишь нетривиальной логикой удаления. Можно допустить утверждение: у любой разработанной самостоятельной сущности должно быть предусмотрено одно аварийное удаление, корректно работающее и не кидающее исключений.


У Вас каша в голове. Речь не об объектах, а о ресурсах, работа с которыми завёрнута в объект класса построенного согласно RAII (точнее, RAII в понимании оппонента). И не об удалении, а об освобождении этих самых ресурсов, путём автоматического вызова деструктора для объекта-обёртки размещённого на стеке.
Корректность же освобождения ресурса, нетривиальности логики этого самого освобождения вообще ортогональна, и никаким образом с ней не связана.

Ещё раз повторяю пример: распределённая транзакция. Здесь, при освобождении, нам необходимо получать/освобождать другие новые ресурсы, и иметь возможность адекватно реагировать на ошибочные ситуации, которые могут возникнуть при этих операциях. На автоматических вызовах деструкторов стековых объектов сделать это нормальным образом невозможно.

L>Наличие одних лишь "нетривиальных удалений" — не только моветон, но и признак серьезных архитектурных ошибок.


См. выше. Вы путаете тёплое с мягким.

L>Вот вам простая философская аналогия из мира системного программирования: допустим, вы написали свой аналог TrueCrypt'a,


Какой TrueCrypt в час ночи ??? Обычному приложению все эти critical'ы нафиг не нужны. Кончилась память ? Ну так идите лесом, или в магазин за DIMM'ами...
*Вы бы ещё ПО для управления ядерным реактором приплели...

D>>Кстати, ifstream из Вашего примера, тоже образец нетривиального ресурса. Бо закрытие файла может вызывать ошибочные ситуации. И чтобы их увидеть, потребуется явный вызов rdbuf()->close()


L>Строго говоря, не может. Ошибка при закрытии хендла означает только одно — его уже закрыли до вас.


Неправда. О конкретных ошибках возможных в этих моментах стандарты ничего не говорят. Постулируется только сама возможность отказа, с возвратом соответствующего значения из close()/fclose()

Если на Вашей конкретной платформе наблюдается описанное Вами поведение, то это проблемы исключительно Вашей конкретной платформы. Стандарт же допускает гораздо больше вариантов реализации.

L>Случилось UB, программа написана некорректно, лучшее что можно сделать, это упасть и собрать дамп


И это тоже чушь. С точки зрения C++, никакого UB здесь быть не может. Бо стандарт допускает и отказы, и многократный вызов close()
Re[10]: Переход на Java
От: _________  
Дата: 02.03.09 20:49
Оценка: -1
D>Я так и знал, что по остальным вопросам возражений не будет

А не с чем спорить: вы не опровергаете то, о чем я писал.
Re[10]: Переход на Java
От: MasterZiv СССР  
Дата: 03.03.09 08:36
Оценка:
Пацак пишет:

> Готов или не готов к нему *ты* — это вопрос отдельный и вообще говоря

> философский. А готовность к нему *программы* в терминах языка выражается
> в конструкции try ... catch. И практика показывает, что в >90% методов в
> java RuntimeException никак не ловят и не ждут. Ибо все заранее
> ожидаемые косяки явно задекларированы через checked-исключения, а

java.lang
Class RuntimeException

java.lang.Object
extended by java.lang.Throwable
extended by java.lang.Exception
extended by java.lang.RuntimeException

Вы не ловите в ваших программах java.lang.Exception ?

> отлавливать вариант "случилось ХЗ чего" особого смысла не имеет. Из

> этого правила лично мне известны только два исключения — вышеописанная
> обертка вокруг checked при переопределении метода (что само по себе
> чревато потенциальными граблями) и вывод матершины в лог.

Любой APP -сервер, думаю, обязан оборачивать выполнения
всех запросов в try...catch. CORBA ORB например (штатный от SUN)
это делает. Думаю, это же делают всякие JBoss etc.
Posted via RSDN NNTP Server 2.1 beta
Re[11]: Переход на Java
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 03.03.09 11:44
Оценка:
Здравствуйте, MasterZiv, Вы писали:

MZ>java.lang

MZ>Class RuntimeException
MZ>java.lang.Object
MZ> extended by java.lang.Throwable
MZ> extended by java.lang.Exception
MZ> extended by java.lang.RuntimeException
MZ>Вы не ловите в ваших программах java.lang.Exception ?
Не туда копаете. Заложенная логика в отнесение исключения к проверяемым или непроверяемым исключениям никак не связана с приведенной вами иерархии наследования. К примеру, Exception является проверяемым, а вот RuntimeException — непроверяемым, несмотря на то, что является наследником Exception. С другой стороны, java.lang.Error, который также, как и java.lang.Exception, наследуется от java.lang.Throwable, не является проверяемым. Итого, с этой точки зрения никакой четкой логики нет. Здесь заложена логика на заложенной в данные исключения семантике, их 3 группы:Собственно, Пацак правильно пишет: паталогия всегда есть — но по заложенной логике нет никакого смысла обрабатывать непроверяемые исключения.
Re[12]: Переход на Java
От: drol  
Дата: 03.03.09 13:13
Оценка:
Здравствуйте, rsn81, Вы писали:

R>Наследники java.lang.RuntimeException — непроверяемые. Семантика: ошибки программы, которые не должны возникать при правильном кодировании — нет смысла их программно обрабатывать (!)


Неуверен, что все наследники RuntimeException подходят под Вашу классификацию. Вот SecurityException, например ?
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.