C vs. JVM's benchmark

>А вообще, автоматические утилиты для javascript сломает и стандартный примём document.getElementById("image_"+i);

Нет:) Посмотри на плугин скриптовый идеи. "фтупую" - сломает - но гдето есть аннотация что возвращает getElementById + варианты. Комплишен будет предложен из всех классов которые может вернуть getElementById - а их список ограничен. То есть - комплишен делается не только на остовании автоматических возможностей абстрактного распознавания - но и экспертных рекомендаций.

>И наличие eval-а сломает не только автокомплишен, но и автоматическое переименование, call hierarchy, дебаггер, измерение coverage...

Да жить вообще страшно. Что ж теперь в нотепаде писать "потому что бывают случаи"?

> 1. слушателями рефакторингов которые умеют хедлись специфику (например есть плугин для junit которы двигает и переименовывает TestCase к классу при переименовании того или другого) и понимают что вот в этом xml - ссылка на класс.

Не далее как в пятницу правил баг коллеги, удалившего пару public-методов из бина, т.к. call hierarchy у них был пустой. А то, что метод вызывается из jsp-шки, мудрый эклипс не прочухал. На такой случай "слушатель" найдётся?

> 2. статический анализ - clazz.getMethod("myMethod") - известная конструкция - так можно обработать рефлекшен

В какой момент оно споткнётся: clazz.getMethod("my"+"Method"), clazz.getMethod("my"+"Met"+"hod") или ещё какое-нибудь усложнение надо прикрутить?

> 3. поиск по строкам и распознавание как "очевиджных совпадений - полное квалифицированное имя) и возможных совпадений - и предложение пользователю.

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

Это умеет и grep.

> Это в любом случае _лучше_ чем ничего и это покрывает 95%. И это реализуемо вразумных пределах для всех этих языков кроме С где нужно писать макропроцессор.

В 95% случаев, даже grep+sed дадут хороший результат.

>> И наличие eval-а сломает не только автокомплишен, но и автоматическое переименование, call hierarchy, дебаггер, измерение coverage...

> Да жить вообще страшно. Что ж теперь в нотепаде писать "потому что бывают случаи"?

Просто не надо ставить eclipse выше vim-а, т.к. ни один не является панацеей.

>> А вообще, автоматические утилиты для javascript сломает и стандартный примём document.getElementById("image_"+i);

> Нет:) Посмотри на плугин скриптовый идеи. "фтупую" - сломает - но гдето есть аннотация что возвращает getElementById + варианты. Комплишен будет предложен из всех классов которые может вернуть getElementById - а их список ограничен. То есть - комплишен делается не только на остовании автоматических возможностей абстрактного распознавания - но и экспертных рекомендаций.

Ээээ, каким же умным должен быть плугин, чтобы понять, что теперь картинки называются не image_0, image_1, а pic_0, pic_1?

Или я опять что-то проспал, и ИИ уже прошёл тест Тьюринга? :)

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

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

В понятие "на начальном этапе" я бы внес и первые релизы. Или предложишь параллельно два бранча держать - на "более наглядном и гибком языке" и на "на более быстром и строгом".

>На такой случай "слушатель" найдётся?

Да. Возможно он убрал нужную галку (свободный поиск часто отключается чтобы переименовальщик не лазил и не переименовывал слова и тд). Идея - находит.

>В какой момент оно споткнётся: clazz.getMethod("my"+"Method"), clazz.getMethod("my"+"Met"+"hod") или ещё какое-нибудь усложнение надо прикрутить?

Ну естественно "бывают случаи". Что ж теперь локальные переменные не переименовывать?

>Это умеет и grep.

Не умеет. Идея обычно понимает контексты и существую очнь много плугов которые понимают контексты. Например в конфиге струтса или web.xml классы комплитиятся только внужных местах и при этом только подходящих типов.

>В 95% случаев, даже grep+sed дадут хороший результат.

Не дадут. Грпе и сед дадут только переименование - а не весь комплекс анализа кода и его эквивалентных трансформаций.

s/строгом"./строгом"?

>Просто не надо ставить eclipse выше vim-а, т.к. ни один не является панацеей.

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

>Ээээ, каким же умным должен быть плугин, чтобы понять

Я признаться подумал что ты про возвращаемое значение. Та ну и что? Вон идейный плугин на html даже помечает что размеры <img> не совпадают с тем что лежит в файле.

> Идея - находит.

Ну мы нищеброды, мы на эклипсе сидим :)

>> В какой момент оно споткнётся: clazz.getMethod("my"+"Method"), clazz.getMethod("my"+"Met"+"hod") или ещё какое-нибудь усложнение надо прикрутить?

> Ну естественно "бывают случаи". Что ж теперь локальные переменные не переименовывать?

Какие в моём примере с лямбдой переменные будут локальными?

>> В 95% случаев, даже grep+sed дадут хороший результат.

> Не дадут. Грпе и сед дадут только переименование - а не весь комплекс анализа кода и его эквивалентных трансформаций.

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

>> Ээээ, каким же умным должен быть плугин, чтобы понять

> Я признаться подумал что ты про возвращаемое значение. Та ну и что? Вон идейный плугин на html даже помечает что размеры <img> не совпадают с тем что лежит в файле.

Сравнить размеры img с размерами файла -- невелика задача. А вот выпарсить из кода место, где назначаются id-шники, место, где они используются, а потом их сопоставить -- задача нетривиальная.

> В понятие "на начальном этапе" я бы внес и первые релизы. Или предложишь параллельно два бранча держать - на "более наглядном и гибком языке" и на "на более быстром и строгом".

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

>Крон не парься - он не умеет - он на четвертом курсе пока не научился. Что толку обяснять реальный опыт студенту.

ЛОЛшто? Пастушок объелся шишек конопли?

>Какие в моём примере с лямбдой переменные будут локальными?

Я не совсем понял там суть твоего вопроса - ты имел ввиду комплишен для $w?

1. Анализатор мог бы его понять именно как код для tk и заведомо знать обект какого типа передается в лямбду - за счет экспертных настроек для tk.

2. Он мог бы предлагать все возможные варианты и сузивать их в последующих вызовах - после первого $w focus следующие предложения предлагать только для тех у кого есть focus. И тд.

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

>Где ты тут увидел слово десктоп? Я говорил о серверном приложении.

Не отмазывайся.

>Не отмазывайся.

Иди обед кушай - тебе уже мам пампушек с обрщем напекла.

> Я не совсем понял там суть твоего вопроса - ты имел ввиду комплишен для $w?

Да для чего угодно.

> 1. Анализатор мог бы его понять именно как код для tk и заведомо знать обект какого типа передается в лямбду - за счет экспертных настроек для tk.

Дело в том, что функция lambda оперделена мною же в соседнем файле. Мне придётся дописывать что-то в утилиту для работы с кодом, дабы научить её работать с моим кодом.

> 2. Он мог бы предлагать все возможные варианты и сузивать их в последующих вызовах - после первого $w focus следующие предложения предлагать только для тех у кого есть focus. И тд.

А как оперделить, у кого есть фокус, ежели все типы данных в тикле -- строка? Лучший вариант из тех, которые я видел -- вимовское дополнение тупо по содержимому файла, который угадывал знакомые слова.

>> В понятие "на начальном этапе" я бы внес и первые релизы. Или предложишь параллельно два бранча держать - на "более наглядном и гибком языке" и на "на более быстром и строгом".

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

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

>Иди обед кушай - тебе уже мам пампушек с обрщем напекла.

Пастушок марш работать. А то выгонят тебя с работы и поедешь обратно в свою кацапетовку быков доить.

>Дело в том, что функция lambda оперделена мною же в соседнем файле.

Это не важно - твоя функция подчиняется сигнатуре -command для tk - а эта сигнатура ему известна. Конкретная функция значения не имеет.

>А как оперделить, у кого есть фокус, ежели все типы данных в тикле -- строка?

Он может не обращать внимание на формальности:) - и понимать что в случае -command в tk - это функция с одним параметром widget. Даже, вероятно, понимать по тому типу у кого сеттится этот комманд какой тип аргумента ему придет.

То есть при наличии нескольких экспертных рекомендаций - все становиться не так гибло.

Посмотри хоть на zsh - там во весь рост использован этот подход.

Хотя я прочитал твою реализацию лямбды - конечно палок в коляса там такому анализатору - немеряно:)

> Лучший вариант из тех, которые я видел -- вимовское дополнение тупо по содержимому файла, который угадывал знакомые слова.

А DLTK ты смотрел?

>>Буду добивать тебя дальше )))) А я согласен, что Java имеет более убогие возможности для программирования, чем С. ;) только в больших приложениях это ПЛЮС ))) у нас к примеру 8 команд по 5-8 человек программистов + манагеры, админы и т.п - получаем примерно 60-80 девоФ. Понятно, что при таком количестве народу уровень у всех очень разный, и Чем меньше возможностей у дева написать мутную хрень тем лучше.

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

Так тем enterprise и живет. чтобы приложение можно было поддержать / развивать имея только средних разработчиков (конечно практика порочна, но какое то время проект еще протянет). В общем пришли к соглачию ))))

>и Чем меньше возможностей у дева написать мутную хрень тем лучше.
>Следующий пример: if(func1() && func2()) - будет ли вызвана func2()? >всегда ли? и можно ли гарантировать это поведение (любое однозначное >поведение)?
>VoDA


__М__Е__Г__А__ -удачный примерчик почему ява необходима индустрии как воздух!
Потому что нынешние програмеры - жопоголовые ахтунги типа VoDA ...

В примере выше всё однозначно и чистенько - но даже такое "проффи" не асиливают :( Хотя порассуждать на лоре о том чего там сегодня рип - считают себя в праве ....

>>Зато в Java определён результат (x++ + x++) :)
>>KRoN73 ***** (*) (07.07.2008 12:45:54)

>Да он в любом языке определён, на код-ревью будет написан комментарий >// TODO: Clean it
>Legioner


В фортунки! Немедленно! :)

>В принципе в текстовых литералах тоже можно автокомплит делать, но конечно не надёжный.

ИДЕЯ умеет в стринговых литералах автокомплит делать. Правда только для имен классов И если есть возможность по схеме XML дополнять. Но и это уже плюс )))

>> func2() будет вызвана всегда и только тогда, когда func1() вернёт не-ноль. > Согласен, неудачная формулировка:)

> Перефразирую:

> func2() будет вызвана всегда в случае, если func1() вернёт не-ноль.

Ок. вроде ранmit у борлонда был ключик который заставлял приложение вызывать все функции, даже если результат if уже известен. поскольку найти доку не смог и гугл не помог, то задача снимается ;)

Следующая задача: есть класс class A { A(); };

A::A() { }

>> func2() будет вызвана всегда и только тогда, когда func1() вернёт не-ноль. > Согласен, неудачная формулировка:)

> Перефразирую:

> func2() будет вызвана всегда в случае, если func1() вернёт не-ноль.

Ок. вроде ранmit у борлонда был ключик который заставлял приложение вызывать все функции, даже если результат if уже известен. поскольку найти доку не смог и гугл не помог, то задача снимается ;)

Следующая задача: есть класс class A { A(); };

A::A() { }

сколько у этого класса конструкторов?

Скучно, ей-богу. Это задачки после второй лекции по С++, если мне не изменяет память.

Лучше так:

void f(int *);
void f(double *);
template <typename T> void f(T);
template <typename T> void f(T*);
template <typename T> void f(const T&);

f(NULL);

Какая f вызовется?

>Какая f вызовется?

NULL я так понимаю определен как (void*)0 ?

Нет, просто 0

>Нет, просто 0

Тогда наверное он предположит что 0 - это int и инстанциирует шаблон f<T>() для T = int

дальше компилятора дело не пойдет.

>что 0 - это int и инстанциирует шаблон f<T>() для T = int

нет он предположит что 0 может быть 4мя разными человеками.

>>что 0 - это int и инстанциирует шаблон f<T>() для T = int

>нет он предположит что 0 может быть 4мя разными человеками.

В исходниках STL 0 типизируют зачем-то - (T*)0. Видимо, по дефолту 0 это int-литерал.

> В исходниках STL 0 типизируют зачем-то - (T*)0

За этим и типизируют - чтобы был "указатель на T".

> Видимо, по дефолту 0 это int-литерал.

По дефолту 0 преобразуем к любому указателю.

>> Видимо, по дефолту 0 это int-литерал.

>По дефолту 0 преобразуем к любому указателю.

А к T=int он может привести 0 вообще без кастинга.

А почему компилятор различает

void f(int*);

template<typename T> void f(T*);

?

>А почему компилятор различает

>void f(int*);

>template<typename T> void f(T*);

? Он как раз не может их различить в вызове f(0).

>А почему компилятор различает

>void f(int*);

>template<typename T> void f(T*);

Видимо по возможности используется специализированная а не обобщенная функция.

>>По дефолту 0 преобразуем к любому указателю.

>А к T=int он может привести 0 вообще без кастинга.

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

>>>По дефолту 0 преобразуем к любому указателю.

>>А к T=int он может привести 0 вообще без кастинга.

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

Маразм. Раз уж они были вынуждены добавить к ключевым словам bool, *_cast, explicit, mutable, то еще одно ключевое слово null/nil это совсем небольшая жертва.

BTW: Я изначально предполагал что код Легионера корректен и с ambiquity не вылетает.

> Маразм.

Ты известный любитель Си++

> Раз уж они были вынуждены добавить к ключевым словам bool, *_cast, explicit, mutable, то еще одно ключевое слово null/nil это совсем небольшая жертва.

Преобразование 0 в указатель было сделано гораздо раньше, чем bool и всё остальное.

>> Раз уж они были вынуждены добавить к ключевым словам bool, *_cast, explicit, mutable, то еще одно ключевое слово null/nil это совсем небольшая жертва.

>Преобразование 0 в указатель было сделано гораздо раньше, чем bool и всё остальное.

Оно унаследовано из Си. Ряд неявных конверсий допустимых в Си наподобие void* -> T* они все равно покоцали.

> Я изначально предполагал что код Легионера корректен и с ambiquity не вылетает.

Я тоже :D Правда, я не смог раскрутить вызов в голове, а компилятор ругнулся.

> Ряд неявных конверсий допустимых в Си наподобие void* -> T* они все равно покоцали.

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

>> Ряд неявных конверсий допустимых в Си наподобие void* -> T* они все равно покоцали.

>Это преобразование не всегда было допустимым. Точно помню, как старые досовские Си-компиляторы на него ругались.

Стандарт ANSI/ISO для плюсов был принят на ~10 лет позже чем ANSI/ISO С89. Afaik 98 год или ококло того.

1000 get