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

GN>>ИМХО проблема не в языках. Многие алгоритмы имеют зависимости по данным (нельзя продолжать выполнение, пока не известен результат предыдущей операции). Да возьмём для примера любимый компилятор — даже если распараллелим компиляцию отдельных файлов, то как быть с линкером?
GZ>Оптимизировать последовательные операции. Пускай даже несколько эвристично. Это делает процессор

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

GZ>а почему бы и не компилятор?

По причине выше.

GN>>Можно вспомнить много таких "революционных" технологий даже на x86 — MMX, SSE, ... реальных выигрышей они не дают, если бы обычных регистров добавили, да нормальный (не стековый) FPU сделали — результат бы мог и лучше получиться. Но это бы была только *эволюция*.
GZ>Вот если бы сам x86 был стековый. Вот бы была крутизна.

Не уверен. Forth хороший язык, но что-то я видел мало людей, кто на нём пишет .

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

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

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


GZ>{
GZ> rows.Add(myString.Substring(i, l-i);

А здесь не создается временная строка в результате работы Substring ? Если так написать

string sTemp = myString.Substring(i, l-i);
rows(Add);

то ясно, что создается. А это отличается только тем, что ссылка на эту строку записывается во временную переменную.


GZ>Делает именно то, что заказывали. Без массива.

Зато с временными строками (== те же массивы)

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

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


RB>

RB>На C++ конкатенацию массива строк в новую строку (я имею в виду не string из STL, а char*) я все же напишу однопроходным алгоритмом и при этом не будут использоваться никакие промежуточные буферы.

RB>Как ?

char szTotal[1000];
char * szStrings[3] ={"abc", "def", "ghi"};
int nStrings = 3;
char* pCurrent = szTotal;
for(int i = 0; i < nStrings; i++)
pCurrent += sprintf(pCurrent,"%s",szStrings[i]);

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

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


GZ>>{
GZ>> rows.Add(myString.Substring(i, l-i);

PD>А здесь не создается временная строка в результате работы Substring ? Если так написать

PD>string sTemp = myString.Substring(i, l-i);
PD>rows(Add);

PD>то ясно, что создается. А это отличается только тем, что ссылка на эту строку записывается во временную переменную.
Именно, во временную переменную записывается ссылка на строку. Правда эта переменная будет оптимизирована и изъята JIT. Это с одной стороны, но с другой стороны в Net есть такое правило(которое подкрепляется языком), строку нельзя изменить. Можно создать только новую строку. Все методы изменяющие строки, не изменяют текущую строку, а создают новую. В результате — rows не будет делать копию строки. У него есть гарантия, то, что строка не будет никогда не изменена, которой он воспользуется. Поэтому процент случаев когда передается именно ссылка на строку, а не копируется строка на порядок выше чем в C++.

GZ>>Делает именно то, что заказывали. Без массива.
PD>Зато с временными строками (== те же массивы)
Попрошу не путать временную строку и локальную ссылку на строку. В том что я описал выше, массивы != строка. И работа с ними существенно отличается.

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

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

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

PD>>Sinclair, sorry, а не мог бы ты подсказать, как здесь эффективно сконкатенировать все же массив строк при том, что количество их определится в момент конкатенации?
S>С массивом все вообще просто. См. string.Join.

+

PD>>Твой первый пример хорош, но там жестко 3 строки. На C++ конкатенацию массива строк в новую строку (я имею в виду не string из STL, а char*) я все же напишу однопроходным алгоритмом и при этом не будут использоваться никакие промежуточные буферы. Потому что задача по определению однопроходная.
S>Это как, интересно?

Не понял, ты спрашиваешь, как в C++ сделать ? Я уже отвечал.

http://www.rsdn.ru/Forum/Message.aspx?mid=1424567&amp;only=1

Автор: Pavel Dvorkin
Дата: 07.10.05

S>Не так ли:
S>

S>public static string Join(IEnumerable<string> strings)
S>{
S>  int len=0;
S>  foreach(string s in strings)
S>      len+=s.Length;
S>    StringBuilder sb = new StringBuilder(len); // избегаем перевыделений
S>  foreach(string s in strings)
S>      sb.Append(s);
S>    return sb.ToString();
S>}
S>

S>?

Да, то же самое. Спасибо.

PD>>Здесь это можно, используя только string, а не StringBuilder ?
S>Можно. Но уволят.

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

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


GN>Когда-то спросил старого программера, как писать оптимальные программы. Я то думал, вопрос с подковыркой (оптимизировать по скорости или по размеру можно). А он ответил просто: "упрощай их".

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

KISS — Keep It Simple, Stupid!

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


PD> char szTotal[1000];
PD> char * szStrings[3] ={"abc", "def", "ghi"};
PD> int nStrings = 3;
PD> char* pCurrent = szTotal;
PD> for(int i = 0; i < nStrings; i++)
PD> pCurrent += sprintf(pCurrent,"%s",szStrings[i]);


М-м-м-м... Ну а если строк много, и их длина неизвестна? Вам

std::vector <std::string> >

чем-то не нравится или я что-то пропустил?

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

GZ>В честь чего. В С++ два основных типа строк.(пишу именно основных, чтоб не наезжали) Строка и нестрока, то есть string и char[]. string объект ООП — char[] наследие С. Кто из них высокоуровневая конструкция, а кто тормозная?

char[] не наследин С, а один из базовых типов. А string на его базе реализован.

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


PD>>А здесь не создается временная строка в результате работы Substring ? Если так написать

PD>>string sTemp = myString.Substring(i, l-i);
PD>>rows(Add);

PD>>то ясно, что создается. А это отличается только тем, что ссылка на эту строку записывается во временную переменную.
GZ>Именно, во временную переменную записывается ссылка на строку. Правда эта переменная будет оптимизирована и изъята JIT. Это с одной стороны, но с другой стороны в Net есть такое правило(которое подкрепляется языком), строку нельзя изменить. Можно создать только новую строку. Все методы изменяющие строки, не изменяют текущую строку, а создают новую. В результате — rows не будет делать копию строки.

Ты меня не понял. Я и не говорил, что rows будут. Я говорил, что Substring будет.

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

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


PD>> char szTotal[1000];
PD>> char * szStrings[3] ={"abc", "def", "ghi"};
PD>> int nStrings = 3;
PD>> char* pCurrent = szTotal;
PD>> for(int i = 0; i < nStrings; i++)
PD>> pCurrent += sprintf(pCurrent,"%s",szStrings[i]);


RB>М-м-м-м... Ну а если строк много, и их длина неизвестна?

Да хоть сотня, что от этого изменится ? И при чем здесь длина, где я ее использую ?
Ты идею прост не понял. sprintf возвращает длину выведенного куска символов (т.е очередной строки). Следующиий вывод идет с новой позиции, начиная за предыдущей строкой, после ее последнего символа. Ни один символ не просматривается и не копируется дважды. Строго однопроходной алгоритм.

>Вам
RB>

RB>std::vector <std::string> >
RB>

RB> чем-то не нравится или я что-то пропустил?

При чем здесь вектор (массив) строк — не понимаю. Речь шла о конкатенации нескольких строк в одну.

GlebZ,

>>> А string вообще кошмар, но зато жутко удобный.

> ПК>Это к уровню языка отношения не имеет.

> В честь чего. В С++ два основных типа строк.(пишу именно основных, чтоб не наезжали) Строка и нестрока, то есть string и char[]. string объект ООП — char[] наследие С. Кто из них высокоуровневая конструкция, а кто тормозная?

Какое отношение к string имеет уровень языка, и string к уровню языка? В лучшем случае тут можно говорить об уровне абстракции. Но и в этом случае вряд ли можно говорить об универсальной зависимости производительности от уровня абстракции. Иными словами, в данном случае производится попытка сделать общий вывод (зависимость производительности от уровня языка) из частных моментов (производительность char[] vs. std::string), не вполне относящихся к ходу рассуждений (уровень языка здесь, имхо, ни при чем).

GlebZ,

> ПК>С такими ошибками в C++ шаблоны могут помочь бороться.

> Заметка из жизни. Если у программиста проблемы с ДНК, то C# многое прощает, а вот шаблоны в С++ многое усугубляют.

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

GlebZ,

> ПК>Теперь осталось показать, что при разработке программ процесс происходит более-менее также...

> Все к этому движется. Только все медленнее и медленнее.

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

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

ПК>Если у программиста проблемы с ДНК, то лечится это не инструментальными средствами. Инструменты, напротив, должны давать возможности тем программистам, у которых с ДНК все в порядке.

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

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

PD>Ты меня не понял. Я и не говорил, что rows будут. Я говорил, что Substring будет.
А я говорил, что никаких временных объектов при этом создаваться не будет.

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

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

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

ПК>>Если у программиста проблемы с ДНК, то лечится это не инструментальными средствами. Инструменты, напротив, должны давать возможности тем программистам, у которых с ДНК все в порядке.

M>А вот это — более чем спорно. Я бы даже сказал, что подобные заявления отдают манией величия =)
M>Не думаю, что стоит вот так категорично говорить о том, что вам должны инструментальные средства.

Я поддерживаю Великое ИМХО Кузнецова Павла.

Вилка — инструмент, ей можно красиво есь не теря собственного достоинства, есть фруктовая вилка, ей можно есть фрукты. Это вводная.

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

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


Такие вот интсрументы эти Ваши вилки

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

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

> Другой пример — корпусная мебель. Части одинаковые, а шкаф каждому свой нужен. Сборка — отверткой.
Теперь осталось показать, что при разработке программ процесс происходит более-менее также...

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

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

S>Такие вот интсрументы эти Ваши вилки

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

Но главное не это. Главное то, что я, как и подавляющее большинство населения, фруктовыми вилками не пользуюсь. Зато пользуюсь чайными ложками. И человека, который заявляет, что "Чайные ложки не нужны, вот фруктовые вилки — это круто!", я всерьез воспринимать затрудняюсь. Так как он, вполне вероятно, большуй умелец по части поедания фруктов не теряя достоинства, но вот с кругозором и трезвой самооценкой у него явно некоторые проблемы

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

GN>>Когда-то спросил старого программера, как писать оптимальные программы. Я то думал, вопрос с подковыркой (оптимизировать по скорости или по размеру можно). А он ответил просто: "упрощай их".

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

PD>KISS — Keep It Simple, Stupid!

В ту же тему: Re[3]: КОНЦЕПЦИЯ ЧИСТЫХ ЛИНИЙ

Автор: IT
Дата: 17.08.05

, Re[4]: КОНЦЕПЦИЯ ЧИСТЫХ ЛИНИЙ

Автор: eao197
Дата: 19.08.05

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

S>>Такие вот интсрументы эти Ваши вилки

M>Простите, у вас есть дети?
M>Я имею в виду, знаете ли вы, какие меры предосторожности нужно предпринимать, если в доме есть ребенок, умеющий ходить, но еще не имеющий развитого инстинкта самосохранения?

Отлично, тема детей, это очень даже хорошо

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

Соответсвенно, взрослым, или как Вы изволили вырвзиться

умелецы по части поедания фруктов не теряя достоинства

Имеют свои вилки, а дети свои.

Таким образом кесарю — кесарево...

ВЫВОД:
Для

программиста проблемы с ДНК

нужны свои инструментальные средства

А для Взрослых — свои.

Прочитав топик про С# 3.0 С# 3.0

Автор: AndrewVK
Дата: 14.09.05

меня посетило подозрение, что C# взрослеет, и скоро там тоже понадобяться раздельные наборы столовых приборов


ЗЫ ОЛЛ прошу извинить фривольный стиль, просто, я отчего-то веселый такой Сыну сегодня пол-года