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

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

А> Есть они. Гениями называются. Отличаются однобокостью. В дикой природе не выживают.
А> Эти узкозаточенные инструменты должны направляться людьми умными. Жалко их.

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

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

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

Ничего себе! У тебя он не заработал, из чего следует, что мой подход бесперспективный. Вопрос — а является ли бесперспективным все, что у тебя не хочет работать ?

S>ЗЫ: создал в 2005 студии проект вин32 консоль и вставил туда твой пример ... откомпилил ... запустил, че-то оно делало, при этом долгое время выдавая вопросы на консоль ... потом я это вырубил

Ну и аргументация. Во-первых, нет там никаких вопросов в тексте программы. И если уж вопросы выдавались, то можно было бы хоть один привести.

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

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

K>

K>for (list<pair<foo, bar>>::iterator iter = v.begin(); iter != v.end(); ++iter)
K>

K>Короче, необходимость делать аннотацию типа iter меня убивает.

Может, я чего-то не понял, но чем это отличается от

IEnumerator en = collection.GetEnumerator();
while (en.MoveNext()) // do something


ИМХО только тем, что вместо явного указания !=v.end() мы пишем "пока есть"

K>Кстати, я сейчас всё более склоняюсь к тому, что все эти коллекции а-ля STL сдизайнены неправильно. Например, если методу класса передаётся коллекция, которую он должен где-то внутри класса сохранить, то эту коллекцию (за исключением тех ситуаций, когда и так приемлемо) в целях сохранения инкапсуляции придётся копировать явно.

Вот это серьезный вопрос, но дело здесь не в неправильности. Кто будет собственником этой коллекции ? Иными словами, если класс должен ее сохранить, должен ли он ее уничтожить при своем уничтожении, т.е. в своем деструкторе ? Тут три подхода возможны

1. При передаче классу коллекции (да и не коллекции, чего угодно) он ее забирает в собственность. Если надо — делайте копии себе до передачи.
2. При передаче классу коллекции он сам делает ее копию, а вашу коллекцию не трогает.
3. Расшаривание со счетчиком ссылок.

Все три подхода ИМХО имеют право на существование.

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

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

PD>>P.S. Задачу, подобную этой , я студентам даю в качестве упражнения по memory-mapped файлам.

А> Павел, вы плохим вещам бедных наивных деток учите.

Да вроде пока никто не жаловался

А> Если задача стоит так, что требуется максимальная скорость доступа к записи с произвольным номером, то что из этого следует? Из этого следует, что файл должен быть организован так, что произвольный доступ стоил бы O(1). Точка.

Точка не проходит по очень простой причине. Дано : текстовый файл. И точка. Вот если у меня будет право самому выбрать структуру данных — разговор будет иной. А в этой задаче такого права мне не дано.

А>Если скорость принципиальна, то за использование плоского текстового файла надо карать жестоко

И бога ради, но при условии, что я в состоянии на это повлиять.

Вот ситуация, с которой я реально имел дело.

Заказчик дал мне CSV файл размером в 100 Мб примерно. Полей в каждой строке примерно 10. Мне надо было отсортировать его по каждому полю, т.е. иметь доступ к строкам этого файла сначала упорядоченно по первому полю, потом по второму и т.д. Дело было 5 лет назад, на машине не то 512, не то 256 Мб памяти.

Я что, должен был заказчику сказать, чтобы он мне в ином формате эти данные представил, уже отсортированные ?

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

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

PD>Ничего себе! У тебя он не заработал, из чего следует, что мой подход бесперспективный. Вопрос — а является ли бесперспективным все, что у тебя не хочет работать ?

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

PD>Ну и аргументация. Во-первых, нет там никаких вопросов в тексте программы. И если уж вопросы выдавались, то можно было бы хоть один привести.

да пожалуйста, вот они

????????????????????????????????????????????????????????????????????????????????????????????????????????????????

хватит?

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

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

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

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

K>>

K>>for (list<pair<foo, bar>>::iterator iter = v.begin(); iter != v.end(); ++iter)
K>>

K>>Короче, необходимость делать аннотацию типа iter меня убивает.

PD>Может, я чего-то не понял, но чем это отличается от

PD>IEnumerator en = collection.GetEnumerator();
PD>while (en.MoveNext()) // do something


PD>ИМХО только тем, что вместо явного указания !=v.end() мы пишем "пока есть"

Напоминаю: в C# есть foreach, а начиная с версии 2.0 — yield. А в C# 3.0 можно писать вот так:

var en = collection.GetEnumerator();

Кстати, ещё одно чисто языковое ограничение: после юзания вложенных функций с замыканиями и лямбд STL-ные функторы юзать вообще не хочется.

K>>Кстати, я сейчас всё более склоняюсь к тому, что все эти коллекции а-ля STL сдизайнены неправильно. Например, если методу класса передаётся коллекция, которую он должен где-то внутри класса сохранить, то эту коллекцию (за исключением тех ситуаций, когда и так приемлемо) в целях сохранения инкапсуляции придётся копировать явно.

PD>Вот это серьезный вопрос, но дело здесь не в неправильности. Кто будет собственником этой коллекции ? Иными словами, если класс должен ее сохранить, должен ли он ее уничтожить при своем уничтожении, т.е. в своем деструкторе ? Тут три подхода возможны

Какие деструкторы?

PD>1. При передаче классу коллекции (да и не коллекции, чего угодно) он ее забирает в собственность. Если надо — делайте копии себе до передачи.

Какая собственность? Как у value может быть собственник? Кому принадлежит 1, 2, 3, 42?

PD>2. При передаче классу коллекции он сам делает ее копию, а вашу коллекцию не трогает.

Какие копии? value не копируют? Где это видано, чтобы было 2 разные единицы, 5 разных восьмёрок?

PD>3. Расшаривание со счетчиком ссылок.

Вот это тема. Можно ещё и GC. Только пофигу. Значения не создают, они есть. Вот есть 1. Я могу это значение записать средствами языка. А есть множество. Пустое множество я тоже могу записать — Set<T>.Empty. А имея множества a и b и элемент e можно записать и такие множества: a | b, a & b, a — b, a.Add(e), a.Remove(e). Где здесь что-то уничтожается или создаётся?

PD>Все три подхода ИМХО имеют право на существование.

Да нет, не все. ИМХО, там где думаю на таком уровне абстракции, чтобы юзать предложенный подход, деструкторам не место.

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

K>Кстати, ещё одно чисто языковое ограничение: после юзания вложенных функций с замыканиями и лямбд STL-ные функторы юзать вообще не хочется.

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

PD>Заказчик дал мне CSV файл размером в 100 Мб примерно. Полей в каждой строке примерно 10. Мне надо было отсортировать его по каждому полю, т.е. иметь доступ к строкам этого файла сначала упорядоченно по первому полю, потом по второму и т.д. Дело было 5 лет назад, на машине не то 512, не то 256 Мб памяти.

И конечно же время было самим узким местом?

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


S>

S>????????????????????????????????????????????????????????????????????????????????????????????????????????????????

S>хватит?

Нет, не хватит. Дело в том, что в моей программе вывод закомментирован. Вот здесь

http://rsdn.ru/forum/message/2811970.1.aspx

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

Ну а если ты хочешь его декомментировать и выводить все 12 млн символов — жди


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

Я так полагаю, что при разработке класса StreamReader его тоже трассировали, нет ?

S>так вот зачем писать тривиальный код в котором ты можешь допустить ошибку? в моем примере много ошибок можно допустить? а в примере IT?

А затем, чтобы он с нормальной скоростью работал.

Я все же жду от тебя код, который читает 12 Мб файл за 0.015 сек . На C#. С использованием чего угодно, кроме unmanaged code.

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

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

PD>>Заказчик дал мне CSV файл размером в 100 Мб примерно. Полей в каждой строке примерно 10. Мне надо было отсортировать его по каждому полю, т.е. иметь доступ к строкам этого файла сначала упорядоченно по первому полю, потом по второму и т.д. Дело было 5 лет назад, на машине не то 512, не то 256 Мб памяти.

R>И конечно же время было самим узким местом?

В данной задаче как раз не время, а память.

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

K>Напоминаю: в C# есть foreach, а начиная с версии 2.0 — yield. А в C# 3.0 можно писать вот так:

Ну а в C++ нет foreach, так что при разработке STL на foreach никак нельзя было рассчитывать.

PD>>Вот это серьезный вопрос, но дело здесь не в неправильности. Кто будет собственником этой коллекции ? Иными словами, если класс должен ее сохранить, должен ли он ее уничтожить при своем уничтожении, т.е. в своем деструкторе ? Тут три подхода возможны

K>Какие деструкторы?

Обыкновенные деструкторы в С++. Мы же вроде STL обсуждали, а она на С++, а в нем они есть.

PD>>1. При передаче классу коллекции (да и не коллекции, чего угодно) он ее забирает в собственность. Если надо — делайте копии себе до передачи.

K>Какая собственность? Как у value может быть собственник? Кому принадлежит 1, 2, 3, 42?

Так, теперь я не понимаю. Ты вот это писал

>если методу класса передаётся коллекция, которую он должен где-то внутри класса сохранить, то эту коллекцию (за исключением тех ситуаций, когда и так приемлемо) в целях сохранения инкапсуляции придётся копировать явно.

Коллекций явно в C++ нет, есть, к примеру, список. Если этот список передать в другой класс, который будет его сохранять, то ... 3 моих варианта.

При чем тут какие-то 1, 2, 3, 42?


PD>>2. При передаче классу коллекции он сам делает ее копию, а вашу коллекцию не трогает.

K>Какие копии? value не копируют? Где это видано, чтобы было 2 разные единицы, 5 разных восьмёрок?

Ничего не понимаю. Какие такие value в C++ ?

PD>>3. Расшаривание со счетчиком ссылок.

K>Вот это тема. Можно ещё и GC. Только пофигу. Значения не создают, они есть. Вот есть 1. Я могу это значение записать средствами языка. А есть множество. Пустое множество я тоже могу записать — Set<T>.Empty. А имея множества a и b и элемент e можно записать и такие множества: a | b, a & b, a — b, a.Add(e), a.Remove(e). Где здесь что-то уничтожается или создаётся?


PD>>Все три подхода ИМХО имеют право на существование.

K>Да нет, не все. ИМХО, там где думаю на таком уровне абстракции, чтобы юзать предложенный подход, деструкторам не место.

Слушай,ИМХО разговор какой-то бессмысленный или мы говорим о разных совсем вещах. Ты начинаешь с критики STL, она на С++, а потом вдруг утверждаешь, что деструкторам там не место. Может, на высотах абстракции им там и не место, но в С++ они есть и это факт.

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

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

K>Вот именно в этом и заключается корень Ваших заблуждений. Дело в том, что далеко не всегда нужно бить на строчки 12Гб файл. Чаще всего точно известно, что данной программе никто и никогда не подсунет файл больше 50К (а если и подсунет, тормозить, будет что-нибудь другое, да так, что мало не покажется).

Вот с этим могу и согласиться. Если это действительно точно известно — да. В конце концов не надо ничего до абсурда доводить — файл из 10 строчек как ни читай, все равно будет одно и то же. Но...

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

>Конечно, бывают исключительные ситуации. Но фреймворки для того и создаются, чтобы покрывать 99% тех случаев, на которые они расчитаны. А вот как раз то, что в System.IO куча классов — очень либерально со стороны фреймворка. Потому что при наличии подобной специфической задачи мы не станем юзать другой фреймворк или писать свой велосипед, а заюзаем TextReader или даже Stream, в зависимости от того, насколько низкоуровневым должно быть решение.

K>А делать решение-на-все-случаи жизни — это заведомо неправильный путь,

Именно! Полностью согласен. Если бы эти методы использовались с анализом их применимости (т.е что они попадают в 99%, а не в 1%) — я бы не возражал. Если в файле 10 строк, я тоже игру с mmf устраивать не буду — из пушки по воробьям. Но , увы, я вижу, что для многих (может, не для тебя) никакой анализ применимости попросту не нужен. Есть класс, есть метод — бери. И запустит он TextReader и прочее для парсинга 100 Мб файла, и потратит 300 Мб памяти, и скажет, что так и должно быть. Потому что думать сам он не умеет и не хочет.

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

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

Все же, ответь мне на вопрос, который я уже в десятый раз задаю. Как на C# сделать просмотр текстового файла в 12 Мб за 0.015 сек ? Ладно, пусть это 1%, пусть даже 0.01%, но вот несчастный я такой, попала моя задача в эти 0.01%, и времени больше нет, и памяти больше нельзя использовать ?

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

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

K>>Напоминаю: в C# есть foreach, а начиная с версии 2.0 — yield. А в C# 3.0 можно писать вот так:

PD>Ну а в C++ нет foreach, так что при разработке STL на foreach никак нельзя было рассчитывать.

Вот я и говорю: один из недостатков STL — отсутствие поддержки со стороны языка. Я именно на этот факт и делал акцент.

Кстати, в C# всё равно есть преимущество: не надо юзать вложенный класс при аннотации типа — меньше писанины.

K>>Какие деструкторы?

PD>Обыкновенные деструкторы в С++. Мы же вроде STL обсуждали, а она на С++, а в нем они есть.

Мы обсуждали не STL, а коллекции вообще. Но даже если и так, в C++ от деструкторов можно отказаться. Для этого есть умные указатели. А умельцы даже прикручивают к нему GC.

PD>Коллекций явно в C++ нет, есть, к примеру, список. Если этот список передать в другой класс, который будет его сохранять, то ... 3 моих варианта.

PD>При чем тут какие-то 1, 2, 3, 42?

При том, что я поделился идеей, которую применил в собственной библиотеке. Мы ведь идею обсуждаем? Ну так вот, как я говорил, есть интерфейс IFooReader, классы Foo и FooBuilder. Foo — это наглая эмуляция value-семантики в рамках ОО. Так вот, "экземпляры" класс Foo (на самом деле правильно говорить значения типа Foo) — это такие же метафизические сущности, как и 1, 2, 3, 42. Ну нельзя создать 10 троек (разве что в каких нибудь смолтоках и прочих). Тройка — одна. Её нельзя ни создать, ни уничтожить. Список списков [[1, 2], [9,8], [42, 64]] — тоже нельзя ни создать не уничтожить. В частности, нельзя создать два таких списка. Он один. Можно связать этот список с несколькими именами. Физически, да, может быть хоть 10 списков, но никакой разницы (если явно не проверять object.ReferenceEquals) между ними нету.

PD>Ничего не понимаю. Какие такие value в C++ ?

Их можно эмулировать.

PD>>>3. Расшаривание со счетчиком ссылок.

K>>Да нет, не все. ИМХО, там где думаю на таком уровне абстракции, чтобы юзать предложенный подход, деструкторам не место.

PD>Слушай,ИМХО разговор какой-то бессмысленный или мы говорим о разных совсем вещах. Ты начинаешь с критики STL, она на С++, а потом вдруг утверждаешь, что деструкторам там не место. Может, на высотах абстракции им там и не место, но в С++ они есть и это факт.

Как я уже говорил, в том же C++ можно обходиться без деструкторов.

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

K>>Кстати, ещё одно чисто языковое ограничение: после юзания вложенных функций с замыканиями и лямбд STL-ные функторы юзать вообще не хочется.

FR>

Что-то не понял. Это улыбка в знак поддержки? Или я перепутал, и функторы — в бусте, а не в STL?

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

PD>Вот с этим могу и согласиться. Если это действительно точно известно — да. В конце концов не надо ничего до абсурда доводить — файл из 10 строчек как ни читай, все равно будет одно и то же. Но...

PD>при условии, что это не будет делаться в цикле

Смотря какой цикл и что ещё в нём делается.

PD>при условии. что можно быть уверенным в том. что он никогда не начнет сильно расти...

Условие редкое. Я про это писал.

PD>Именно! Полностью согласен. Если бы эти методы использовались с анализом их применимости (т.е что они попадают в 99%, а не в 1%) — я бы не возражал.

Ну дык. Думаю, тот же IT делает анализ применимости. Вася Пупкин, который полгода назад открыл для себя способ рисовать формочки в Делфях такого анализа не делает. Но внимание! Вася Пупкин и в C++ и STL наворотит такого (свинья везде грязь найдёт). Ну так вот: ради профессионалов вроде IT и проектируются фреймворки, чтобы они могли меньше времени тратить на вещи, которые не критичны (предполагается, что как специалисты, они могут выделить такие ситуации). Что же до ВП — всем пофигу, т.к. ВП спасёт не супермощный фреймворк, а супеполезные книжки.

PD> Если в файле 10 строк, я тоже игру с mmf устраивать не буду — из пушки по воробьям. Но, увы, я вижу, что для многих (может, не для тебя) никакой анализ применимости попросту не нужен. Есть класс, есть метод — бери. И запустит он TextReader и прочее для парсинга 100 Мб файла, и потратит 300 Мб памяти, и скажет, что так и должно быть. Потому что думать сам он не умеет и не хочет.

Ну, я думаю, и в C++ных библиотеках немало граблей, на которые гипотетический ВП может наступить и истратить 300Мб памяти и заставить работать прогу сутками.

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

Именно про то я и говорю. Как раз .NET Framework спроектирован по данному принципу. Не нравятся "высокоуровневые" TextReader, File и т.п., можно юзать Stream. Если слишком много проблем с ручной работой со Stream — BinaryReader тут как тут. Надо буферизацию сделать — нет ничего проще: оборачиваем Stream в BufferedStream.

PD>Все же, ответь мне на вопрос, который я уже в десятый раз задаю. Как на C# сделать просмотр текстового файла в 12 Мб за 0.015 сек ? Ладно, пусть это 1%, пусть даже 0.01%, но вот несчастный я такой, попала моя задача в эти 0.01%, и времени больше нет, и памяти больше нельзя использовать ?

Не знаю, насколько это критично. М.б. не подходит вообще для данной задачи C# (как не подходит, например, для написания драйверов видюх, хотя...). Тут всё зависит от. Будем ли мы писать универсальную функцию для всех кодировок, или нам заранее известна кодировка? Будем ли мы юзать StringBuilder и List, или сами изобретём более быстрый велосипед (в котором, например, Clear не будет физически обращать в 0 всю коллекцию). Надо ли нам возвращать string[], или достаточно будет вернуть буфер и список пар — (начальный индекс, конечный индекс). И т.д.

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

K>Вот я и говорю: один из недостатков STL — отсутствие поддержки со стороны языка. Я именно на этот факт и делал акцент.

Нет, акцент (по крайней мере в том месте, на которое я возразил, был насчет имеенно того, как там итерация делается.

>Когда надо пройтись по коллекции, пишут что-то вроде:
for (list<pair<foo, bar>>::iterator iter = v.begin(); iter != v.end(); ++iter)
Короче, необходимость делать аннотацию типа iter меня убивает.

Вот на это я и возразил сл своим примером с IEnumeraеtor. И только.

K>Мы обсуждали не STL, а коллекции вообще. Но даже если и так, в C++ от деструкторов можно отказаться. Для этого есть умные указатели. А умельцы даже прикручивают к нему GC.

Ну во-первых, умные указатели не панацея, а должны использоваться тогда, когда ни нужны. Использовать их везде и всегда — способ сделать программу непонимаемой, и только. Во-вторых, можно, конечно, перенести уничтожение многого в Release, но это не значит, что тем самым избавишься от деструкторов.

PD>>Коллекций явно в C++ нет, есть, к примеру, список. Если этот список передать в другой класс, который будет его сохранять, то ... 3 моих варианта.

PD>>При чем тут какие-то 1, 2, 3, 42?

K>При том, что я поделился идеей, которую применил в собственной библиотеке. Мы ведь идею обсуждаем? Ну так вот, как я говорил, есть интерфейс IFooReader, классы Foo и FooBuilder. Foo — это наглая эмуляция value-семантики в рамках ОО. Так вот, "экземпляры" класс Foo (на самом деле правильно говорить значения типа Foo) — это такие же метафизические сущности, как и 1, 2, 3, 42. Ну нельзя создать 10 троек (разве что в каких нибудь смолтоках и прочих). Тройка — одна. Её нельзя ни создать, ни уничтожить. Список списков [[1, 2], [9,8], [42, 64]] — тоже нельзя ни создать не уничтожить. В частности, нельзя создать два таких списка. Он один. Можно связать этот список с несколькими именами. Физически, да, может быть хоть 10 списков, но никакой разницы (если явно не проверять object.ReferenceEquals) между ними нету.

Насколько я понял, ты делаешь нечто свое, не в рамках того, о чемя подумал. Вполне допускаю, что ты прав, судить не могу, так как не видел, а по пяти строчкам объяснения судить не буду. Но все это никак не отменяет традиционного

K>Как я уже говорил, в том же C++ можно обходиться без деструкторов.

Теоретически, может быть, и можно (и то не уверен), а практически — зачем ? Если мне не нужны счетчики ссылок и GC, почему их не использовать ? В конце концов , деструктор — просто специфическая функция...

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

KP>>Кстати, а что такое "до диез"?
LVV>С# в музыкальной нотации называется До диез.
Вы музыке учите или все таки программированию.
Если программированию то извольте правильно называть то, чему учите.

Здравствуйте, <Аноним>, Вы писали:

А> Интересно, этот маленький смешной человечек, проявивший просто предельную неадекватность, собрался тут поучать *меня*? Ржунимагу!
Ты б хоть представился...

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

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

IT> А вот то что я решаю это всё в одну строку — это огромный плюс, потому что строк у меня таких не одна, а десятки тысяч и увеличение объёма кода в 33 раза, как в твоём случае для меня неприемлемо. Я не из тех, кто любит хвастаться проектами в миллионы бестолковых строк.
А что тебе мешает написать библиотеку для С++. Или просто класс-хелпер в проекте.
Если поставить С# и С++ в одинаковое положение просто сравняв возможности библ, которые идут с ними "по умолчанию" то окажется что разница то между ними в колве кода совсем маленькая.

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

K>.. Но внимание! Вася Пупкин и в C++ и STL наворотит такого (свинья везде грязь найдёт)..

С++ отличается тем, что вероятность написать на нём неработающую программу выше Т.е. на С++ Вася не наворотит — оно падать будет, это заставит его более плотно изучить предмет и именно так, в принудительном порядке, пойдёт процесс обучения.

Но после того, как Вася научился думать, не вижу смысла заставлять его писать на C++ и дальше. Да и способов научиться думать есть несколько, С++ и тут не серебрянная пуля.