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

E>>>>Зачем для этой фичи много памяти при компиляции?

M>Ты думаешь, анализ и расставление меток для Edit&Continue даются даром?

Заходим на второй круг?

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

E>>>>>Зачем для этой фичи много памяти при компиляции?

M>>Ты думаешь, анализ и расставление меток для Edit&Continue даются даром?

E>Заходим на второй круг?

E>Конкретно а метки и прочее я так думаю, что если приструнить оптимизатор + оставить прокладок в коде, то это не дороже чем .map файл сгенерить. что умели практически все компиляторы С и С++...

Блин. это одна из фич компилятора. Которых много. То есть потребности компилятора растут не только из-за Edit&Continue.

E>Зачем для этой фичи много памяти при компиляции?

Так не только же для этой фичи

Блин. Это ад какой-то

Сейчас не удивлюсь, если ты повторишь мантру

Автор: Erop
Дата: 20.08.12

.

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

M>

E>>Зачем для этой фичи много памяти при компиляции?

M>Так не только же для этой фичи

M>Блин. Это ад какой-то

Попробуй как-то ПОНЯТНО объяснить, как конкретно эта фича увеличивает рабочее множество компилятора...

M>>Блин. Это ад какой-то

E>Попробуй как-то ПОНЯТНО объяснить, как конкретно эта фича увеличивает рабочее множество компилятора...

Ты считаешь, что анализ компилиркмого кода и расставление меток является операцией с нулевым оверхедом?

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

E>Ну мне, например, тоже интересно, как такая сильная зависимость возникает, и ради чего не идут на меньшую зависимость? Ну там невозможно в принципе, очень сложно, очень медленно и т. д...

Ссылку в топике дали.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ссылку в топике дали.

Ну, если не трудно, повтори? Я тот топик сильно не весь ещё прочёл... Или это уже в этом топике?

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


H>В чем проблема-то? Строки с двухбайтовым символом, покрывают весь BMP. Строки с четырехбайтовым символом покрывают весь юникод вообще. Но достаточно и двухбайтового символа т.к. все что за BMP практически не используется.

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

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

N>Переупрощаешь. Нормализация может дать и несколько символов.
N>Именно посимвольные сравнения начинают терять смысл, остаются только поиски подстрок. А это дороже.

Чушь таки это. Если речь идёт об операциях над буквами именно, словами там, текстовой информацией на естественном языке, как бы, то есть символы, которые логично трактовать, как символы. Это типа там скобки, пробелы, запятые и т. д.
А есть всё остальное логично трактовать именно, как строки. Зачем в тексте на русском уметь менять e на ё или наоборот я не понимаю. Я понимаю операци "убрать диакритику", но это просто и понятно делается. Берёшь список некашерных модификаторов и поэтому списку фильтруешь...

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

S>Я, естественно, хотел сказать, что за предположение о константности времени выполнения операции a[i] без проверки того, как реализован operator[] для этого a, нужно сразу же отправлять в астрологический колледж.

На мой вкус туда надо отправлять тех кто делает такие операторы медленными.
Как мне кажется у списка на указателях не должно быть []...
но речь тут не о том.
Функциональщина, не важно в форме линка или стл, хороша тем, что освобождает программиста от размышлений о процедурном аспекте. Но тем же она и плоха. В какой-то момент фокус не удаётся и фанат функциональщины получает ВНЕЗАПНО мегатормозной код...

Или ты думаешь на С++ нельзя родить аналога линка что ли? Конечно же можно. и оно так же будет работать со всеми теми же проблемами...

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


M>Чистейший C++. Взято на основе [url=http://code.google.com/p/cpplinq/source/browse/src/cppLinqUnitTest

Какая разница С++ или шарп? Речь же идёт о функциональщине против императивщины...

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

E>На мой вкус туда надо отправлять тех кто делает такие операторы медленными.
E>Как мне кажется у списка на указателях не должно быть []...
Это интересная концепция. Вы хотите, чтобы объём прикладного кода отражал сложность нижележащей операции, так что ли?
То есть если у нас периодически в коде встречается обращение к пятому элементу списка, вы хотите требовать от программиста писать

int item5;
T curr = list.head();
for(int i=0;i<5;i++)
  curr++;
item5 = curr.value();

вместо просто list[5]?

Простите, я с этим не согласен.

E>но речь тут не о том.
А о чём?
E>Функциональщина, не важно в форме линка или стл, хороша тем, что освобождает программиста от размышлений о процедурном аспекте. Но тем же она и плоха. В какой-то момент фокус не удаётся и фанат функциональщины получает ВНЕЗАПНО мегатормозной код...
Пока что тема зависимости этого эффекта от функциональщины не раскрыта. Фанат процедурности запросто может получить ВНЕЗАПНО мегатормозной код.
Просто потому, что таково свойство любой инкапсуляции — прятать подробности.
Вот, например, делаю я совершенно процедурный вызов connect(). И ВНЕЗАПНО получаю его за 300 секунд вместо 300 миллисекунд. В чём дело? Да я просто запустил его на машине без доступа во внешнюю сеть, и он побежал искать certificate revocation list, обламываясь по таймауту.
E>Или ты думаешь на С++ нельзя родить аналога линка что ли? Конечно же можно. и оно так же будет работать со всеми теми же проблемами...
Я думаю, что некоторые тут пытаются подменить тему.

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

S>Это интересная концепция. Вы хотите, чтобы объём прикладного кода отражал сложность нижележащей операции, так что ли?
Я не хочу, что бы меняли семантику, без изменения имени.
В частности я против перегрузки операторов В НЕОЧЕВИДНЫХ случаях.
operator[]( int ) -- 'nj оператор ПРЯМОЙ выборки.

Для непрямой выборки можно завести метод, например у Next можно иметь версию с параметром "скока раз от 0 до ..."
Тогда будет что-то вроде

list.head()->Next( 5 );

S>вместо просто list[5]?
Даже, если кто-то не в состоянии запрограммировать такие простые вещи, это не даёт права кому-то приписывать мне всякий бред. Даже если этот кто-то мой земляк.

S>Простите, я с этим не согласен.

Это всё от незнания STL

E>>Функциональщина, не важно в форме линка или стл, хороша тем, что освобождает программиста от размышлений о процедурном аспекте. Но тем же она и плоха. В какой-то момент фокус не удаётся и фанат функциональщины получает ВНЕЗАПНО мегатормозной код...
S>Пока что тема зависимости этого эффекта от функциональщины не раскрыта. Фанат процедурности запросто может получить ВНЕЗАПНО мегатормозной код.
Ну тутошние наезды на линк, на самом деле, являются наездами на то, что он функциональщина
E>>Или ты думаешь на С++ нельзя родить аналога линка что ли? Конечно же можно. и оно так же будет работать со всеми теми же проблемами...
S>Я думаю, что некоторые тут пытаются подменить тему.
Да, и эти "некоторые" -- ты

Здравствуйте, Erop, Вы писали:
S>>Это интересная концепция. Вы хотите, чтобы объём прикладного кода отражал сложность нижележащей операции, так что ли?
E>Я не хочу, что бы меняли семантику, без изменения имени.
E>В частности я против перегрузки операторов В НЕОЧЕВИДНЫХ случаях.
Ой-ой-ой. Так можно много чего запретить:

int count = 1;
assert((count << 2) == (count * 4)); // :)) 
assert((cout << 2) == (cout * 4)); //  :crash:

E>operator[]( int ) -- 'nj оператор ПРЯМОЙ выборки.

S>>Простите, я с этим не согласен.
E>Это всё от незнания STL
Нет, это от понимания того, что процедурность vs функциональность тут совершенно неважны. По виду программы гадать о её нефункциональных характеристиках нельзя. Можно было бы на гипотетическом языке реального времени, где система типов бы включала перформанс-характеристики.
На реально существующих — нельзя.

E>Ну тутошние наезды на линк, на самом деле, являются наездами на то, что он функциональщина
Тутошние наезды на линк преимущественно происходят от людей, которые не знают линк, но думают, что зато знают С++.
Как показывает практика, С++ такие люди тоже не знают.

E>Да, и эти "некоторые" -- ты
Это ещё почему? Вся прелесть в том, что критикуемый линк — нифига не функциональный. Linq to objects насквозь процедурен. Он не более функционален, чем С-шный qsort().

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

S>Это ещё почему? Вся прелесть в том, что критикуемый линк — нифига не функциональный. Linq to objects насквозь процедурен. Он не более функционален, чем С-шный qsort().

а что в нем(в линке) — НЕ функционального??? qsort реализует inplace сортировку, тут всё понятно, а в линком то что?

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

J>а что в нем(в линке) — НЕ функционального??? qsort реализует inplace сортировку, тут всё понятно, а в линком то что?
Я не понимаю ваш вопрос. Весь linq — это специальный способ записи вызова некоторых определённых императивных процедур.
Я могу сделать энергичную реализацию всех этих OrderBy и ThenBy; могу сделать её inplace.
Могу — не делать. Могу написать на C++ qsort таким образом, чтобы он был ленивым и не-inplace.

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

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

J>>а что в нем(в линке) — НЕ функционального??? qsort реализует inplace сортировку, тут всё понятно, а в линком то что?
S>Я не понимаю ваш вопрос. Весь linq — это специальный способ записи вызова некоторых определённых императивных процедур.
S>Я могу сделать энергичную реализацию всех этих OrderBy и ThenBy; могу сделать её inplace.
S>Могу — не делать. Могу написать на C++ qsort таким образом, чтобы он был ленивым и не-inplace.

под линком вы имеете в виду query syntax ??

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

J>под линком вы имеете в виду query syntax ??
конечно. Тут делаются сильные заявления про то, что на "императивных" языках синтаксис якобы позволяет "видеть сквозь код" без помоши профайлера, а "функциональный linq" якобы не позволяет. Я с ними спорю

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

S>Нет, это от понимания того, что процедурность vs функциональность тут совершенно неважны. По виду программы гадать о её нефункциональных характеристиках нельзя. Можно было бы на гипотетическом языке реального времени, где система типов бы включала перформанс-характеристики.
S>На реально существующих — нельзя.

Я, в целом, согласен, что гадать при программировании нельзя. Но у меня как-то получается таки ЗАНТЬ где какие асимптоты...

Про несогласие с тем, что нехорошо менять семантику без смены имени я не понял.
IMHO, ты привёл пример говнокода который как раз и иллюстрирует, что бездумное переопределение операторов ведёт в ад.
Кстати, в правильной С++ программе в глобальном пространстве имён cout'а нет, есть std::cout...

S>Как показывает практика, С++ такие люди тоже не знают.
Эта, отучаемся таки говорить за всех...

E>>Да, и эти "некоторые" -- ты
S>Это ещё почему? Вся прелесть в том, что критикуемый линк — нифига не функциональный. Linq to objects насквозь процедурен. Он не более функционален, чем С-шный qsort().

Чё? И в области запросов к БД тоже?

Ну чего нам про слов-то спорить? Фиг с ним, давай назовём это "декларативный стиль программирования" vs "процедурный"...

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

E>Про несогласие с тем, что нехорошо менять семантику без смены имени я не понял.
E>IMHO, ты привёл пример говнокода который как раз и иллюстрирует, что бездумное переопределение операторов ведёт в ад.
Ну, то есть говнокод начинается прямо со стандартной библиотеки, так?
E>Кстати, в правильной С++ программе в глобальном пространстве имён cout'а нет, есть std::cout...
И как это поможет?
E>Эта, отучаемся таки говорить за всех...
Я за конкретных говорю.

E>Чё? И в области запросов к БД тоже?
А в области запросов к БД он настолько же процедурен, насколько любая выбранная вами библиотека доступа к БД в С++.
Вот, скажем, DBLib, мир её праху. Происходит запрос, он уезжает в сервер, потом приезжает результат. Асимптотику тут гадать по С++ коду бесполезно.
Принципиально linq ничем не отличается — кроме статической валидации корректности запроса.
E>Ну чего нам про слов-то спорить? Фиг с ним, давай назовём это "декларативный стиль программирования" vs "процедурный"...
Ну так и не спорьте, делов-то.

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

S>Ну, то есть говнокод начинается прямо со стандартной библиотеки, так?
А есть сомнения, в том, что с++-потоки -- это говнокод?
Как ты относишься к тамошнему виртуальному наследованию, например?
А к "удобству" поддержки юникода?
А к невозможности использовать юникод в именах файлов?
Ну и т. д.

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

E>>Кстати, в правильной С++ программе в глобальном пространстве имён cout'а нет, есть std::cout...
S>И как это поможет?

Показанной тобой проблемы не будет. В std нет count, а в глобальном нет cout, если ты сам его не заведёшь, конечно...

S>Ну так и не спорьте, делов-то.
Так не надо глупости писать, что вот де мол и на С++ так тоже можно. Я ещё раз намекаю, что на С++ можно вобще полный аналог линка залудить, если очень хочется. Тока не делают так почему-то Делают через STL-way