Здравствуйте, FR, Вы писали:

FR>Насколько я понимаю сейчас java это делает на порядок хуже чем нормальный программист вручную на C++.
Почему вы так думаете?

FR>Тем более на C++ все гарантированно а на java может быть разместит а может и нет, гарантий никаких.
Гарантий, конечно, никаких, ведь при условии динамической компиляции выделение памяти на куче может быть через некоторое время сконвертировано в выделение на стеке.

Здравствуйте, rsn81, Вы писали:

R>Здравствуйте, FR, Вы писали:
FR>>Тем более на C++ все гарантированно а на java может быть разместит а может и нет, гарантий никаких.
R>Гарантий, конечно, никаких, ведь при условии динамической компиляции выделение памяти на куче может быть через некоторое время сконвертировано в выделение на стеке.

Дак вопрос не в самом месте размещения объектов, а в гарантиях налагаемых на принимаемые условия. Примером слабости таких в JVM и .Net может служить ветка в немерловом форуме про notnullable ссылки, которые там (в Н) нельзя получить из-за модели самой платформы (дотнета).

Здравствуйте, rsn81, Вы писали:

R>Здравствуйте, FR, Вы писали:

FR>>Насколько я понимаю сейчас java это делает на порядок хуже чем нормальный программист вручную на C++.
R>Почему вы так думаете?

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

FR>>Тем более на C++ все гарантированно а на java может быть разместит а может и нет, гарантий никаких.
R>Гарантий, конечно, никаких, ведь при условии динамической компиляции выделение памяти на куче может быть через некоторое время сконвертировано в выделение на стеке.

Угу а на C++ железно будет на стеке и будет и шустрее и надежнее (относительно NULL и освобождения ресурсов).

Здравствуйте, eao197, Вы писали:

E>

E>class Demo {
E>    static public void main( String[] args )
E>    {
E>        StringBuffer buf = findAppropriateBuffer();
E>        for( int i = 0; i != args.length; ++i )
E>            buf.append( args[ i ] );
E>        System.out.println( buf );
E>    }

E>    static private StringBuffer findAppropriateBuffer()
E>    {
E>        return null;
E>    }
E>}
E>

И что? buf явно проинициализирован. Тот, кто не прочитал спецификацию на возвращаемое значение — сам дурак.
Этот код точно так-же пишется на С/С++, только он выкинет не exception, а core dump.

E>ЗЫ Теперь понятно, почему тебе SymADE&SOP так понравился... ты просто не писал никогда сложных программ, не участвовал в сложных проектах.

В SymADE для отслеживания нулевых указателей и гарантии, что не будет NullPointerException нужно всего-то написать плагин к компилятору, что делается одним человеком за пару месяцев (и наверняка будет написан уже до того, как большинству он понадобится). В Java для этого нужно менять синтаксис языка (JSR-308), и переписывать все средства программирования, от javac до Eclipse. Это займёт несколько лет минимум, и будет сделано не так, как нужно для конкретных проектов — как и произошло с assert, enum, generic types.

Здравствуйте, FR, Вы писали:

FR>Угу, имеет значение совсем другое. Насколько я понимаю в java любому объекту можно присвоить null. В С++ нет. И соответственно число ошибок обращения по нулевому указателю должно быть меньше. Ну и тот же RAII над которым так любят посмеятся поклоники манджед сред тоже имеет значение.

Объекту вообще нельзя присвоить null. Его можно присвоить только ссылке на объект. Точно так-же, как в C++.

Здравствуйте, rsn81, Вы писали:

R>Здравствуйте, FR, Вы писали:

FR>>Насколько я понимаю сейчас java это делает на порядок хуже чем нормальный программист вручную на C++.
R>Почему вы так думаете?

Потому, что в java нельзя передать ссылку на объект в стеке в хип или другой тред. А в C++ можно. То есть C++ может больше.

Здравствуйте, mkizub, Вы писали:

M>Объекту вообще нельзя присвоить null. Его можно присвоить только ссылке на объект. Точно так-же, как в C++.

В С++ ссылке присвоить NULL без хаков затруднительно
Но дело не в этом а в том что в C++ есть не только ссылочные объекты.

Здравствуйте, FR, Вы писали:

M>>Объекту вообще нельзя присвоить null. Его можно присвоить только ссылке на объект. Точно так-же, как в C++.

FR>В С++ ссылке присвоить NULL без хаков затруднительно

Не путай, то, что слова одинаковые, не означает одинакового смысла. В яве ссылка соответствует C-шному указателю.

FR>Но дело не в этом а в том что в C++ есть не только ссылочные объекты.

На автоматических переменных это никак не сказывается. Все локальные переменные должны быть проинициализированы, а проинициализированы ссылкой на объект в хипе, или созданы на стеке — имеет отношение только к скорости работы (кстати, аллокатор в нынешних явах — для каждого треда отдельный, и в виду heap compaction, затраты на него не превышают пары инструкций процессора).
Большее количество проблем с null в чём-то другом. Может в том, что все объекты наследуются от одного класса, или ещё в чём-то, но не в автоматических переменных — с ними контроль более жёсткий, чем в C++.

Здравствуйте, mkizub, Вы писали:

M>И что? buf явно проинициализирован. Тот, кто не прочитал спецификацию на возвращаемое значение — сам дурак.
M>Этот код точно так-же пишется на С/С++, только он выкинет не exception, а core dump.

Подучили бы C++ прежде чем такие заявления делать. В C++ можно возвращать объекты по значению. В этом случае NULL объекту вообще нельзя будет присвоить.

А в Java -- пожалуйста. И шибко умный компилятор Java может только проверить, что переменная-ссылка получила значение, но какое это значение компилятор Java понять уже не может. А вот компилятор Nice -- может.

Кроме того, это пример явно демонстрирует некорректность вашего категоричного утверждения:

Ошибки NullPointerException возникают исключительно по причине передачи null в качестве аргумента метода, и null ссылки в полях классов.

Здравствуйте, mkizub, Вы писали:

M>Большее количество проблем с null в чём-то другом. Может в том, что все объекты наследуются от одного класса, или ещё в чём-то, но не в автоматических переменных — с ними контроль более жёсткий, чем в C++.

А как объяснить тот факт, что способ создания объектов в Delphi похож на то, что в Java, и там тоже большое кол-во проблем с null (nil)?
И как влияет на это общий базовый класс?

Здравствуйте, Стэн, Вы писали:

С>А как объяснить тот факт, что способ создания объектов в Delphi похож на то, что в Java, и там тоже большое кол-во проблем с null (nil)?

Да, что-то общее есть. И другая закономерность есть — практически все люди, евшие огурцы — уже померли или вскоре помрут. Тоже загадка...

С>И как влияет на это общий базовый класс?

Это мне так почудилось. После дальнейших размышлений — от этой идеи я отказался. Появилась другая — в С++ нет (небыло долгое время, и сейчас нет, если выключить RTTI) безопасного способа upcasting-а, легче определение и код для невиртуальных методов — как результат, в нём меньше шаманят с полиморфизмом, используют другие приёмы проектирования. А полиморфизм через ссылки/указатели и может быть только реализован, то есть сама структура языка меньше располагает к использованию указателей вообще, и как следствие — NULL в частности.

Здравствуйте, mkizub, Вы писали:

[]

M>Это мне так почудилось. После дальнейших размышлений — от этой идеи я отказался. Появилась другая — в С++ нет (небыло долгое время, и сейчас нет, если выключить RTTI) безопасного способа upcasting-а, легче определение и код для невиртуальных методов — как результат, в нём меньше шаманят с полиморфизмом, используют другие приёмы проектирования. А полиморфизм через ссылки/указатели и может быть только реализован, то есть сама структура языка меньше располагает к использованию указателей вообще, и как следствие — NULL в частности.

Прости, но ты пишешь ерунду.

пс: полиморфизм использую чуть-ли не на каждом шагу, но вот upcasting'а нету нигде (за исключением комовского QI).

Здравствуйте, EvilChild, Вы писали:

EC>Здравствуйте, MatFiz, Вы писали:

EC>С какого перепугу из качественности кода следует его unmaintainability?
EC>Maintainability как раз главный показатель качества.
EC>Оно перпендикулярно усилиям потраченным на написание.

Элементарная логика. Следи за руками.
Maintainable ==> качественный
тогда
Некачественный ==> Unmaintailable.

Здравствуйте, MatFiz, Вы писали:

MF>Maintainable ==> качественный
MF>тогда
MF>Некачественный ==> Unmaintailable.
Это твоё сообщение противоречит твоему предыдущему.
Я именно это и утверждал.

Здравствуйте, EvilChild, Вы писали:

EC>Здравствуйте, MatFiz, Вы писали:

MF>>Maintainable ==> качественный
MF>>тогда
MF>>Некачественный ==> Unmaintailable.
EC>Это твоё сообщение противоречит твоему предыдущему.
EC>Я именно это и утверждал.

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

Здравствуйте, eao197, Вы писали:

FR>>>Нифига списки вполне сопоставимые http://www.digitalmars.com/d/changelog.html и по ICE тоже. Похоже на самом деле ошибки больше зависят от квалификации пишущих а не от используемого языка.
K>>Надо учитывать, что компиляторы Scala и D по сложности, мягко говоря, сильно отличаются.

E>Ой-ли.

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

Здравствуйте, Klapaucius, Вы писали:

FR>>>>Нифига списки вполне сопоставимые http://www.digitalmars.com/d/changelog.html и по ICE тоже. Похоже на самом деле ошибки больше зависят от квалификации пишущих а не от используемого языка.
K>>>Надо учитывать, что компиляторы Scala и D по сложности, мягко говоря, сильно отличаются.

E>>Ой-ли.

K>Т.е. это не надо учитывать? Вы утверждаете, что можно сравнивать языки по багтрекерам двух разных проектов, которые писали разные люди, разное время и на разных языках? Методикой не поделитесь, очень интересно.

Мое "ой-ли" относилось к вашему утверждению о том, что сложность компиляторов Scala и D слишком различаются. По моему мнению, D вовсе не проще Scala, скорее наоборот. Соответственно, и сложность компиляторов Scala и D не слишком различаются.

К тому же багтрекер, как ни крути, очень объективный показатель качества программного продукта (ну или разработчиков). Более объективный, может быть, чем мифические человеко-месяцы или KLOC-и.

Здравствуйте, mkizub, Вы писали:

M> Появилась другая — в С++ нет (небыло долгое время, и сейчас нет, если выключить RTTI) безопасного способа upcasting-а, легче определение и код для невиртуальных методов — как результат, в нём меньше шаманят с полиморфизмом, используют другие приёмы проектирования.

Не понимаю логики , как связан upcasting с использованием полиморфизма? Вообщет хороший стиль подразумевает минимизацию upcasting?

Здравствуйте, minorlogic, Вы писали:

M>Не понимаю логики , как связан upcasting с использованием полиморфизма?

Ты вынужден искать такие алгоритмы, так проектировать программу, чтоб тип данных был известен во время компиляции точно. Как следствие, тебе нужно меньше ссылок (потому как через ссылки полиморфизм и реализуется), и получается меньше null-евых ошибок.

M>Вообщет хороший стиль подразумевает минимизацию upcasting?

В C++ — наверняка.

ЗЫ В любом случае, это просто предположение.

E>К тому же багтрекер, как ни крути, очень объективный показатель качества программного продукта (ну или разработчиков). Более объективный, может быть, чем мифические человеко-месяцы или KLOC-и.

Не сказал бы что слишком обьективный. Но есть определённая корреляция — как правило, чем БОЛЬШЕ записей в багтреккере (всех вместе — открытых и закрытых), тем ВЫШЕ качество программного продукта.