Re:

Хуже того, когда административные проблемы (а именно, невнимание архитектора/PM'а к тому, что творят его подчиненные, и плохую формулировку задач) пытаются решать техническими средствами (ограничением средств выполнения задач этими самыми подчиненными), то все равно говно получается на выходе. Даже если запретить перегрузки операторов, наложить в _языке_ строгие ограничения на naming conventions, количество и длину методов в одном классе итп.

"Если техники в состоянии сломать что-либо, они это сломают", как было написано ~50 лет назад :-).

> А теперь-ка попробуй не jad-ом, а javap

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

public class B1
{
    public static String m(int ai[])
    {
        StringBuilder s = new StringBuilder();

        for(int i = 0; i < ai.length; i++)
            s.append(ai[i]).append(":");

        return s.toString();
    }

    public static void main(String args[])
    {
        int ai[] = {
            1, 2, 3
        };
        System.out.println(m(ai));
    }
}

Ну что же, ждём 1.5.1! :)))

>нужно понимать философию этого языка и нужно мыслить в терминах Java.

У джавы нет философии. И нет никаких особо выдающихся из общего болота "терминов" .

> 6. Кидать эксепшн - дорогое удовольствие.

Если Excpetion Дорогое удовольствие - ты выбрал совсем не ту платформу.

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

Оппа...  Приехали в Хопёр...
А это что? (особое внимание на последний пункт.)

"A member (class, interface, field, or method) of a reference (class,
interface, or array) type or a constructor of a class type is
accessible only if the type is accessible and the member or
constructor is declared to permit access:

   * If the member or constructor is declared public, then access is
     permitted. All members of interfaces are implicitly public.
   * Otherwise, if the member or constructor is declared protected,
     then access is permitted only when one of the following is true:
        + Access to the member or constructor occurs from within the
          package containing the class in which the protected member
          or constructor is declared.
        + Access is correct as described in §6.6.2.
   * Otherwise, if the member or constructor is declared private,
     then access is permitted if and only if it occurs within the
     body of the top level class (§7.6) that encloses the declaration
     of the member.
   * Otherwise, we say there is default access, which is permitted
     only when the access occurs from within the package in which the
     type is declared."

>> У джавы нет философии.

Философия жабы - это философия разработчиков, для которых признак крутости - это системный подход, архитектура и дизайн приложения, а не количество хаков, в нём использованных. Только красноглазым студентам этой философии всё равно не понять. Ну и хер на них - пусть себе очередной 1001 по счёту Х-йВМ на C с ассемблером пишут.

Вот это уже интересно (с другой машины под оффтопиком):

    public static string m(int[] ai)
    {

        string s = "";

        for ( int i = 0; i < ai.Length; i++ ) 
        {
           s += ai[i] + ":";
        }

        return s;
    }


.method public hidebysig static string  m(int32[] ai) cil managed
{
  // Code size       42 (0x2a)
  .maxstack  3
  .locals init (string V_0,
           int32 V_1)
  IL_0000:  ldstr      ""
  IL_0005:  stloc.0
  IL_0006:  ldc.i4.0
  IL_0007:  stloc.1
  IL_0008:  br.s       IL_0022
  IL_000a:  ldloc.0
  IL_000b:  ldarg.0
  IL_000c:  ldloc.1
  IL_000d:  ldelem.i4
  IL_000e:  box        [mscorlib]System.Int32
  IL_0013:  ldstr      ":"
  IL_0018:  call       string [mscorlib]System.String::Concat(object,
                                                              object,
                                                              object)
  IL_001d:  stloc.0
  IL_001e:  ldloc.1
  IL_001f:  ldc.i4.1
  IL_0020:  add
  IL_0021:  stloc.1
  IL_0022:  ldloc.1
  IL_0023:  ldarg.0
  IL_0024:  ldlen
  IL_0025:  conv.i4
  IL_0026:  blt.s      IL_000a
  IL_0028:  ldloc.0
  IL_0029:  ret
} // end of method B2::m

++++++++++++++++++++++

    public static String m(int[] ai)
    {

        String s = "";

        for ( int i = 0; i < ai.length; i++ ) 
        {
           s += ai[i] + ":";
        }

        return s;
    }

.method public hidebysig static string  m(int32[] ai) cil managed
{
  // Code size       71 (0x47)
  .maxstack  4
  .locals init (string V_0,
           int32 V_1)
  IL_0000:  ldstr      ""
  IL_0005:  stloc.0
  IL_0006:  ldc.i4.0
  IL_0007:  stloc.1
  IL_0008:  br.s       IL_0040
  IL_000a:  newobj     instance void [vjslib]java.lang.StringBuffer::.ctor()
  IL_000f:  ldloc.0
  IL_0010:  callvirt   instance class [vjslib]java.lang.StringBuffer [vjslib]java.lang.StringBuffer::append(string)
  IL_0015:  newobj     instance void [vjslib]java.lang.StringBuffer::.ctor()
  IL_001a:  ldarg.0
  IL_001b:  ldloc.1
  IL_001c:  ldelem.i4
  IL_001d:  callvirt   instance class [vjslib]java.lang.StringBuffer [vjslib]java.lang.StringBuffer::append(int32)
  IL_0022:  ldstr      ":"
  IL_0027:  callvirt   instance class [vjslib]java.lang.StringBuffer [vjslib]java.lang.StringBuffer::append(string)
  IL_002c:  callvirt   instance string [vjslib]java.lang.StringBuffer::ToString()
  IL_0031:  callvirt   instance class [vjslib]java.lang.StringBuffer [vjslib]java.lang.StringBuffer::append(string)
  IL_0036:  callvirt   instance string [vjslib]java.lang.StringBuffer::ToString()
  IL_003b:  stloc.0
  IL_003c:  ldloc.1
  IL_003d:  ldc.i4.1
  IL_003e:  add
  IL_003f:  stloc.1
  IL_0040:  ldloc.1
  IL_0041:  ldarg.0
  IL_0042:  ldlen
  IL_0043:  blt.s      IL_000a
  IL_0045:  ldloc.0
  IL_0046:  ret
} // end of method B::m

Интересно...

>Видимо, подразумевались Ваши мозги? Ну, дык, давайте, благо, недалеко, >приезжайте, позаимствую две-три ложки, применю куда-нибудь. Если >наскребу, конечно.

и давно вы стрелочником работаете ?

>Если бы вы назвали функцию не TryParse, а, скажем, ExtractInteger >(аналогичную strtol), с возвратом, к примеру, кроме результата еще и >позиции символа, который уже не относится к "числу", вопросов было бы, >пожалуй, меньше. А так и правда получается что в 95% случаев лучше >использовать эксепшн, даже несмотря на то, что это дороже по накладным >расходам.

:lol: И как же эксепшен "тормозит" работу ? хотелось бы услышать ???

> Если бы вы назвали функцию не TryParse, а, скажем, ExtractInteger (аналогичную strtol), с возвратом, к примеру, кроме результата еще и позиции символа, который уже не относится к "числу", вопросов было бы, пожалуй, меньше.

Тогда был бы другой ответ: возвращать объект с атрибутами - строкой и позицией.

> Пакеджы не устраивают тем, что нельзя объявить область видимости метода пакеджем. Либо private, либо protected, либо private.

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

По идее, поиск обработчика исключения занимает некоторое время.

Рекомендую почитать-таки, как работают эксепшны (да хоть бы и в яве) и перестать гнать волну. Если не хватает базового образования, то рекомендую какие-либо компьютерные факультеты популярных в Нске вузов. Если же времени учиться нет, попробуйте написать пару бенчмарков.

Признак крутости - это системный подход, архитектура и дизайн приложения

Какая может быть на яве архитектура, если там нельзя свой распределитель памяти и интеллектуальный указатель создать? ;)

Ну, собственно, именно про это я и написал в самом начале :-): приходится на ровном месте городить классы, единственным предназначением которых является объединение орла и трепетной лани, а кое-где, н-р, в J2ME это явно не поощряется :-).

Плюс к тому, очевидно, что добавляется работы гарбэдж коллектору.

"Старые валенки дворника стояли в углу и воздух тоже не озонировали".

Конечно, в статически типизируемых языках, в особенности, с нормальным JIT- или вообще AOT-компиляцией в этом месте все обстоит не настолько плохо, как, например, в питоне (без обвязок в виде Psyco и всяких прочих vapourware типа Starkiller'а), но все равно работы достаточно (создание и инициализация объекта для эксепшна, корректное отматывание стэк-фрэймов, поиск обработчика, удаление объекта для эксепшна)

А что, gc никак подрюкать не удается разве?

> интеллектуальный указатель создать

В смысле "smart pointer"? Тогда стройными рядами к дядюшке Билли!

Тогда стройными рядами к дядюшке Билли!

Это еще почему?

Даже уже посследователи дядюшки Билли отказались от умных указателей, ибо MFC и COM сузили свою нишу. Только тот, кто никогда не работал в серьёзных прикладных проектах, а пишет свой очень нужный 10001-ый манагер окошек just for fun, думает, что можно всё написать на С/C++. Ron прав.

И особенно нужный и полезный продукт это KOffice.

Тогда стройными рядами к дядюшке Билли!

Ага, объясни мне pls каким-таким боком связаны умные указатели и MFC? А насчет COM - если ты не в курсе, то умные указатели и подсчет ссылок - вещи разного уровня - очень не удобно делать второе, не имея первого. Правда многим моим знакомым ява программистам этим приходится постоянно заниматься - Init / Release писать вручную и думать какого черта этот модуль не деинициализировался, а висит где-то в сборщике мусора? Тут поневоле о дизайне и архитектуре задумаешься...
Вообще же, за умными указателями стоит очень важная и полезная для любой архитектуры идиома proxy. Кстати, возможности ее реализации в C++ мне тоже не особенно нравятся. Но это все же лучуше, чем ничего...

> модуль не деинициализировался

Значит так хорошо пишут.

> А насчет COM - если ты не в курсе, то умные указатели и подсчет ссылок - вещи разного уровня - очень не удобно делать второе, не имея первого

Учи матчасть:

"...allows you to create "smart pointer" classes that encapsulate pointers and override pointer operators to add new functionality to pointer operations. Templates allow you to create generic wrappers to encapsulate pointers of almost any type.

The following code outlines a simple reference count garbage collector. The template class Ptr<T> implements a garbage collecting pointer to any class derived from RefCount..."

Тебе сказать откуда это? :)

Идиома прокси

А что мешает на жабе использовать идиому прокси? Говоря по-правде, лично мне ближе и роднее С++, хотя бы потому, что у меня с ним много больший опыт работы, чем с жабой, но, с другой стороны, жаба, как раз тем, имхо, и приятна, что позволяет использовать все фкусности и фишки ОО-дизайна не заморачиваясь на всяких мелочах, типа в каком месте delete поставить, передавать ли объект указателем, ссылкой или по значению и ещё куче других. Жаба в этом плане намного более pure ОО язык чем С++.

Тогда стройными рядами к дядюшке Билли!

>Значит так хорошо пишут
Значит - это общая проблема.

>Тебе сказать откуда это? :)
Я знаю, только не понял связь этого с COM или MFC
Для тебя повторю еще раз - умные указатели и подсчет ссылок - это не одно и то же, второе удобно реализовывать, используя первое. Но только подсчетом ссылок умные указатели далеко не ограничиваются...

Тогда стройными рядами к дядюшке Билли!

>А что мешает на жабе использовать идиому прокси?
Хорошо, напишите аналог прозрачного счетчика ссылок на яве.

>C другой стороны, жаба, как раз тем, имхо, и приятна, что позволяет использовать все фкусности и фишки ОО-дизайна не заморачиваясь на всяких мелочах, типа в каком месте delete поставить, передавать ли объект указателем, ссылкой или по значению и ещё куче других.

Может я неправильно понимаю слово "архитектура", но, по моему, то что Вы описали, как раз к ней и относится :) Архитектура, в моем понимании, - это то, что позволяет приложению соответствовать не только функциональным, но и нефункциональным требованиям (типа требуемых ресурсов, скорости работы или расширяемости). Да у явы удачная архитектура для определенного класса задач, но изменить ее или создать новую Вам будет очень тяжело...

> Значит - это общая проблема.

Для кого общая проблема-то? Для тех кто не умеет проектировать?

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

Так откуда всё-таки цитата была?

> Да у явы удачная архитектура для определенного класса задач

100% согласен. Java служит для задач middleware.

> но изменить ее или создать новую Вам будет очень тяжело...

А зачем? Открою страшную тайну. Некоторые задачи лучше решаются на php, особенно весело смотрятся http://www.netbeans.info/downloads/download.php?type=beta2&p=1 и http://eclipse.org/downloads/index.php.

Цитата была, естественно, из M$DN. При этом в Managed Exts это сделано более просто для кодировщика.

Тогда стройными рядами к дядюшке Билли!

>Для кого общая проблема-то? Для тех кто не умеет проектировать?
Проектируй - не проектируй, но от ошибки никто не застрахован и чем меньше явных вызовов Init / Release, тем лучше. Просто смешно, с одной стороны говорить - как хорошо, что есть сборщик мусора, который защищает от дурацких ошибок, а с другой, чуть в сторону от генеральной линии партии отойдешь - "умей проектировать". Для сведения, у меня на C++ уже несколько лет не было утечек памяти (но сборщик мусора все-равно не помешал бы:)

>Так откуда всё-таки цитата была?
Visual C++ Programmer's Guide, угадал?

> Для кого общая проблема-то? Для тех кто не умеет проектировать?

Для них - не проблема. А вот остальные таки могут заметить, что гамак всё же раскачивается и ласты где-то неудобны.

> Visual C++ Programmer's Guide, угадал?

Угадали.:) Правда сейчас они всё на контролируемые расширения пытаются народ с джавы перетянуть. COM (COM+) и MFC они, судя по всему, перевели на подчинённые роли. Ну а про то что есть до сих пор support MFC в ATL, которая non-Attributed & DLL посмотрите сами, ибо это оффтопик здесь, это Linux сайт и Java топик.

> Хорошо, напишите аналог прозрачного счетчика ссылок на яве. НЕФИГ ЭТО НУЖНО?

see java.lang.reflect.Proxy

> Проектируй - не проектируй, но от ошибки никто не застрахован и чем меньше явных вызовов Init / Release

Если у вас проблемы сопряжения с мудацкой платформой - то это ваши проблемы и мудачкой платформы а не Java.

Тогда стройными рядами к дядюшке Билли!

>НЕФИГ ЭТО НУЖНО?
Как обычно - нет, значит и не нужно

Тогда стройными рядами к дядюшке Билли!

>Если у вас проблемы сопряжения с мудацкой платформой - то это ваши проблемы и мудачкой платформы а не Java.

Я думаю, что не все же работают со сферическим конем в вакууме...

Зачем переписывать java.lang.reflect.Proxy? Почитайте статью некого господина Jeremy Blosser'а на JavaWorld и увидите небольшой, но качественный пример. Позвольте, вы просто поставьте себе джаву и посмотрите. Времени это у вас займёт немного, а зато знать вы её будете не по наслышке.

Тогда стройными рядами к дядюшке Билли!

>Зачем переписывать java.lang.reflect.Proxy?

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

>Времени это у вас займёт немного, а зато знать вы её будете не по наслышке

Вот еще - бином Ньютона нашли :)

Щёччик сцылок для жабы

Нет, а правда, для чего в приложении на жабе может понадобицца щёччик сцылок?

Для чего в приложении на жабе может понадобицца щёччик сцылок?

Есть некий важный ресурс, типа COM-порта, который надо осободить как только ни одному клиенту он не нужен, но использовать его могут сразу несколько клиентов. Как только, ни одного клиента не осталось, ресурс надо как можно быстрее закрыть. Вот и приходится писать Init / Release или Advise / Unadvise.

>Рекомендую почитать-таки, как работают эксепшны (да хоть бы и в яве) и >перестать гнать волну. Если не хватает базового образования, то >рекомендую какие-либо компьютерные факультеты популярных в Нске вузов. >Если же времени учиться нет, попробуйте написать пару бенчмарков.

Продолжаю угарать :lol: ... мега умный наш java или хрен знает какое ещё программер, примени к себе свой мега пост и напиши пару бенчей. Лично нам обнаружить разумное отклонение по времени не удалось, может ты обнаружишь :lol: и не надо мне Нскими вузами тыкать, я сам в НГУ 6 лет откалбасил. На с++ gcc умеет оптимизировать "при которой влияние наличия исключений на быстродействие сведено, фактически к 0". На Java не много больше, но даже с учётом линейного по длине наследовая java type преобразования mc-ы у нас совпадали. Тебе череп не жмёт ???

>Есть некий важный ресурс, типа COM-порта, который надо осободить как >только ни одному клиенту он не нужен, но использовать его могут сразу >несколько клиентов. Как только, ни одного клиента не осталось, ресурс >надо как можно быстрее закрыть. Вот и приходится писать Init / Release >или Advise / Unadvise.

И эти люди плюют на жабу :lol: вы бы хоть книгу открыли что ли ?

когда на наш объект ком порта не останется ни одной ссылки им сильно заинтересуется gc и позовёт метод finalize у этого объекта в котором можно сплясать ваши ритуальные пляски по поводу смерти этого объекта. protected void finalize() { try { file.close(); } catch (Exception e) { } } Это написанно в любом учебнике на java.

В общем, как я понял, на жабу плюётся тот, кто с ней либо не знаком вообще (или знаком с ней по обсуждению с приятелями C# программерами), либо на начальной стадии её изучения и ему горесно жалко об отсутствии некоторох опасных с++ плюшек.

Для чего в приложении на жабе может понадобицца щёччик сцылок?

>когда на наш объект ком порта не останется ни одной ссылки им сильно заинтересуется gc
Во-во. Как я и подозревал настоящие ява-программеры даже не задумываются о таких вещах. Вопрос в том, как быстро он им заинтересуется? Какие будут мнения?

Ну, в такой ситуации ничего не поделаешь. Это обратная сторона сборшика мусара - если надо точно управлять временем освобождения ресурса, то надо делать явный метод его освобождения - на деструктор полагацца в этом не получаецца. С другой стороны, сильно ли напрягает необходимость явно вызывать метод освобождения ресурса в нужный момент в жабе по сравнению с необходимостью внимательно следить, что объект удаляецца в нужный момент в С++ ?

> когда на наш объект ком порта не останется ни одной ссылки им сильно заинтересуется gc и позовёт метод finalize у этого объекта в котором можно сплясать ваши ритуальные пляски по поводу смерти этого объекта. protected void finalize() { try { file.close(); } catch (Exception e) { } }

Именно тогда? lol

> Это написанно в любом учебнике на java.

Выкинь такой учебник.

"Чисто не там, где часто убирают, а где не мусорят." (с)

Для чего в приложении на жабе может понадобицца щёччик сцылок?

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

Да, нет идеала, к сожалению
Если бы в C++ была нормальная рефлексия, т.е. возможность итерировать члены класса в compile time (как это делают конструкторы и деструкторы), то можно было написать сборщик мусора для отдельных классов общим образом (это и сейчас возможно, просто необходимо писать код итерирования ручками). А в остальных использовать подсчет ссылок или обычное размещение / освобождение. Вот это было бы здорово :)

>Во-во. Как я и подозревал настоящие ява-программеры даже не >задумываются о таких вещах. Вопрос в том, как быстро он им >заинтересуется? Какие будут мнения?

Когда захожешь - System.gc();

finalize завётся перед смертью объекта из gc. И где ты меня захотел подъебать ?

и что из-под анонимной маски ???

> Когда захожешь - System.gc();

Здорово, продолжай в том же духе - Петросяном станешь. Извини, что сразу не въехал.

Для чего в приложении на жабе может понадобицца щёччик сцылок?

Вдогонку:

>Это обратная сторона сборшика мусара - если надо точно управлять временем освобождения ресурса

Не только временем, но и порядком. Предположим, у меня есть
class B;
class A { protected B b; };

И в деструкторе / finalize A мне надо иметь валидный b. Как я понимаю, сборщик мусора этого мне гарантировать не может. Согласитесь, что такая ситуация достаточно реалистична, особенно в сложных проектах?