gear nuke wrote:
> R>Зачем JIT?
>
> Чтобы определить в runtime характеристики кэша и прочего и сгенерировать
> оптимальный код на лету.
Тогда лучше сразу не мелочиться и не суетиться при оптимизации. Ну Вы
поняли, о чём я. Впрочем, если система команд разумна, то управление
кеш-памятью может идти хоть в ран-тайме — всё равно ускорение доступа к
главным данным окупит всё. Главное, чтобы она была.

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

GZ>Да уж. Действительно сильно искуственный пример.
GZ>strok — злобная функция, так как она использует static данные на уровне CRT.

Хуже. Она использует __declspec(thread). Иначе, сам подумай, что будет, если ее начнут из разных потоков вызывать


>И соответсвенно, два выполнения strtok — прямой путь к нетрадиционному сексу. Лучше всего вообще забыть о ее существовании.

Вообще да. Я свою писал

GZ>Именно. А если у кого-то была ссылка на строку, то тебе надо делать копии. Но чаще придется делать копии, из-за того что ты не можешь предположить, будет строка изменяться, или нет.

Во многих и даже очень многих могу

const char* p — и я имею право предположить, что не будет.


GZ>По крайней мере одну придется делать(и не дай бог что TestWord тоже использует strtok):


GZ>

GZ>void MyWords(const char* str)
GZ>{
GZ>   char* myString=new char[strlen(str)+1];
GZ>   strcpy(myString, str);
GZ>   p=strtok(myString,",");
GZ>   while(p)
GZ>   {
GZ>     TestWord(p);
GZ>     p = strtok(NULL,",")
GZ>   }
GZ>}
GZ>

Да зачем же ? Пусть TestWord себе благополучно эту строку исследует (например, является ли слово палиндромом). Начало — p, конец — '\0', зачем мне тут подстроки в отдельный буфер копировать, когда и на месте все ясно ?

Здравствуйте, Павел Кузнецов, Вы писали:


ПК>Дело в наличии внутренних различий и в обусловленной этим разнице в процессе разработки. В отличие от серийного производства каждая новая программа, не разрабатываемая изменением уже существующей, проектируется заново (естественно, с учетом предыдущего опыта, но заново).

Если позволите, то я слегка в этот разговор вмешаюсь, несколько в иной плоскости.

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

Если речь идет о библиотеках типа STL, MFC etc. или компонентах для рынка — все ясно. В общем, они и рассчитаны на то, что их именно повторно будут использовать.

А вот когда речь идет о коде, разработанном для данного проекта, то во многих случаях Copyright на этот код получит заказчик. Так что повторно его использовать законным путем можно только в том случае, когда новый проект будет для того же заказчика (или когда заказчик прежний разрешит). В противном случае повторное использование есть нарушение Copyright.

Интересно было бы узнать — насколько часто программисты действительно повторно используют свой код ? Т.е не идеи из него используют для нового кода, а прямо-таки класс/функцию/компонент свой берут и в новый проект втыкают. Естественно, речь не идет о библиотеках.

Прочитал я то. что написали участники дискуссии. В общем, со многим можно согласиться. С тезисом "клиент всегда прав" не поспоришь. Да и тот факт, что нынешнее программирование — это работа за деньги, а кто платит, тот и заказывает музыку, тоже вне сомнения. Хотя средства разраюотки — прерогатива не только заказчика, но и разработчика.

Но вот утверждение, что, дескать в этом и заключается новая ситуация в IT-индустрии — ИМХО спорно. Боюсь, что она не новая, а очень даже старая.

Есть такой класс программистов — программисты на Visual Basic. VB как-то в России не слишком популярен ИМХО и признаваться, что на нем пишешь, даже как-то стыдно считалось . А вот в мире он весьма популярен, где-то мне встретилось утверждение, что в мире около 1 млн. программистов на VB. За то. что мне память здесь не изменяет — не поручусь, так что критиковать это утверждение не надо. И потом, неизвестно кого они туда включили — может, школьников средних школ тоже

Так вот, эти самые программисты на VB свою работу делали, а вот эффективности от них никто и не ждал. Потому что программы для массового использования они не делали, а делали для данного конкретного случая, порой для себя, или для заказчика, которому она нужна, а торговать он ей вовсе не собирается. Кстати, если во времена своих химических расчетов имел бы PC с VB — вполне возможно, на нем бы и начал свою карьеру. Просто, удобно, легко...

Что касается эффективности — кто ее от Бейсика когда ждал ? К нему традиционное отношение как к чему-то неэффективному — интерпретатор же! И пусть VB никакой не интерпретатор — от однажды завоеванной репутации так легко не отделаешься

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

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

PD>Есть такой класс программистов — программисты на Visual Basic. VB как-то в России не слишком популярен ИМХО и признаваться, что на нем пишешь, даже как-то стыдно считалось . А вот в мире он весьма популярен, где-то мне встретилось утверждение, что в мире около 1 млн. программистов на VB. За то. что мне память здесь не изменяет — не поручусь, так что критиковать это утверждение не надо. И потом, неизвестно кого они туда включили — может, школьников средних школ тоже

PD>Так вот, эти самые программисты на VB свою работу делали, а вот эффективности от них никто и не ждал. Потому что программы для массового использования они не делали, а делали для данного конкретного случая, порой для себя, или для заказчика, которому она нужна, а торговать он ей вовсе не собирается. Кстати, если во времена своих химических расчетов имел бы PC с VB — вполне возможно, на нем бы и начал свою карьеру. Просто, удобно, легко...

думаю ты сильно ошибаешся, утверждая что Visual Basic есть средство для
наколенного написания программ. Это полноценный mainstream продукт для разработки
софта. Как раз для приложений массового использования. А то что он использовался в основном для in house софта (которым не надо торговать) — так только потому, что это основной это именно in house приложения.

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

GZ>>strok — злобная функция, так как она использует static данные на уровне CRT.

PD>Хуже. Она использует __declspec(thread). Иначе, сам подумай, что будет, если ее начнут из разных потоков вызывать
Для этого достаточно одного потока.

PD>Во многих и даже очень многих могу
PD>const char* p — и я имею право предположить, что не будет.
+1. К сожалению const многие не ставят. Поэтому приходится лазить по коду и узнавать, можно или нельзя. Ну а в Net const в параметрах нет.

GZ>>По крайней мере одну придется делать(и не дай бог что TestWord тоже использует strtok):
GZ>>

GZ>>void MyWords(const char* str)
GZ>>{
GZ>>   char* myString=new char[strlen(str)+1];
GZ>>   strcpy(myString, str);
GZ>>   p=strtok(myString,",");
GZ>>   while(p)
GZ>>   {
GZ>>     TestWord(p);
GZ>>     p = strtok(NULL,",")
GZ>>   }
GZ>>}
GZ>>

PD>Да зачем же ? Пусть TestWord себе благополучно эту строку исследует (например, является ли слово палиндромом). Начало — p, конец — '\0', зачем мне тут подстроки в отдельный буфер копировать, когда и на месте все ясно ?
Честно говоря, аналогом можно считать больше wstring чем char*. Char* — это область памяти с которой можно сильно сглюкавить, что для Net противозаконно. Я когда код пишу, подразумеваю что им будут пользоваться и другие. А другие обычно в код функции не смотрят, а ориентируются по названию и параметрам. Поэтому всегда пытаюсь показать, что строка может быть изменена или нет, тем же const. Но бывает и такое:

if (bla-bla)
   strupr(lpStr);

То есть, не обязательно строка будет изменена. А защищать ее как-то уже надо. В Net над таким задумываться не надо. Поскольку это не value объект, он всегда передается по ссылке. А возвращаться может только в виде другой строки(или другой ссылки, если строка не изменилась). Именно в том, что это именно неvalue объект, и не хранится в стеке, скорее и стало определяющим фактом для выбора такого "функционального" пути.

Но особым плюсом такого подхода можно указать следующее:

string str1="this is the string";
.......
string str2="this is the string";

Строка str1 и str2 — несмотря на то, что являются разными ссылками, в действительности ссылаются на одну и ту же строку. Строка лежит в метаданных. Достаточно частый случай что константно описывают одну и ту же строку в разных частях программы. Компилятор сохраняет строку в одном и том-же месте.

С уважением, Gleb.

Pavel Dvorkin,

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

Пожалуй, при разговорах о повторном использовании речь идет о других проектах, делающихся "для себя". Особенно актуально это для (относительно) маленьких команд и/или (относительно) долгоживущих проектов.

> Интересно было бы узнать — насколько часто программисты действительно повторно используют свой код? Т.е не идеи из него используют для нового кода, а прямо-таки класс/функцию/компонент свой берут и в новый проект втыкают.

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

> Естественно, речь не идет о библиотеках.

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

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

PD>>Хуже. Она использует __declspec(thread). Иначе, сам подумай, что будет, если ее начнут из разных потоков вызывать
GZ>Для этого достаточно одного потока.

Только при некорректном использовании.

GZ>Честно говоря, аналогом можно считать больше wstring чем char*. Char* — это область памяти с которой можно сильно сглюкавить

или сделать что-то очень эффективно. Вообще возможность сделать что-то эффективно всегда связана с большей возможностью сглюкавить. Крайний пример такого утверждения — ассемблер.



GZ>

GZ>if (bla-bla)
GZ>   strupr(lpStr);
GZ>

Да. Классический вариант inplace обработки.


GZ>То есть, не обязательно строка будет изменена. А защищать ее как-то уже надо. В Net над таким задумываться не надо. Поскольку это не value объект, он всегда передается по ссылке. А возвращаться может только в виде другой строки(или другой ссылки, если строка не изменилась).

Вообще-то идея string как неизменяемого объекта в NET мне нп\равится (правда, идея не Net, а Java принадлежит, а может, и кому-то до нее — не знаю). Разумеется, при наличии еще и StringBuilder.



GZ>Но особым плюсом такого подхода можно указать следующее:
GZ>

GZ>string str1="this is the string";
GZ>.......
GZ>string str2="this is the string";
GZ>

GZ>Строка str1 и str2 — несмотря на то, что являются разными ссылками, в действительности ссылаются на одну и ту же строку.


Такое поведение и в С++. Еще в Borland C++ 3.1 было(merge duplicate strings). Только там оно управляемо через опции компилятора. Можно и отказаться

>Строка лежит в метаданных.

В С++ — в readonly данных (т.е. страница readonly). Изменить строку не удастся без шаманства.

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

IS>думаю ты сильно ошибаешся, утверждая что Visual Basic есть средство для
IS>наколенного написания программ. Это полноценный mainstream продукт для разработки
IS>софта. Как раз для приложений массового использования. А то что он использовался в основном для in house софта (которым не надо торговать) — так только потому, что это основной это именно in house приложения.

Игорь, я вовсе не утверждаю этого И более того, если есть 1 млн. программистов на нем, то они за что-то деньги свои получают. Я о другом говорю. До сих пор была определенная разница между тем, что можно было хотя бы в принцие писать на VB и тем, для чего VB не может рассматриваться как среда разработки вообще.
Например, я сильно сомневаюсь, что Adobe могла бы рассматривать VB как среду для разработкт своих продуктов. И даже на порядок более простой какой-нибудь file downloader тоже на VB никто писать не стал бы. Не то средство.

А вот будет ли Adobe переписывать PhotoShop на .net — не знаю. Надеюсь, что нет

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

MS>Но зададим себе вопрос — "а оно надо"? Может быть и не нужен поиск в Janus? Или нужен?

Янус не стоит приводит в качестве примера. Облик януса определяется не столько потребностями пользователей в целом, сколько потребностями его разработчиков.
Это вобще очень забавный проект — с одной стороны open source, с другой цели его сугубо утилитарные (очень мало влияют соображения престижа или самореализации).

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Это не так хотя бы по простому факту того, что выпускаемые программы отличаются друг от друга. В противном случае не понимаю, зачем их много...

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

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


PD>Игорь, я вовсе не утверждаю этого И более того, если есть 1 млн. программистов на нем, то они за что-то деньги свои получают. Я о другом говорю. До сих пор была определенная разница между тем, что можно было хотя бы в принцие писать на VB и тем, для чего VB не может рассматриваться как среда разработки вообще.

PD>Например, я сильно сомневаюсь, что Adobe могла бы рассматривать VB как среду для разработкт своих продуктов. И даже на порядок более простой какой-нибудь file downloader тоже на VB никто писать не стал бы. Не то средство.

если приглядеться — у формы автоапдейтера Microsoft AntiSpyware просвечивает VB икона =)

PD>А вот будет ли Adobe переписывать PhotoShop на .net — не знаю. Надеюсь, что нет
главное чтобы программа была удобная, а на чем ее переписывали — мне уже не интересно.

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


PD>Так вот, у меня впечатление такое, что этот стиль VB попросту начинает проникать в те области, куда программистов VB раньше и на пушечный выстрел не подпускали, да они и сами не стремились, так как знали, что им там делать нечего — не влезут они с VB в имеющиеся ресурсы, не добьются нужной производительности. А ресурсы увеличились — и они пошли!

На самом деле большинство требуемых программ бухгалтерские, складские, зарплата. Там много писанины, но нет задач оптимизации по скорости ,вернее есть но их не так много и решаются интеграцией через различные Dll где они решаются более эффективно на типизированных компилированных языках. Посмотри на 1С зарплаты 1С программистов, итд.
В свое время Delphi был изгоем для большинства сишников, сейчас Net. Каждый инструмент для решения своей задачи, но в большинстве случаев нужна скорость разработки, библиотеки классов итд. Железо совершенствуется и там,где в свое время было лимитирующим процессом, сейчас нет проблем так как скорости возросли в 10 раз за период в 5 лет.

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

PD>Хотел я в исходном постинге напомнить про один принцип. Потом решил, что введет ненужную игривость

PD>KISS — Keep It Simple, Stupid!

а ты уверен, что знаешь, что именно это утверждение значит?
Что соображения удобства чтения и модификации кода стоят выше соображений эффективности
почитай Реймонда, например.

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

PD>Есть такой класс программистов — программисты на Visual Basic. VB как-то в России не слишком популярен ИМХО и признаваться, что на нем пишешь, даже как-то стыдно считалось . А вот в мире он весьма популярен, где-то мне встретилось утверждение, что в мире около 1 млн. программистов на VB. За то. что мне память здесь не изменяет — не поручусь, так что критиковать это утверждение не надо. И потом, неизвестно кого они туда включили — может, школьников средних школ тоже

PD>Так вот, эти самые программисты на VB свою работу делали, а вот эффективности от них никто и не ждал. Потому что программы для массового использования они не делали, а делали для данного конкретного случая, порой для себя, или для заказчика, которому она нужна, а торговать он ей вовсе не собирается. Кстати, если во времена своих химических расчетов имел бы PC с VB — вполне возможно, на нем бы и начал свою карьеру. Просто, удобно, легко...

PD>Что касается эффективности — кто ее от Бейсика когда ждал ? К нему традиционное отношение как к чему-то неэффективному — интерпретатор же! И пусть VB никакой не интерпретатор — от однажды завоеванной репутации так легко не отделаешься

PD>Так вот, у меня впечатление такое, что этот стиль VB попросту начинает проникать в те области, куда программистов VB раньше и на пушечный выстрел не подпускали, да они и сами не стремились, так как знали, что им там делать нечего — не влезут они с VB в имеющиеся ресурсы, не добьются нужной производительности. А ресурсы увеличились — и они пошли!

Есть у меня на работе одна система. Клиентская часть написана на VC6. Около полумега cpp-шек. Многопоточная, большой объем взаимодействия с системой, работа с Oracle и прочие мелочи. Работать она должна на машинах с 32 мегами памяти (потому что есть у нас и такие). Ничего, работает. На тысяче машин где-то. Параллельно.

Есть для нее панель управления. Через которую ею администраторы управляют. Ее писал на VB6. Почему? Потому что надо быстро было писать, и чтобы работало. Больше сотни окошек в ней, а написана была за 4 месяца. Кстати, с собственным, заточенным под нее гридом (работает, чертяка, идеально). Памяти жрет под полсотни мег. Ну и что? У админов ее все равно 512. Не то, что у пользователей.

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

Кстати, об эффективности. На VB, бывает, тоже приходится данные локально обсчитывать. И где пооптимизировать — находится...

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

Д>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Хотел я в исходном постинге напомнить про один принцип. Потом решил, что введет ненужную игривость

PD>>KISS — Keep It Simple, Stupid!

Д>а ты уверен, что знаешь, что именно это утверждение значит?

Уверен

Д>Что соображения удобства чтения и модификации кода стоят выше соображений эффективности


А это вопрос спорный. Смогтря для чего, по крайней мере.

Д>почитай Реймонда, например.

Ну что же, у каждого своя точка зрения.

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

Д>>Что соображения удобства чтения и модификации кода стоят выше соображений эффективности

PD>А это вопрос спорный. Смогтря для чего, по крайней мере.

Спорить тут абсолютно не о чем. Почитай книгу.
http://www.catb.org/~esr/writings/taoup/html/

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

Д>Здравствуйте, Pavel Dvorkin, Вы писали:

Д>>>Что соображения удобства чтения и модификации кода стоят выше соображений эффективности

PD>>А это вопрос спорный. Смогтря для чего, по крайней мере.

Д>Спорить тут абсолютно не о чем. Почитай книгу.


Почему, если в некоторой книге что-то написано,, то спорить уже абсолютно не о чем ? Там что — евангелие или тезисы ЦК КПСС к NNN съезду?


Д>http://www.catb.org/~esr/writings/taoup/html/

Из протокола заседания комиссии по разработке нового автомобиля.

Директор фирмы :

Уважаемые господа!

Мы приступаем к разработке автомобиля нового поколения с использованием новейших технологий. Вот какими принципами вы должны руководствоваться :

Если автомобиль будет сжигать 100 литров бензина на 100 км пути — это не страшно. Нефти еще много, это не ресурс.
Если габариты автомобиля таковы, что, будучи на самой правой полосе шестрирядной дороги, он выходит частично на полосу встречного транспорта — это тоже не страшно. Кто захочет — объедет, а до остальных нам дела нет.
Но вот если вы не сможете с закрытыми глазами развинтить его и заменить мотор — всех уволим!
Если хоть один механик на станции ТО не сможет это сделать — всех уволим!
А если это не сможет кто-то сделать через 10 лет, когда вас уже в фирме не будет — на том свете найдем и угольков подкинем.

Вопросы есть ? Приступайте!

P.S. А вообще-то я не против автомобиля новейших технологий. Лишь бы он не отнимал ресурсов больше, чем существующие.

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

PD>Почему, если в некоторой книге что-то написано,, то спорить уже абсолютно не о чем ? Там что — евангелие или тезисы ЦК КПСС к NNN съезду?

евангелие — это близко к истине

PD>Из протокола заседания комиссии по разработке нового автомобиля.

PD>Директор фирмы :

PD>Уважаемые господа!

PD>Мы приступаем к разработке автомобиля нового поколения с использованием новейших технологий. Вот какими принципами вы должны руководствоваться :

PD>Если автомобиль будет сжигать 100 литров бензина на 100 км пути — это не страшно. Нефти еще много, это не ресурс.
PD>Если габариты автомобиля таковы, что, будучи на самой правой полосе шестрирядной дороги, он выходит частично на полосу встречного транспорта — это тоже не страшно. Кто захочет — объедет, а до остальных нам дела нет.
PD>Но вот если вы не сможете с закрытыми глазами развинтить его и заменить мотор — всех уволим!
PD>Если хоть один механик на станции ТО не сможет это сделать — всех уволим!
PD>А если это не сможет кто-то сделать через 10 лет, когда вас уже в фирме не будет — на том свете найдем и угольков подкинем.

пусть лучше жрет топливо, но зато не глохнет при повороте руля на угол чуть больше обычного
и не взрывается после замены зеркала заднего обзора на другую модель
про пример с sprintf еще не забыл?

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

Д>евангелие — это близко к истине

1.Не сотвори себе кумира!
2. Не относись ко всему чересчур серьезно. Имей чувство юмора.

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

А почему он глохнуть-то должен ? Можно ить обычных размеров сделать, и с обычным расходом горючего. Тойота вроде не глохнет, и Мерседес тоже. И размерами они не с ТУ-154.
А вот если у вас только Запорожец получается, то научитесь делать хотя бы Тойоту. Но обычных размеров.

Д>про пример с sprintf еще не забыл?

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

А кстати, о sprintf. Меня, как я помню, обвиняли в том. что возможно переполнение буфера. Не спорю, теоретически возможно. Но ведь и в этом операторе переполнение возможно

int nScreenArea = nScreenWidth * nScreenHeight;

А вдруг у нас будет экран 80000*60000. Сразу все перестанет работать.

Так вот, мой sprintf вызовет переполнение буфера. Обязательно вызовет. Но не раньше, чем этот пример сгенерирует integer overflow