[dxp 50]

А если не видно разницы...(с) то нафиг этот билдер.

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

 

И вообще, нафиг этот билдер - глюкало еще то.

Ага, особенно, если учесть, что в основе обоих одна и та же оболочка и VCL. Одинаковое глюкало.

 

либо VS.

Не надоело еще сравнивать несравнимые вещи? Когда VS научится лепить графические апликухи тем же способом, что и билдер, тогда и сравним. Уж Qt в противовес билдеру приводили бы, что-ли. Это была бы тема.

 

Наврено сам придумал. Но копирайт поставить не могу - вдруг прочитал где.

Вот это похоже на правду.

 

Ок, а иначе кто наследник ?

Зачем ему наследник? Он сам живее всех живых?.. Кто у делфы наследник? Аналогия понятна?

 

Ну не сравнивайте шарп и оригинальную (не java#) жабу по быстродействию. Шарповский X-код ложится прямо на команды таргета, а джава (не java#)- все-таки интерпретатор. Так что если вы по эффективности одного делаете предположение о другом, то ошибаетесь. Шарп по эффективности ничуть не хуже, чем це++, а по остальным критериям, включая легкость разработки, так и гораздо лучше.

Ой, не надо этих песен/басен! Разберитесь сначала в вопросе как следует, потом подискутируем. Хинт: разработавшие и применяющие жабу с шарпом поди не глупее нас с вами, если бы все было бы так, как вы пишете, уже давно на AVR бы на шарпе код лепили. Только хде ж он? :08:

 

 

В Delphi 2009 шаблоны есть. http://www.codegear.com/article/38622/imag...oUpgradeRUS.pdf

Не прошло и тридцати лет. Еще осталось дождаться, пока в них глюки вычистят, научатся широко применять и появятся приемы типа описанных в "Modern C++ Design", а также делфовая STL. :)

[VCucumber 0]

Ага, особенно, если учесть, что в основе обоих одна и та же оболочка и VCL. Одинаковое глюкало.

Нет. Был опыт, причем не только мой, но целой команды. После замены билдера на дельфи число необъяснимых глюков снизилось на порядки.

 

Не надоело еще сравнивать несравнимые вещи? Когда VS научится лепить графические апликухи

Вы, вообще, VS когда-нибудь запускали ?

 

Зачем ему наследник? Он сам живее всех живых?.. Кто у делфы наследник? Аналогия понятна?

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

 

Ой, не надо этих песен/басен! Разберитесь сначала в вопросе как следует, потом подискутируем.

Ок, не буду спорить. Возможно и жаба компилиться в таргет, а не интерпретируется как Х-код. Просто я вижу жутко тормозные жабовые приложения и шарп, который летает в полный рост. А по поводу оптимизации, это на аргумент предыдущего оратора, так оно зависит не от языка вообще, а от конкретной реализации компилятора. Абсолютно одинаково с це.

 

Хинт: разработавшие и применяющие жабу с шарпом поди не глупее нас с вами, если бы все было бы так, как вы пишете, уже давно на AVR бы на шарпе код лепили.

Скоро уже, подождите чуток ) А для ARM, MIPS уже можно ; Но что-то я уже повторяюсь.

[ukpyr 0]

Забудьте об этом тупом неповоротливом языке

"поворотливость" программы зависитъ только от компилятора. язык тут ни при чем. но так сложилось что подавляющее большинство компиляторов для контроллеров - С/С++.

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

Изменено 29 ноября, 2008 пользователем ukpyr

[xvr 12]

Нет. Был опыт, причем не только мой, но целой команды. После замены билдера на дельфи число необъяснимых глюков снизилось на порядки.

Пишу на Builder'е начиная с 1й версии, необъяснимых глюков не встречал (объяснимые - встречал), может что то в 'команде' не так?

 

 

 

Во избежании обвинения в пристрастии к BCB, сразу говорю, что писал (и пишу) еще на VC, gcc, icc (x86 & Itanium), HiTech C.

[Kopa 0]

Во как! А for(;;){} чем не угодило?

 

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

в определённых ему рамках и пишется не задумываясь о его необходимости и

возможной негибкости при использовании.:) ( т.е. "зашоренное" мышление )

 

А если требуется некое другое использование ( например доступ к счётчику цикла вне

данного цикла), то это может превратится в маленький ньюанс в понимании.

 

P.S. Но это не только в Си проявляется. :beer:

[777777 0]

"поворотливость" программы зависитъ только от компилятора. язык тут ни при чем.

Неповоротливость, как и гибкость, зависят только от языка, но никак не от компилятора. Почему, например, для перевда буквы в нижний регистр нельзя просто установить бить 0x40, как в Си (c |= 0x40), а надо сначала получить код символа, выполнить с ним арифметическую операцию, а потом преобразовать опять в символ?

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

Вот например, недавно узнал, что оказывается внутри скобок begin-end нельзя объявлять локальные переменные. То есть, любая временная переменная, которая нужна на протяжении 3-4 строк, должна объявляться в начале функции и жить на всем ее протяжении. Да у меня в каждом цикле объявляются переменные а в конце цикла уничтожаются! А в паскале я должен позаботиться о них в начале функции, придумать им разные имена и т.д.?

 

А вообще, такие заявления (об эквивалентности Си и паскаля) могут делать только те, кто начинал с паскаля. Я начинал и Си, и когда пытался познакомиться с паскалем, меня просто бесило, что вещи, элементарные и очевидные в Си, обрастают в паскале кучей ограничений. Если вы начинали с паскаля, то эти ограничения вам объяснили сразу, поэтому переходя на Си вы даже не думаете о том, что что-то можно сделать проще и легче, потому что программируя на Си, вы продолжаете думать по-паскалевски, вы просто не знаете о том, что мир шире, что можно выйти из его дурацких ограничений, так же, как дальтоники не догадываются о том, что мир на самом деле ярче, чем они его видят.

Изменено 8 декабря, 2008 пользователем 777777

[Aesthete Animus 0]

Вот например, недавно узнал, что оказывается внутри скобок begin-end нельзя объявлять локальные переменные. То есть, любая временная переменная, которая нужна на протяжении 3-4 строк, должна объявляться в начале функции и жить на всем ее протяжении. Да у меня в каждом цикле объявляются переменные а в конце цикла уничтожаются! А в паскале я должен позаботиться о них в начале функции, придумать им разные имена и т.д.?

 

Тут Вы неправы, хотябы потому, что С89 тоже требует объявлять переменные в начале функции и это мало кого смущало.

[zltigo 1]

Тут Вы неправы, хотябы потому, что С89

89??? 1989 год. Сколько лет прошло, по этой причине не помню, но то, что еще в 80-х годах на единственном более-менее доступном тогда борлондячем компиляторе можно было ограничивать область видимости и соответственно объявлять переменные внутри функции, это точно.

...и это мало кого смущало.

Меня смущало-бы и даже очень.

[ukpyr 0]

Вот например, недавно узнал, что оказывается внутри скобок begin-end нельзя объявлять локальные переменные. То есть, любая временная переменная, которая нужна на протяжении 3-4 строк, должна объявляться в начале функции и жить на всем ее протяжении. Да у меня в каждом цикле объявляются переменные а в конце цикла уничтожаются! А в паскале я должен позаботиться о них в начале функции, придумать им разные имена и т.д.?

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

очему, например, для перевда буквы в нижний регистр нельзя просто установить бить 0x40, как в Си (c |= 0x40)

а кто запрещает компилятору скомпилировать выражение c = c or $40 как установку бита ? вроде не проблема ?

вон в avr-gcc сначала устанавливать/обнулять биты приходилось через костыли cbi/sbi, потом научились делать через |=, &=~ . так что реализация таких мелочей зависит только от компиляторописателей, проблема паскаля в том, что он распространен значительно меньше чем С, соответственно намного меньше качественных компиляторов.

Изменено 8 декабря, 2008 пользователем ukpyr

[Aesthete Animus 0]

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

Не путайте причину со следствием.

[zltigo 1]

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

Изумительно :( При этом она будет жить и сохраняться и МЕЖДУ использованиями а использование переменной с одним и тем-же именем для РАЗНЫХ целей отнюдь не добавляет удобства и безошибочности.

[tyro 0]

Изумительно :( При этом она будет жить и сохраняться и МЕЖДУ использованиями а использование переменной с одним и тем-же именем для РАЗНЫХ целей отнюдь не добавляет удобства и безошибочности.

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

[forever failure 0]

В стандарте Ц89 переменную можно объявлять в любом месте в начале блока, а не только в начале функции, в том числе анонимного блока, не связанного ни с каким оператором ветвления. Напр.:

void func (int c, char B)

{

int a;

a = b + c;

{

float f;

f = a + c;

}

}

 

По стандарту Ц99 переменную можно объявлять в любом месте, где допустима инструкция (как в Ц++).

[zltigo 1]

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

Вопрос в том, что есть реальные побудительные мотивы так "мудро" поступать или нет. А на мотивы уже язык свой отпечаток накладывает. Повторяю, именно реальные причины, а НЕ ВОЗМОЖНОСТЬ писать чего-либо через заднепроходное отверстие. В том-же "C" больше возможностей написать чего-либо через #@^#^%$ но МЕНЬШЕ ПРИЧИН это делать.

[777777 0]

В стандарте Ц89 переменную можно объявлять в любом месте в начале блока, а не только в начале функции, в том числе анонимного блока, не связанного ни с каким оператором ветвления. Напр.:

void func (int c, char B)
    {
    int a;
    a = b + c;
     {
     float f;
     f = a + c;
     }
    }

Сишники обычно пишут так:

void func (int c, char B)
    {
    int a = b + c;
       {
       float f = a + c;
       ...       
       }
    }

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