Re: Переход на Java
От: MasterZiv СССР  
Дата: 26.02.09 15:33
Оценка: +1 -8 :))) :))
opener пишет:

> Насколько сложно перейти на Java после С++?


Сложно будет сдержать рвотный рефлекс, самопроизвольно
возникающий при виде кода на Java и спецификации языка.

Проще/сложнее сама жаба по
> сравнению с С++?

Во много-много раз. Java -- вообще примитивный язык.

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

Там не язык сложнее. Там сложнее всё остальное.
Потому что надо компенсировать убогость языка сложностью
программ, которые на нём пишут.

Если ты тупо знаешь язык, то тебе ничего платить не
будут. Если ты к этому ещё знаешь всяческие EJB/STRUTS/JPA/AJAX
и прочую херню, то -- да, тут тебе отвалят.
Posted via RSDN NNTP Server 2.1 beta
Re[4]: Переход на Java
От: MasterZiv СССР  
Дата: 26.02.09 17:13
Оценка: +1 -5 :))) :)))
unix_hater пишет:

> странное мнение. если говорить о утечках памяти — есть gc, в чем

> проблема? а вот с утечками ресурсов — ну, тут уж никакой язык не
> поможет, это логическая ошибка.

Имеется в виду то, что GC — и есть одна большая утечка памяти.
Постоянная. Мнение — не моё, ещё раз.
Posted via RSDN NNTP Server 2.1 beta
Re[7]: Переход на Java
От: drol  
Дата: 01.03.09 03:38
Оценка: 1 (1) +4 -1
Здравствуйте, Аем Вопля, Вы писали:

АВ>Ладно, я вижу, шутки вы не поняли.


Чтобы шутку понимали, она должна быть смешной.

АВ>Такие ситуация обычно и называется утечкой ресурсов.


Так вот ещё раз повторяю вопрос: причём здесь утечка памяти ?

АВ>И основная проблема как раз в том, что вызывать Dispose нужно вручную, отслеживая все ветви выполнения, а это ничем не лучше старого доброго C,


Если необходимо детерминированное освобождение ресурса, то нужно хоть что-то, но написать. Других вариантов нет. И "в отличии от", в Java хотя бы try/finally есть.

АВ>хотя, казалось бы, с появлением GC все должно делаться автоматически.


Ну так если Dispose() явно не вызовете, оно, в итоге, автоматически и сделается. Когда наступит момент срабатывания GC, он вызовет соответствующий finalizer и все неуправляемые ресурсы занятые FileStream'ом освободятся. Управляемые освободятся обычным образом: как только живые ссылки исчезнут и сработает GC.

АВ>И тут оказывается, что C++ имеет даже некоторое преимущество в этом отношении, так как поддерживает автоматический вызов деструкторов при выходе из области видимости.


Распространённое заблуждение. В деструкторе C++ можно разместить процедуры освобождения только для элементарных ресурсов. Прежде всего "чистых" объектов в памяти. Любой ресурс с нетривиальной логикой освобождения, например, распределённая транзакция, и облом-с. Бо из деструктора нельзя нормальным образом передать информацию о возникновении ошибочной ситуации в процессе этого самого освобождения.

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

АВ>Допустим, это может быть создание объектов в цикле.


Создавайте. В чём проблема ? Даже больше скажу, если это строго локальный объект цикла, то есть вероятность, что JIT сгенерит код, который больше одного такого и не создаст, а просто станет переиспользовать один и тот же объект.

АВ>Неграмотное использование GC легко может привести к созданию программы, низкая эффективность которой не влезет ни в какие ворота.


"Я плакаль" (c) не мой
Неграмотное использование C++ может к такому привести... Мне вот даже думать об этом страшно

Как раз в системе с GC, низкоквалифицированный разработчик напишет нормальный (относительно) код с гораздо более высокой вероятностью, чем в системе без оного.
*Уж поверьте человеку, который каждый год видит результаты "подвигов" студентов как на C++, так и на Java.

АВ>А GC — это такая «квазиавтоматика», когда ты все равно должен держать в голове, как этот GC работает.


GC есть система управления памятью. И, как и любую другую систему управления памятью, её, разумеется, надо знать и понимать.

АВ>И на практике получается так, что из-за GC управление ресурсами в .Net и Джаве становится местами даже еще более «ручным», чем в C++.


См. выше. Это Вам кажется от обилия всяких там smart pointer'ов и тому подобной ерунды в C++ коде. В Java всё это ненужно, бо GC как раз и решает данные проблемы.

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


Для упрощения управления ресурсами отличными от памяти.
Re: Переход на Java
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.09 20:48
Оценка: +6
Здравствуйте, opener, Вы писали:

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


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

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


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

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


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

Оба фактора при желании поддаются изменению .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Переход на Java
От: Аем Вопля  
Дата: 27.02.09 21:57
Оценка: 2 (1) +2 -2
Кто вообще сказал, что на C++ часто возникают утечки памяти? Если придерживаться определенного стиля кодирования, и руки у программистов растут из правильного места, то утечек не будет.

Нашему проекту на C и C++ уже пара лет, за все это время у нас возникла ровно одна (1 — одна) утечка памяти, которая была исправлена за пять минут, и то она возникла потому, что программист, который написал код, имеет привычку писать неаккуратно.

Зато от коллег, пишущих на C#, я много раз слышал разговоры об утечках.

Ключевое слово using их спасает. А то у них вообще был бы практически C.

Вот как мучаются те, кто пишет на J#:

import System.*;
import System.IO.*;
import System.Text.*;

class Test
{
    public static void main(String[] args)
    {
        String path = "c:\\temp\\MyTest.txt";

        // Delete the file if it exists.
        if (!(File.Exists(path))) {
            // Create the file.
            FileStream fs = File.Create(path);
            try {
                ubyte info[] =(new UTF8Encoding(true)).GetBytes("This is some" 
                    + " text in the file.");

                // Add some information to the file.
                fs.Write(info, 0, info.length);
            }
            finally {
                fs.Dispose();
            }
        }
        // Open the stream and read it back.
        FileStream fs = File.Open(path, FileMode.Open);

        try {
            ubyte b[] = new ubyte[1024];
            UTF8Encoding temp = new UTF8Encoding(true);

            while (fs.Read(b, 0, b.length) > 0) {
                Console.WriteLine(temp.GetString(b));
            }
        }
        finally {
            fs.Dispose();
        }
    } //main
} //Test


Ну это же точно как в C! Забудешь закрыть файл — получишь утечку ресурсов. И все надо закрывать руками, отслеживая ветви выполнения.

Конечно, это же совсем не то, что «неуправляемый» C++!

#include <fstream>
using namespace std;
int main()
{
    ifstream file("file.txt");

    if (!file)
    {
        return 1;
    }

    int n;

    file >> n;

    if (n < 0)
    {
        // И не надо вручную ничего закрывать.
        return 1;
    }

    return 0;
}
Re[12]: Переход на Java
От: Аем Вопля  
Дата: 28.02.09 17:38
Оценка: -5
По-моему, это ты ничего не понял.

Почему-то мне кажется, что тебе мало лет (16?).
Re[5]: Переход на Java
От: drol  
Дата: 28.02.09 09:54
Оценка: +3 -1
Здравствуйте, Аноним, Вы писали:

А>А в чем отличие освобождения памяти от освобождения ресурсов?


В масштабе. Память есть самый интенсивно используемый ресурс. Посему и необходимость снижения возможностей для ошибок в управлении ею стоит в первых рядах.
Re[9]: Переход на Java
От: drol  
Дата: 01.03.09 09:46
Оценка: :))) :)
Здравствуйте, Аем Вопля, Вы писали:

D>>Чтобы шутку понимали, она должна быть смешной.

АВ>Чтобы шутка была смешной, ее нужно понимать.

Я так и знал, что по остальным вопросам возражений не будет
Re[5]: Переход на Java
От: Пацак Россия  
Дата: 27.02.09 22:14
Оценка: :)))
Здравствуйте, MasterZiv, Вы писали:

MZ>Имеется в виду то, что GC — и есть одна большая утечка памяти.

MZ>Постоянная. Мнение — не моё, ещё раз.

Ну считай, что минусы тогда тоже не тебе.
Ку...
Re: Переход на Java
От: ArtK  
Дата: 25.02.09 09:03
Оценка: +2
Здравствуйте, opener, Вы писали:

O>Насколько сложно перейти на Java после С++? Проще/сложнее сама жаба по сравнению с С++? По моим нынешним представлениям вроде проще. И какого тогда хрена у жаба-программистов зарплаты больше?


Сам недавно начал делать проект на Java, до этого работал только с C++. imho язык чуть проще, но своих нюансов хватает. Основную сложность составляет изучения сопутствующих технологий, без которых в Java никак. А вообще переход с C++ на Java подразумевает смену области деятельности, т.к. языки созданы для решения разных задач.
Re[2]: Переход на Java
От: MasterZiv СССР  
Дата: 26.02.09 15:35
Оценка: -2
Аноним 321 пишет:

> нет утечек памяти... Есть. Но они возникают гораздо реже, чем в C/C++.


Есть другое мнение (не моё). Что там утечки ВООБЩЕ ПОСТОЯННО ВОЗНИКАЮТ.

Posted via RSDN NNTP Server 2.1 beta
Re[4]: Переход на Java
От: Аем Вопля  
Дата: 28.02.09 12:15
Оценка: :))
П>Теперь внимание, вопрос: какое отношение имеют утечки памяти к приведенному фрагменту кода?

Файл — это участок памяти, распределенной на энергонезависимом запоминающем устройстве.
Re[6]: Переход на Java
От: Аем Вопля  
Дата: 28.02.09 16:51
Оценка: +1 -1
D>Не очень понятно что Вы конкретно имели в виду, однако, в любом случае, утечка всё равно не вытанцовывается.
D>Ну не вызвали Dispose() у FileStream'а, и что ? "Распределённой на энергонезависимом запоминающем устройстве" памяти в виде файла от этого ни холодно, ни жарко. Как был файл, так он и остался. Особенно при работе "только на чтение"

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

И основная проблема как раз в том, что вызывать Dispose нужно вручную, отслеживая все ветви выполнения, а это ничем не лучше старого доброго C, хотя, казалось бы, с появлением GC все должно делаться автоматически.

И тут оказывается, что C++ имеет даже некоторое преимущество в этом отношении, так как поддерживает автоматический вызов деструкторов при выходе из области видимости.

Пример с файлом был не самым удачным, просто пример с памятью мне было придумывать лень. Если вы программировали на Джаве или C#, думаю вы и сами таких примеров придумаете достаточно. Допустим, это может быть создание объектов в цикле.

Неграмотное использование GC легко может привести к созданию программы, низкая эффективность которой не влезет ни в какие ворота. А такая ситуация у меня плохо ассоциируется с «автоматикой». Для меня, «автоматическое» — это то, что делается само, не требуя от меня никакого участия. А GC — это такая «квазиавтоматика», когда ты все равно должен держать в голове, как этот GC работает.

И на практике получается так, что из-за GC управление ресурсами в .Net и Джаве становится местами даже еще более «ручным», чем в C++.

Я не прав? Если я не прав, зачем тогда ввели ключевое слово using в C#, а? Если и так все «автоматическое»?
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[3]: Переход на Java
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.03.09 13:35
Оценка: 1 (1)
Здравствуйте, CreatorCray, Вы писали:

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


Потому что хороший современный язык обязан быть спроектирован в том числе и с учетом простоты и удобства как создания фреймворков, так и их использования. А для С++ даже ABI все никак не устаканят.
... << RSDN@Home 1.2.0 alpha 4 rev. 1137 on Windows Vista 6.0.6001.65536>>
AVK Blog
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!
Переход на Java
От: opener  
Дата: 25.02.09 08:42
Оценка: :)
Насколько сложно перейти на Java после С++? Проще/сложнее сама жаба по сравнению с С++? По моим нынешним представлениям вроде проще. И какого тогда хрена у жаба-программистов зарплаты больше?

01.03.09 01:48: Перенесено модератором из 'C/C++' — Кодт
Re: Переход на Java
От: Аноним  
Дата: 26.02.09 07:57
Оценка: +1
Не проще. Java другая. Например, GC предполагает другие идиомы создания и удаления объектов. Есть еще распространенное заблуждение, что в Java нет утечек памяти... Есть. Но они возникают гораздо реже, чем в C/C++.

И главное — библиотеки. В Java создано огромное множество кросс-платформенных библиотек. В С/С++ немного не так. Здесь же чувствуется единство этих библиотек. Не случайно, Java часто называют "платформой".
Re[4]: Переход на Java
От: Аноним  
Дата: 27.02.09 09:45
Оценка: +1
_>странное мнение. если говорить о утечках памяти — есть gc, в чем проблема? а вот с утечками ресурсов — ну, тут уж никакой язык не поможет, это логическая ошибка.

А в чем отличие освобождения памяти от освобождения ресурсов? До появления gc ошибки освобождения памяти точно так же назвали бы логической ошибкой, нет?
Re[3]: Переход на Java
От: drol  
Дата: 28.02.09 14:53
Оценка: -1
Здравствуйте, CreatorCray, Вы писали:

CC>В С++ декларируется "принцип платишь только за то, что реально используешь". В соответствии с ним — поставляется жизненно необходимый минимум.


Ерунда. На каждый момент времени "жизненно необходимый минимум" есть вполне конкретное понятие. И в 2009 году, когда даже зачуханный стобаксовый сотовый телефон спокойно поддерживает CLDC-1.1/MIDP-2.0/JSR 135/ещё много чего, стандартная библиотека C++ — реликт каменного века.

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


Потому что у нормальных людей есть дела поважнее изобретения велосипедов и ковыряния в compatibility issues. Посему они и выбирают не языки, а платформы.

CC>ИМХО появление новых языков с большими библиотеками в комплекте необходимая мера в последнее время.


Это "последнее" время длиться уже как минимум 15+ лет.

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


"Большая" она сейчас, а "в момент появления" ничего особо большого там не было. Только "жизненно необходимый минимум"
Re[6]: Переход на Java
От: MasterZiv СССР  
Дата: 28.02.09 16:09
Оценка: :)
Пацак пишет:

> MZ>Имеется в виду то, что GC — и есть одна большая утечка памяти.

> MZ>Постоянная. Мнение — не моё, ещё раз.
>
> Ну считай, что минусы тогда тоже не тебе.

Какие минусы ? Не понял.
Posted via RSDN NNTP Server 2.1 beta
Re[9]: Переход на Java
От: Пацак Россия  
Дата: 28.02.09 17:18
Оценка: -1
Здравствуйте, Аем Вопля, Вы писали:

АВ>Этот ответ ничего не прояснил.


Не мои проблемы, я старался как мог.

П>>Равно как и я — между приведенным кодом и утечками памяти.


АВ>здесь
Автор: Аем Вопля
Дата: 28.02.09


Хм...

АВ>когда вы открываете файл, выделяются некие ресурсы, необходимые для работы с этим файлом, включая оперативную память


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

АВ>Пример с файлом был не самым удачным, просто пример с памятью мне было придумывать лень.


А, вон как...

АВ>Если вы программировали на Джаве или C#, думаю вы и сами таких примеров придумаете достаточно. Допустим, это может быть создание объектов в цикле.


Рассмотрим простейший:

for (int i=0; i<1000000; i++) {
  Foo foo = new Foo();
  bar(foo);
}


Разницу в поведении для C++ и java объяснять надо или все понятно и так?

АВ>Неграмотное использование GC легко может привести к созданию программы, низкая эффективность которой не влезет ни в какие ворота.


...равно как и неиспользование. Только последнее, как любой ручной процесс, еще и чревато трудноуловимыми багами.

АВ>Я не прав?


Нет.

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


Без понятия, равно как и о многом другом в C#. Но мы сейчас таки не о нем, а о C++ vs Java.
Ку...
Re[10]: Переход на Java
От: Аем Вопля  
Дата: 28.02.09 17:30
Оценка: -1
П>Не мои проблемы, я старался как мог.

Не надо хамить.
Re[10]: Переход на Java
От: Пацак Россия  
Дата: 28.02.09 20:14
Оценка: +1
Здравствуйте, MasterZiv, Вы писали:

MZ>Не, реально, даже само название статьи торкает конкретно:

MZ>"Handling memory leaks in Java programs". !!!

Правильнее было бы назвать статью "Emulating memory leaks in Java programs", т.к. по сравнению с реальной утечкой памяти (когда средствами языка ее уже невозможно вернуть в использование) рассматриваемая в ней ситуация имеет куда более тривиальный характер — память всего лишь нерационально используется, только и всего. Да, это плохо и может привести к проблемам (довольно редко, впрочем), но конкретно к java как таковой отношения не имеет — умеючи, того же эффекта можно добиться практически на любом языке.
Ку...
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[10]: Переход на Java
От: _________  
Дата: 02.03.09 20:49
Оценка: -1
D>Я так и знал, что по остальным вопросам возражений не будет

А не с чем спорить: вы не опровергаете то, о чем я писал.
Re[14]: Переход на Java
От: MasterZiv СССР  
Дата: 04.03.09 06:50
Оценка: :)
rsn81 пишет:

> MZ>Если да,

> Ага, да!
>
> MZ>то вы ловите также и RuntimeException.
> А вот это нет, нет здесь никакой связи "если-то"!

Господа, я устал вам объяснять очевидное.
Более этим заниматься не хочу.
Posted via RSDN NNTP Server 2.1 beta
Re: Переход на Java
От: Аноним  
Дата: 25.02.09 08:51
Оценка:
Здравствуйте, opener, Вы писали:

O>Насколько сложно перейти на Java после С++? Проще/сложнее сама жаба по сравнению с С++? По моим нынешним представлениям вроде проще. И какого тогда хрена у жаба-программистов зарплаты больше?

Во первых зарплата определяется не сложностью работы, а тем сколько бабла приносят ее результаты
Во вторых я бы не говорил так однозначно
Re: Переход на Java
От: yumi  
Дата: 26.02.09 08:12
Оценка:
Здравствуйте, opener, Вы писали:

O>Насколько сложно перейти на Java после С++? Проще/сложнее сама жаба по сравнению с С++? По моим нынешним представлениям вроде проще. И какого тогда хрена у жаба-программистов зарплаты больше?


Смотря, что значит перейти на Java. Если изучить язык, то где-то неделя примерно. Как язык, она действительно проще, это типичный bondage & discipline язык

И на какую именно Джаву, J2ME, J2SE, J2EE... Изучение не только языка, но и изучение сопутствующих подходов, библиотек, требует чуть больше времени.

Насчет зарплат, то она не коррелирует со сложностью инструмента, а зависит от производительности труда программиста, использующего тот или иной инструмент.
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[3]: Переход на Java
От: unix_hater  
Дата: 26.02.09 16:14
Оценка:
Здравствуйте, MasterZiv, Вы писали:

MZ>Аноним 321 пишет:


>> нет утечек памяти... Есть. Но они возникают гораздо реже, чем в C/C++.


MZ>Есть другое мнение (не моё). Что там утечки ВООБЩЕ ПОСТОЯННО ВОЗНИКАЮТ.


MZ>


странное мнение. если говорить о утечках памяти — есть gc, в чем проблема? а вот с утечками ресурсов — ну, тут уж никакой язык не поможет, это логическая ошибка.
Re: Переход на Java
От: LaptevVV Россия  
Дата: 27.02.09 13:13
Оценка:
Здравствуйте, opener, Вы писали:

O>Насколько сложно перейти на Java после С++? Проще/сложнее сама жаба по сравнению с С++? По моим нынешним представлениям вроде проще. И какого тогда хрена у жаба-программистов зарплаты больше?

1. Меня лично напрягала необходимость обязательно писать обработку исключений.
2. Большая библиотека. Гораздо больше С++ и разнообразней.
Ну. еще памятью управлять явно не нужно.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re: Переход на Java
От: srggal Украина  
Дата: 27.02.09 14:14
Оценка:
Здравствуйте, opener, Вы писали:

O>Насколько сложно перейти на Java после С++? Проще/сложнее сама жаба по сравнению с С++? По моим нынешним представлениям вроде проще. И какого тогда хрена у жаба-программистов зарплаты больше?


Перешел, скучаю по С++, особенно при работе с Generic'ами...
Поскольку нищи у языков разные, то переход на Java подразумевает изучение кучи всего помимо Java, но об этом уже писали.

Что такое "куча всего" в моём случае (из основного, что вспомнилось):
JPA/Eclipselink
Spring/Security/orm/rcp
JAX-WS/WS-I
OSGi
Ant
Maven
AOP/AspectJ
ЗЫ
Самое стремное по началу -- gc...
Re[3]: Переход на Java
От: Пацак Россия  
Дата: 27.02.09 22:21
Оценка:
Здравствуйте, Аем Вопля, Вы писали:

АВ>Кто вообще сказал, что на C++ часто возникают утечки памяти?

...
АВ>Вот как мучаются те, кто пишет на J#:

АВ>
...
АВ>


Теперь внимание, вопрос: какое отношение имеют утечки памяти к приведенному фрагменту кода?
Ку...
Re[3]: Переход на Java
От: CreatorCray  
Дата: 28.02.09 13:25
Оценка:
Здравствуйте, Аем Вопля, Вы писали:

АВ>Кто вообще сказал, что на C++ часто возникают утечки памяти? Если придерживаться определенного стиля кодирования, и руки у программистов растут из правильного места, то утечек не будет.

+1
У меня в проекте-тесте для либы даже спецом есть код который намеренно делает утечку чтоб убедится что BoundsChecker не поломался вдруг и мышек все еще ловит.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Переход на Java
От: CreatorCray  
Дата: 28.02.09 13:25
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>2. Большая библиотека. Гораздо больше С++ и разнообразней.

В С++ декларируется "принцип платишь только за то, что реально используешь". В соответствии с ним — поставляется жизненно необходимый минимум.

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

ИМХО появление новых языков с большими библиотеками в комплекте необходимая мера в последнее время.
Во сколько раз меньше народу в момент появления той же Java стало бы писать на ней не будь под нее большой библы с готовыми велосипедами?
Поэтому хочешь продвинуть язык — сделай так, чтоб начать лабать на нем можно было сразу. Отсюда наличие большой библиотеки просто must have.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Переход на Java
От: drol  
Дата: 28.02.09 13:53
Оценка:
Здравствуйте, Аем Вопля, Вы писали:

П>>Теперь внимание, вопрос: какое отношение имеют утечки памяти к приведенному фрагменту кода?


АВ>Файл — это участок памяти, распределенной на энергонезависимом запоминающем устройстве.


Не очень понятно что Вы конкретно имели в виду, однако, в любом случае, утечка всё равно не вытанцовывается.
Ну не вызвали Dispose() у FileStream'а, и что ? "Распределённой на энергонезависимом запоминающем устройстве" памяти в виде файла от этого ни холодно, ни жарко. Как был файл, так он и остался. Особенно при работе "только на чтение"
Re[5]: Переход на Java
От: Пацак Россия  
Дата: 28.02.09 14:23
Оценка:
Здравствуйте, Аем Вопля, Вы писали:

АВ>Файл — это участок памяти, распределенной на энергонезависимом запоминающем устройстве.


Офигеть! А почему мы тогда не говорим о вредном воздействии java-программ на вселенскую энтропию?
Ку...
Re[3]: Переход на Java
От: MasterZiv СССР  
Дата: 28.02.09 16:17
Оценка:
CreatorCray пишет:

> Вот мне всегда было непонятно, почему в плюс языка всегда пытаются

> отнести большую стандартную библиотеку?

Потому что на таком языке легче писать переносимые и кроссплатформенные
программы. Это, конечно, в современном мире ни на фиг никому не надо,
но всё же.

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


Если эта стандартная библиотека стандартизована и её реализация
обезательна, то -- для самого языка.
Posted via RSDN NNTP Server 2.1 beta
Re[2]: Переход на Java
От: MasterZiv СССР  
Дата: 28.02.09 16:19
Оценка:
srggal пишет:

> Ant

> Maven

Это из списка можно смело выкинуть.
Это можно применять и для С/С++, знания универсальный.
Posted via RSDN NNTP Server 2.1 beta
Re[6]: Переход на Java
От: Аем Вопля  
Дата: 28.02.09 16:27
Оценка:
П>Офигеть! А почему мы тогда не говорим о вредном воздействии java-программ на вселенскую энтропию?

Это вы к чему? Не вижу связи.
Re[7]: Переход на Java
От: Пацак Россия  
Дата: 28.02.09 16:48
Оценка:
Здравствуйте, Аем Вопля, Вы писали:

П>>Офигеть! А почему мы тогда не говорим о вредном воздействии java-программ на вселенскую энтропию?


АВ>Это вы к чему?


К тому что "обобщать — так уж обобщать".

АВ>Не вижу связи.


Равно как и я — между приведенным кодом и утечками памяти.
Ку...
Re[3]: Переход на Java
От: Пацак Россия  
Дата: 28.02.09 16:49
Оценка:
Здравствуйте, MasterZiv, Вы писали:

>> Ant

>> Maven

MZ>Это можно применять и для С/С++, знания универсальный.


Можно, но количество плагинов несопоставимо.
Ку...
Re[8]: Переход на Java
От: Аем Вопля  
Дата: 28.02.09 16:53
Оценка:
П>К тому что "обобщать — так уж обобщать".

Этот ответ ничего не прояснил.

П>Равно как и я — между приведенным кодом и утечками памяти.


здесь
Автор: Аем Вопля
Дата: 28.02.09
Re[8]: Переход на Java
От: Аем Вопля  
Дата: 28.02.09 17:16
Оценка:
Мне кажется, что вы сами прекрасно знаете, о чем я говорю, просто вам хочется поспорить.

Ну да, пример немного неудачный, но я говорю я обо всем известных вещах, которые и так должны быть понятны, даже без примеров: здесь
Re[7]: Переход на Java
От: MasterZiv СССР  
Дата: 28.02.09 17:20
Оценка:
Аем Вопля пишет:

> И основная проблема как раз в том, что вызывать Dispose нужно вручную,

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

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

Ну и я хотел бы добавить, что в Java даже нет средств расширения языка,
которые могли бы позволить, скажем, программисту, пишушему класс для работы
с файлом, сделать что-то, что позволило бы программисту, использующему
этот класс, НЕ ДУМАТЬ О ЗАКРЫТИИ ФАЙЛА.

Единственное, что приходит на ум, это решение в стиле Java
-- реализовать класс-стратегию для работы с файлом, которая бы открывала
файл, вызывала пользоват. код и закрывала бы файл
-- реализовать интерфейс для осуществления операций с файлом
-- дать пользователю реализовать этот интерфейс, создать стратегию,
и имплементацию этого интерфейса, и, слив это всё в едином экстазе,
вызвать главный метод стратегии, который бы всё делал.

Но это, как вы понимаете,

-- выглядит гораздо сложнее, чем
try
{
}
finally { file.close() }

-- никак не решает проблемы, потому что пользователю всё равно
придётся заботится о том, чтобы файл закрывался сам, оформляя весь
код имменно таким образом,

-- и наконец просто слишком сложно для того, чтобы не забыть
закрыть файл.
Posted via RSDN NNTP Server 2.1 beta
Re[7]: Переход на Java
От: MasterZiv СССР  
Дата: 28.02.09 17:23
Оценка:
> Я не прав? Если я не прав, зачем тогда ввели ключевое слово using в C#,
> а? Если и так все «автоматическое»?

Ну отчасти не прав. В том, что GC всё-таки работают, как идея, и реальные
системы на них и на Java тоже работают. Может, требуют больше ресурсов.
Но работают -- это надо признать, хотя я тоже от этого не в восторге.
Posted via RSDN NNTP Server 2.1 beta
Re[11]: Переход на Java
От: Пацак Россия  
Дата: 28.02.09 17:35
Оценка:
Здравствуйте, Аем Вопля, Вы писали:

АВ>Не надо хамить.


Какое хамство? Ситуация: я объяснил, ты не понял. Согласись, если для кого-то из нас это и проблема — то уж точно не для меня.
Ку...
Re[8]: Переход на Java
От: Пацак Россия  
Дата: 28.02.09 17:42
Оценка:
Здравствуйте, MasterZiv, Вы писали:

MZ>Ну и я хотел бы добавить, что в Java даже нет средств расширения языка,

MZ>которые могли бы позволить, скажем, программисту, пишушему класс для работы
MZ>с файлом, сделать что-то, что позволило бы программисту, использующему
MZ>этот класс, НЕ ДУМАТЬ О ЗАКРЫТИИ ФАЙЛА.

Вопрос в том, так ли уж часто это надо пользователю. Как правило если пользователь хочет "не думать о файлах", то он хочет не думать именно о файловом вводе/выводе вообще, получив взамен нечто более высокоуровневое — типа, скажем, такого:

  DocumentBuilder builder = DocumentBuilderFactory.newInstance().newDocumentBuilder();
  File file = new File("/home/user/foo.xml");
  Document doc = builder.parse(file);


Задача программиста, пишущего либу — дать ему такую возможноть. И это будет всяко красивее и читабельнее, чем манипуляции с try ... finally или неявными действиями в деструкторе.
Ку...
Re[13]: Переход на Java
От: Пацак Россия  
Дата: 28.02.09 17:46
Оценка:
Здравствуйте, Аем Вопля, Вы писали:

АВ>Почему-то мне кажется, что тебе мало лет (16?).


Это имеет какое-то отношение к проблемам выделения памяти в C++? Нельзя ли ближе к сути?

ЗЫ Обращение на "ты" негласно принято by default на rsdn. Впрочем, если Вы, сударь, настаиваете, то для Вас я могу сделать исключение.
Ку...
Re[14]: Переход на Java
От: Аем Вопля  
Дата: 28.02.09 17:51
Оценка:
Отклонение от темы началось с вот этого вашего сообщения:

«Офигеть! А почему мы тогда не говорим о вредном воздействии java-программ на вселенскую энтропию?»

Прекратим диалог на этом.
Re[9]: Переход на Java
От: Пацак Россия  
Дата: 28.02.09 17:52
Оценка:
Здравствуйте, Пацак, Вы писали:

П>Вопрос в том, так ли уж часто это надо пользователю.


Пардон, оговорка по Фрейду. Имелось в виду "программисту, работающему с нашим классом". Пользователю нашей либы, иначе говоря.
Ку...
Re[15]: Переход на Java
От: Пацак Россия  
Дата: 28.02.09 17:58
Оценка:
Здравствуйте, Аем Вопля, Вы писали:

АВ>Отклонение от темы началось с вот этого вашего сообщения:

АВ>«Офигеть! А почему мы тогда не говорим о вредном воздействии java-программ на вселенскую энтропию?»

Напротив, сударь — это была попытка вернуть Вас к начатой в ветке теме, а именно к проблемам с утечками памяти.

АВ>Прекратим диалог на этом.


Как Вам будет угодно. Тем более, что судя по всему, сказать по сути Вы толком ничего не можете. Надеюсь диалог с MasterZiv окажется более плодотворным.
Ку...
Re[9]: Переход на Java
От: MasterZiv СССР  
Дата: 28.02.09 19:06
Оценка:
Пацак пишет:

> Вопрос в том, так ли уж часто это надо пользователю. Как правило если

> пользователь хочет "не думать о файлах", то он хочет не думать именно о
> файловом вводе/выводе вообще, получив взамен нечто более высокоуровневое
> — типа, скажем, такого:


>

> DocumentBuilder builder = DocumentBuilderFactory.newInstance().newDocumentBuilder();
> File file = new File("/home/user/foo.xml");
> Document doc = builder.parse(file);

Это — ровно то самое, о чём я написал.
И это — уход от темы, потому как вы подменяете одно другим.
Я говорю о случае, когда от файла человеку ничего более не нужно,
кроме как просто ввода-вывода. Вы же говорите о более "высокого уровня"
случае, когда применение стратегий будет уже оправдано.

Я говорю, что в таком примитивном случае pattern-based машинерия Java
НЕ РАБОТАЕТ, потому что слишком тяжела для такого простого случая,
вы же делаете случай гораздо более сложным, и говорите, что такая
машинерия работает в этом случае. Я спорить не буду, да, работает,
но СЛУЧАЙ ДРУГОЙ. И в других языках тут ничем это не будет отличаться --
для разбора XML-я или рег.выражения в C++ или PERL наверное будут
использоваться подобные же подходы.

Но случай с открытием файла — это лишь ПРИМЕР того, где технология
Java (с нашей точки зрения) "лажает". Нет смысла рассматривать
другой пример и доказывать, что там она "не лажает".
Posted via RSDN NNTP Server 2.1 beta
Re[16]: Переход на Java
От: MasterZiv СССР  
Дата: 28.02.09 19:09
Оценка:
Пацак пишет:

> Как Вам будет угодно. Тем более, что судя по всему, сказать по сути Вы

> толком ничего не можете. Надеюсь диалог с MasterZiv окажется более
> плодотворным.

Да, вас явно занесло. Наверное, обоих, потому как я не понял, кто начал.
Posted via RSDN NNTP Server 2.1 beta
Re[9]: Переход на Java
От: MasterZiv СССР  
Дата: 28.02.09 19:12
Оценка:
Аем Вопля пишет:

> Ну да, пример немного неудачный, но я говорю я обо всем известных вещах,

> которые и так должны быть понятны, даже без примеров: здесь
> <http://www.ibm.com/developerworks/library/j-leaks/index.html&gt;

Классно, спасибо.
Добавил страницу в закладки, буду читать перед сном, и
давать в виде ссылки всем тем, кто думает, что GC решает все проблемы
на свете.

Не, реально, даже само название статьи торкает конкретно:
"Handling memory leaks in Java programs". !!!
Posted via RSDN NNTP Server 2.1 beta
Re: Переход на Java
От: MasterZiv СССР  
Дата: 28.02.09 19:15
Оценка:
opener пишет:

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

> сравнению с С++? По моим нынешним представлениям вроде проще. И какого
> тогда хрена у жаба-программистов зарплаты больше?

Что-то мы тут (в теме) сильно отошли кажется от темы эхотага.
Я искренне не виноват. А если виноват — каюсь.
Может быть модератор с соглашения автора сочтёт возможным
перенаправить нас на путь истенный, типа в философии, или ещё где ?
Я извиняюсь за самомодерирование...
Posted via RSDN NNTP Server 2.1 beta
Re[10]: Переход на Java
От: Пацак Россия  
Дата: 28.02.09 20:05
Оценка:
Здравствуйте, MasterZiv, Вы писали:

MZ>Это — ровно то самое, о чём я написал.


Возможно я пропустил... Где именно?

MZ>И это — уход от темы, потому как вы подменяете одно другим.

MZ>Я говорю о случае, когда от файла человеку ничего более не нужно,
MZ>кроме как просто ввода-вывода. Вы же говорите о более "высокого уровня"
MZ>случае, когда применение стратегий будет уже оправдано.

Ну я, собственно, пытаюсь разобраться — а так ли уж часть программистам нужен "просто файловый ввод-вывод"? Насколько я могу судить, обычно на одного core-developer'а, занимающегося работой с ресурсами, приходится десяток-два "пользователей" его кода, работающих с более высокоуровневыми понятиями — документами, архивами, конфигурациями etc. И с точки зрения инкапсуляции, им должно быть совершенно безразлично, как именно внутри организованы его классы.

MZ>Но случай с открытием файла — это лишь ПРИМЕР того, где технология

MZ>Java (с нашей точки зрения) "лажает".

Зависит от ситуации. Можно сходу придумать пример, где освобождение ресурсов в деструкторе будет создавать неудобства и потенциальные ошибки. Что, например, произойдет, если плюсовая функция вернет указатель на открытый в локальном контексте файл? А если дочерняя функция начнет чтение из него в отдельном потоке? Автоматические деструкторы сами по себе — не панацея и не освобождают от необходимости думать и следить за стилем кодирования. По крайней мере имхо делают это гораздо реже и в меньшей степени, чем garbage collector в java.
Ку...
Re[2]: Переход на Java
От: Пацак Россия  
Дата: 28.02.09 20:18
Оценка:
Здравствуйте, MasterZiv, Вы писали:

MZ>Может быть модератор с соглашения автора сочтёт возможным

MZ>перенаправить нас на путь истенный, типа в философии, или ещё где ?
MZ>Я извиняюсь за самомодерирование...

Вроде бы на rsdn самомодерирование даже приветствуется — если делать его через "бомбочки". Я свою повесил на головное сообщение — за перенос в "философию программирования". Предлагаю сделать так же.
Ку...
Re[2]: Переход на Java
От: alexeiz  
Дата: 01.03.09 00:47
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>1. Меня лично напрягала необходимость обязательно писать обработку исключений.


Что в Java в этом плане лучше? Или ты для освобождения памяти и ресурсов в C++ писал обработчики исключений?
Re[3]: Переход на Java
От: Пацак Россия  
Дата: 01.03.09 02:10
Оценка:
Здравствуйте, alexeiz, Вы писали:

LVV>>1. Меня лично напрягала необходимость обязательно писать обработку исключений.


A>Что в Java в этом плане лучше?


Я так понимаю, что имелось в виду следующее: если в каком-то методе возникает исключение, то ты должен либо явно обработать его, либо явно же добавить его к описанию этого метода. В последнем случае его надо будет (опять же явно и обязательно) обработать где-то выше. Например:

  // Так можно - исключение декларируется
  void foo1() throws MyException {
    throw new MyException();
  }
  
  // И так тоже - исключение обрабатывается
  void foo2() {
    try {
      throw new MyException();
    } catch (MyException e) {
      // do smth
    }
  }
  
  // А вот так - уже нет. Нужно определить либо то, либо то
  void foo3() {
    throw new MyException();
  }


С++ в этом плане более лоялен, а в java эти строгости действительно иногда напрягают. Впрочем, польза от них тоже есть — глядя на код сразу видно, где и какой конкретно shit может happens. Так что это, как обычно, палка о двух концах...
Ку...
Re[4]: Переход на Java
От: MasterZiv СССР  
Дата: 01.03.09 03:32
Оценка:
Пацак пишет:

> С++ в этом плане более лоялен, а в java эти строгости действительно

> иногда напрягают. Впрочем, польза от них тоже есть — глядя на код сразу
> видно, где и какой конкретно shit может happens. Так что это, как

На самом деле в Java можно делать и так, и так, т.е. и как в С++.
В Java есть два вида исключений: простые (можно сказать strict) и Runtime
Exceptions.
Runtime Exceptions обрабатываются ровно так же в смысле обязательности
перехвата, как и в С++, т.е. их перехватывать либо объявлять не обязательно. То
есть в принципе можно было бы делать и
так, и так, сочетая при этом всё в одной программе.
Но только :

-- решение об этом принимает разработчик класса, а не пользователь
-- многие программисты либо вообще не знают про такие возможности, либо
не понимают преимуществ Runtime Exceptions, или тупо не хотят разбираться
с этим.

И в итоге наверное подавляющее большинство исплючений в реальном
коде Java — strict.
Posted via RSDN NNTP Server 2.1 beta
Re[8]: Переход на Java
От: Аем Вопля  
Дата: 01.03.09 08:41
Оценка:
D>Чтобы шутку понимали, она должна быть смешной.

Чтобы шутка была смешной, ее нужно понимать.
Re[5]: Переход на Java
От: Пацак Россия  
Дата: 01.03.09 08:57
Оценка:
Здравствуйте, MasterZiv, Вы писали:

MZ>На самом деле в Java можно делать и так, и так, т.е. и как в С++.


Можно, но подменять одно другим — считается несколько дурным тоном. И в общем-то практически никогда это не бывает нужно — за исключением разве что случая, когда нужно переопределить метод предка, но добавить к нему выброс еще одного типа исключения не позволяет синтаксис. Тут приходится извращаться — оборачивать checked exception в runtime exception, а потом извлекать снаружи. Но тут надо четко понимать, что кроме конкретно этого нашего кода этот метод может использоваться и в других местах, где никто не ждет выброса необъявленного исключения и поэтому оно может привести к непредсказуемым последствиям. Так что опять же — и хорошо и плохо, it depends.
Ку...
Re[6]: Переход на Java
От: MasterZiv СССР  
Дата: 01.03.09 12:03
Оценка:
Пацак пишет:

Тут приходится
> извращаться — оборачивать checked exception в runtime exception, а потом
> извлекать снаружи. Но тут надо четко понимать, что кроме конкретно этого
> нашего кода этот метод может использоваться и в других местах, где никто
> не ждет выброса необъявленного исключения и поэтому оно может привести к
> непредсказуемым последствиям.

Чтобы в Java НЕ ЖДАЛИ появления RuntimeException, которое по сути своей
непредсказуемо появляется, -- это новость какая-то.
Posted via RSDN NNTP Server 2.1 beta
Re[8]: Переход на Java
От: MasterZiv СССР  
Дата: 01.03.09 12:04
Оценка:
drol пишет:

> Ну так если *Dispose()* явно не вызовете, оно, в итоге, автоматически и

> сделается. Когда наступит момент срабатывания GC, он вызовет
> соответствующий finalizer и все /неуправляемые/ ресурсы занятые
> *FileStream*'ом освободятся. Управляемые освободятся обычным образом:
> как только живые ссылки исчезнут и сработает GC.

Вы пишите на Java finalizer-ы ?

Потом, ключевая фраза тут "когда наступит момент срабатывания GC".
А он, вообще-то, может и никогда не наступить.

> Распространённое заблуждение. В деструкторе C++ можно разместить

> процедуры освобождения только для элементарных ресурсов. Прежде всего
> "чистых" объектов в памяти. Любой ресурс с нетривиальной логикой
> освобождения, например, распределённая транзакция, и облом-с. Бо из
> деструктора нельзя нормальным образом передать информацию о
> возникновении ошибочной ситуации в процессе этого самого освобождения.

Да пожалуйста, передавайте. Сохраните только предварительно внутри
этого объекта.

Ладно, я не вижу что тут можно ещё спорить или доказывать.
Posted via RSDN NNTP Server 2.1 beta
Re[9]: Переход на Java
От: drol  
Дата: 01.03.09 12:26
Оценка:
Здравствуйте, MasterZiv, Вы писали:

MZ>Вы пишите на Java finalizer-ы ?


Нет, бо не работаю (промышленно) на Java уже более трёх лет. Сейчас я их пишу на C#, точнее пишу то что из finalizer'ов вызывается.

MZ>Потом, ключевая фраза тут "когда наступит момент срабатывания GC".

MZ>А он, вообще-то, может и никогда не наступить.

Типа удивили. Вызов деструктора C++ тоже может никогда не наступить. Какой-нибудь kill -9 и "до свидания, друзья, до свидания..."

>> Бо из

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

MZ>Да пожалуйста, передавайте. Сохраните только предварительно внутри

MZ>этого объекта.

Какого объекта ? Объекта уже нет. Фигня ведь случилась в автоматическом вызове деструктора.

MZ>Ладно, я не вижу что тут можно ещё спорить или доказывать.


Конечно. Ведь тут C++ надо знать и понимать
Re[4]: Переход на Java
От: Аем Вопля  
Дата: 01.03.09 13:49
Оценка:
Согласен, C++ — говно-язык.
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[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[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[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, например ?
Re[13]: Переход на Java
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 03.03.09 13:38
Оценка:
Здравствуйте, drol, Вы писали:

D>Неуверен, что все наследники RuntimeException подходят под Вашу классификацию. Вот SecurityException, например ?

А что не так? После того, как авторизация действия не пройдена, как и после деления на ноль — собственно, поздно махать кулаками, надо было сделать так, чтобы не было как деления на ноль, так и попытки выполнить неавторизуемое действие.
И потом, это не моя классификация, а Sun Microsystem: Unchecked Exceptions — The Controversy.
Re[14]: Переход на Java
От: drol  
Дата: 03.03.09 14:29
Оценка:
Здравствуйте, rsn81, Вы писали:

D>>Неуверен, что все наследники RuntimeException подходят под Вашу классификацию. Вот SecurityException, например ?


R>А что не так?


То что ловить надо по-месту. Ну например, я лезу к ресурсу, а доступ к нему запрещён.

R>надо было сделать так, чтобы не было как деления на ноль, так и попытки выполнить неавторизуемое действие.


Security-ограничения могут изменяться прямо на ходу. Во время проверки на возможность доступа всё было нормально, а в промежутке между ней и реальным доступом кислород — хлоп! — и перекрыли.
Re[12]: Переход на Java
От: MasterZiv СССР  
Дата: 03.03.09 15:52
Оценка:
rsn81 пишет:

> Не туда копаете. Заложенная логика в отнесение исключения к проверяемым

> или непроверяемым исключениям никак не связана с приведенной вами
> иерархии наследования. К примеру, Exception является проверяемым, а вот

Алло, гараж, у меня простой вопрос:

пишется ли

try
{
...
} catch (Exception e)
{
...
}

У вас в программах ?

Если да, то вы ловите также и RuntimeException.

Если нет, ну извините, вы (не вы rsn81 конкретно,
а все, кто не пишет) не умеете писать программы на языке
Java, либо это -- какие-то незначительные или учебные программы.
Posted via RSDN NNTP Server 2.1 beta
Re[13]: Переход на Java
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 03.03.09 18:52
Оценка:
Здравствуйте, MasterZiv, Вы писали:

MZ>Алло, гараж, у меня простой вопрос:

Я уже ответил на него выше, перечитайте внимательно, попробую 2 раз.

MZ>пишется ли

MZ>try
MZ>{
MZ>...
MZ>} catch (Exception e)
MZ>{
MZ>...
MZ>}
MZ>У вас в программах ?
Да, java.lang.Exception и его наследники (если при этом это не наследники java.lang.RuntimeException!) являются checked, соответственно, компилятор заставит написать обработчик.

MZ>Если да,

Ага, да!

MZ>то вы ловите также и RuntimeException.

А вот это нет, нет здесь никакой связи "если-то"!

MZ>Если нет, ну извините, вы (не вы rsn81 конкретно,

MZ>а все, кто не пишет) не умеете писать программы на языке
MZ>Java, либо это -- какие-то незначительные или учебные программы.
Re[11]: Переход на Java
От: Пацак Россия  
Дата: 03.03.09 20:36
Оценка:
Здравствуйте, MasterZiv, Вы писали:

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


В боевых — практически нет. И стараюсь его также не выбрасывать, используя вместо этого конкретных потомков.

// О том, что Exception — checked-исключение уже сказали, повторять не буду.

MZ>Любой APP -сервер, думаю, обязан оборачивать выполнения

MZ>всех запросов в try...catch.

Да, и сводится поимка RuntimeException в большинстве случаев, скорее всего, к все той же банальной матершине в лог. Не потому, что "java-программистам влом изучать такой удобный механизм", а просто из-за того, что довольно сложно на верхнем уровне предложить адекватную реакцию, скажем, на ситуацию "где-то внутри стэка вызовов что-то вышло за границы какого-то массива".
Ку...
Re[15]: Переход на Java
От: Пацак Россия  
Дата: 03.03.09 20:47
Оценка:
Здравствуйте, drol, Вы писали:

D>>>Вот SecurityException, например ?

R>>А что не так?

D>То что ловить надо по-месту.


Ну поймали, а что это даст? Наиболее разумное поведение, которое приходит на ум — определить причину облома и выбросить наверх соответствующее checked-исключение, чтоб вышестоящий метод смог решить, что ему делать дальше. Ну либо, если это возможно, проглотить исключение и тут же на месте обработать возникшую ситуацию. Как видно, что в том, что в другом случае необходимости пробрасывать RuntimeException наверх через иерархию вызовов не вырисовывается совершенно никакой.
Ку...
Re[16]: Переход на Java
От: drol  
Дата: 04.03.09 03:40
Оценка:
Здравствуйте, Пацак, Вы писали:

П>Ну поймали, а что это даст?


Дело не в "даст", а в том что SecurityException нуждается в обычной обработке, не такой как у прочих RuntimeException'ов, но "явно" этого не видно, бо не checked.
Re[17]: Переход на Java
От: rsn81 Россия http://rsn81.wordpress.com
Дата: 04.03.09 06:34
Оценка:
Здравствуйте, drol, Вы писали:

D>Дело не в "даст", а в том что SecurityException нуждается в обычной обработке, не такой как у прочих RuntimeException'ов, но "явно" этого не видно, бо не checked.

Почему нуждается-то?
Re[15]: Переход на Java
От: Пацак Россия  
Дата: 04.03.09 20:15
Оценка:
Здравствуйте, MasterZiv, Вы писали:

MZ>Господа, я устал вам объяснять очевидное.

MZ>Более этим заниматься не хочу.

И не надо — тебя уже давно прекрасно поняли. Ты пытаешься сказать, что раз RuntimeException — это потомок Exception, то все, кто ловит второе — автоматически ловят и первое. Да, чисто логически это действительно так. Но дело в том, что непосредственно Exception никто, как правило, не ловит. А все его checked-потомки (которых ловят) стоят уже на отдельной от RuntimeException ветке иерархии.
Ку...
Re: Переход на Java
От: AutumnLeaf Великобритания  
Дата: 06.03.09 10:55
Оценка:
Здравствуйте, opener, Вы писали:

O>Насколько сложно перейти на Java после С++? Проще/сложнее сама жаба по сравнению с С++? По моим нынешним представлениям вроде проще. И какого тогда хрена у жаба-программистов зарплаты больше?


Да, вот мне тоже интересно, какого хрена у программистов на brainfuck такие маленькие зарплаты?!

Вот интересно, у меня после чтения таких тем создается впечатление, что в то время как все программисты на Java спокойно делают свою работу и получают за это деньги, часть программистов на C++ ментально на него ... (вроде слово не совсем нецензурное, но мало ли) — может это говорит о какой-то их неудовлетворенности?
Re[2]: Переход на Java
От: MasterZiv СССР  
Дата: 06.03.09 16:31
Оценка:
AutumnLeaf пишет:

> получают за это деньги, часть программистов на C++ ментально на него ...

> (вроде слово не совсем нецензурное, но мало ли) — может это говорит о
> какой-то их неудовлетворенности?

AutumnLeaf, не судите по себе. Не обобщайте свои проблемы на других, в общем.
Posted via RSDN NNTP Server 2.1 beta
Re: Переход на Java
От: minorlogic Украина  
Дата: 06.03.09 18:22
Оценка:
Здравствуйте, opener, Вы писали:

O>Насколько сложно перейти на Java после С++? Проще/сложнее сама жаба по сравнению с С++? По моим нынешним представлениям вроде проще. И какого тогда хрена у жаба-программистов зарплаты больше?


Преход с С++ на жабу , никакой сложности не представляет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[3]: Переход на Java
От: AutumnLeaf Великобритания  
Дата: 08.03.09 12:28
Оценка:
Здравствуйте, MasterZiv, Вы писали:

MZ>AutumnLeaf, не судите по себе. Не обобщайте свои проблемы на других, в общем.


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

Так что, простите, ваша реплика мимо.
Re: Переход на Java
От: ArtemGorikov Австралия жж
Дата: 10.03.09 12:01
Оценка:
Здравствуйте, opener, Вы писали:

O>Насколько сложно перейти на Java после С++? Проще/сложнее сама жаба по сравнению с С++? По моим нынешним представлениям вроде проще. И какого тогда хрена у жаба-программистов зарплаты больше?


зарплаты у других программистов больше чем у тебя, скорее всего, из-за того что они просто делают свою работу, повышают квалификацию и все такое. Доход зависит от области применения и качества/скорости работы, от знаний наверно тоже.
P.S. Вообще я думаю ты тролль.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.