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

CC>Если поставить С# и С++ в одинаковое положение просто сравняв возможности библ, которые идут с ними "по умолчанию" то окажется что разница то между ними в колве кода совсем маленькая.

но ведь по факту библиотеки не равны
кроме того, некоторые встроенные возможности C# С++ может только с трудом эмулировать.

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

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

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

Тогда надо заставлять Васю Пупкина писать на Хаскелле. Пока он разберётся, как хоть что-нибудь написать, он пройдёт процесс обучения.

А вообще, ставить вопрос "учить ли Яве или нет" некорректно. Учить. Можно даже выбрать её как первый язык. Но учить надо вообще разным вещам. Ведь программиста учат ещё и матекматике, физике, философии, наконец. Так почему по профильным дисциплинам должная фигурировать только Ява?

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

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

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

Я пишу на C# и стараюсь избавиться от IDiposable и финализаторов везде, где возможно. Если пишу интероп, то организую пул unmanaged-объектов и т.п. Т.е. оставляю явное управление ресурсами там, где это действительно необходимо.

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

Традиционное не отменяется — есть ListBuilder, SetBuilder, MapBuilder — полностью аналогичные std::vector, std::set, std::map. Если ситуация специфическая и мы должны юзать деструкторы — то можно использовать только эти классы. Если же мы остаёмся в рамках автоматического управления ресурсами, то получаем бонус в виде List, Set, Map.

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

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

Ну а там, где без них никак? Какая-нибудь трёхэтажная алгоритмика, где передаётся список MultiMap-ов с Set-ов на List'ы?

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

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

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

+1

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

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

Чаще редкое. я бы так сказал...

K>Ну дык. Думаю, тот же IT делает анализ применимости.

Вообще-то он прямо сказал, что его не интересует, как оно там внутри устроено...

>Вася Пупкин, который полгода назад открыл для себя способ рисовать формочки в Делфях такого анализа не делает. Но внимание! Вася Пупкин и в C++ и STL наворотит такого (свинья везде грязь найдёт).

См. ответ SergH, мне нечего больше добавить.

>Ну так вот: ради профессионалов вроде IT и проектируются фреймворки,

Эх, если бы... Тогда я и говорить ничего не стал бы. Беда именно в том, что эти фреймворки ну прямо-таки как будто специально созданы для полупрофессионалов. Найди класс, найди метод — вперед. Так большинство и работает. Дедлайн на носу, времени разбираться нет, способ сделать есть — вперед. И вот поэтому я и встрял в эту дискуссию, тема которой "Раннее знакомство с Java калечит судьбы программистов" . Сначала надо научиться самому писать, а потом уж использовать готовые фреймворки. Иначе их использование будет по принципу черного ящика — со всеми вытекающими.


>чтобы они могли меньше времени тратить на вещи, которые не критичны (предполагается, что как специалисты, они могут выделить такие ситуации). Что же до ВП — всем пофигу, т.к. ВП спасёт не супермощный фреймворк, а супеполезные книжки.

Опять-таки если бы... Потому как книжки по той же Java и C# большей частью именно тому и посвящены, как этот фреймворк использовать. Не говорю — все книги, но большинство. А до тех, которые действительно рассматривают детали реализации, ВП либо вообще не доберется, либо доберется тогда, когда уже поздно будет, так как он написал уже тысячи строк кода вышеизложенным методом. Прочтет он теперь полезную книжку, где говорится, что он многое делал не так и что ? Думаешь, пересмотрит свои воззрения ? Черта с два, просто отложит эту книгу в сторону с мыслю — придумывают тут всякое, писал раньше код, заказчик не жаловался, и дальше писать буду.

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

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

Matrix trans = mSrc.Transpose();

то и ничего не скажешь. Хорошо, если там найдется метод, который на месте делает. Так ведь прямоугодьную матрицу на месте не транспонируешь, будут авторы FW специально этим частным случаем заниматься . Память сейчас не ресурс, new вам в руки и вперед, а старую матрицу со временем GC приберет

Вот тебе другой пример, который IT привел

return File.ReadAllText("filename.ext").Split('\n')[n];

Для меня тут несколько светофоров с красным светом поставлено. ReadAllText — это что, чтение целиком ? Куда ? В один буфер построчно ? Да нет, иначе какой потом Split ? Значит, в один буфер ? А это надо ? Зачем мне весь файл в память переводить, если одна строка нужна, хоть и последняя. Второй светофор — Split ? Он мне массив строк вернет ? Размер какой данных у этого массива ? Опять целый файл ? Да еще и выделение памяти на каждую строку. А строку как там делают ? Тут я уже не знаю, надо исходники смотреть. Смотрю — посимвольно в StringBuilder добавляют. Бррр... И все ради одной последней строки ? При том, что суть задачи разбора по строкам банальна — иди по файлу, ищи CR/LF... А последнюю строку , кстати, и вообще просто можно получить — прочитать , скажем, 1024 байта в конце файла и искать предпоследний CR/LF задним ходом. Найдем — задача решена. Не найдем — еще 1 Кб прочитаем и т.д. За нулевое время от размера файла задача решается и с затратами памяти в 1 Кб + размер строки.

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

И все же, как насчет 0.015 сек ? . Не выйдет ведь и со Stream. Потому что здесь вообще в/в неприменим, не даст он такой скорости даже на C++. Слишком много лишних действий.

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

K>Не знаю, насколько это критично. М.б. не подходит вообще для данной задачи C#

Боюсь, что да.

>(как не подходит, например, для написания драйверов видюх, хотя...).

А вот этот аргумент не пойдет. Для написания драйверов он не годится не потому, что в нем что-то не так, а потому, что в драйверах управляемый код не используется. Тут и говорить не о чем. По крайней мере сейчас.

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

Вот именно. Я ведь не противник отнюдь Явы и C#. То, что ты сейчас написал, и есть анализ . Анализ того, насколько это будет быстро, какие ресурсы использоваться будут, есть ли тут лишние действия и можно ли их убрать (а убирание их, возможно, приведет к очень серьезной перестройке). Если такой анализ будет делаться — да пишите потом хоть на Basic . Беда в том, что он многими не будет делаться, и более того, они заявляют, что это и не надо.

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

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

K>Я пишу на C# и стараюсь избавиться от IDiposable и финализаторов везде, где возможно. Если пишу интероп, то организую пул unmanaged-объектов и т.п. Т.е. оставляю явное управление ресурсами там, где это действительно необходимо.

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

K>Традиционное не отменяется — есть ListBuilder, SetBuilder, MapBuilder — полностью аналогичные std::vector, std::set, std::map. Если ситуация специфическая и мы должны юзать деструкторы — то можно использовать только эти классы. Если же мы остаёмся в рамках автоматического управления ресурсами, то получаем бонус в виде List, Set, Map.

Если действительно выложишь — напомни. Будет время (эх, если будет) — посмотрю. Любопытно.

K>Ну а там, где без них никак? Какая-нибудь трёхэтажная алгоритмика, где передаётся список MultiMap-ов с Set-ов на List'ы?

Вполне возможно, что в твоей системе классов это и есть лучшее решение

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

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

SH>но ведь по факту библиотеки не равны
SH>кроме того, некоторые встроенные возможности C# С++ может только с трудом эмулировать.

А не наоборот ? Те же mmf, которые на С++ делаются элементарно, но C# можно только через PInvoke использовать, а потом непонятно. что с полученным указателем делать, так как бестиповый доступ к данным на C# противоречит его сути...

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

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

KP>>>Кстати, а что такое "до диез"?
LVV>>С# в музыкальной нотации называется До диез.
CC>Вы музыке учите или все таки программированию.
CC>Если программированию то извольте правильно называть то, чему учите.
А не подскажете, как перевести значок "решетка" на русский язык?
Или просто С-решетка говорить?
"С sharp" промпт перевел как "С острый" — это лучше?
На обложке книжки Павловской по С# изображен гитарный аккорд До диез...
Кстати, иногда его неверно называют Си-диез.

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

PD>Вообще-то он прямо сказал, что его не интересует, как оно там внутри устроено...

А после этого он ещё что-то про гигабайты говорил
Не, утверждение о том, что IT адекватен я рассматриваю как доказанное, я его живого лично видел

PD>Эх, если бы... Тогда я и говорить ничего не стал бы. Беда именно в том, что эти фреймворки ну прямо-таки как будто специально созданы для полупрофессионалов. Найди класс, найди метод — вперед.

Да. Но не понятно, как бы так сделать фреймворк, чтобы его только правильные люди использовали — он всем даёт преимущества, а "доброта" C# до времени скрывает ошибки, котрые сразу вылезли бы в C++. Хаскель, на самом деле, выход Его даже просто использовать — голову сломаешь.

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

PD>Matrix trans = mSrc.Transpose();

PD>то и ничего не скажешь. Хорошо, если там найдется метод, который на месте делает. Так ведь прямоугодьную матрицу на месте не транспонируешь, будут авторы FW специально этим частным случаем заниматься . Память сейчас не ресурс, new вам в руки и вперед, а старую матрицу со временем GC приберет

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

PD>И все же, как насчет 0.015 сек ? . Не выйдет ведь и со Stream. Потому что здесь вообще в/в неприменим, не даст он такой скорости даже на C++. Слишком много лишних действий.

Несложно найти задачу, с которой не справится и С. Потому что она без явного использования SSE2/3/4 не решается, а компилятор так оптимизить не умеет. Ну и что?

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

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

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

FR>>

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

Встретил собрата по несчастью

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

PD>А не наоборот ?

yield, foreach, лямбды.
потоки, наконец.

PD>Те же mmf, которые на С++ делаются элементарно, но C# можно только через PInvoke использовать, а потом непонятно. что с полученным указателем делать, так как бестиповый доступ к данным на C# противоречит его сути...

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

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

K>А вообще, ставить вопрос "учить ли Яве или нет" некорректно. Учить. Можно даже выбрать её как первый язык. Но учить надо вообще разным вещам. Ведь программиста учат ещё и матекматике, физике, философии, наконец. Так почему по профильным дисциплинам должная фигурировать только Ява?

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

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


PD>return File.ReadAllText("filename.ext").Split('\n')[n];

PD>Для меня тут несколько светофоров с красным светом поставлено. ReadAllText — это что, чтение целиком ? Куда ? В один буфер построчно ? Да нет, иначе какой потом Split ? Значит, в один буфер ? А это надо ? Зачем мне весь файл в память переводить, если одна строка нужна, хоть и последняя. Второй светофор — Split ? Он мне массив строк вернет ? Размер какой данных у этого массива ? Опять целый файл ? Да еще и выделение памяти на каждую строку. А строку как там делают ?

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

print sum((1 for _ in file("input.txt")))

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

SH>А после этого он ещё что-то про гигабайты говорил
SH>Не, утверждение о том, что IT адекватен я рассматриваю как доказанное,

Я не говорил, что он неадекватен

>я его живого лично видел

А это не доказательство

SH>Да. Но не понятно, как бы так сделать фреймворк, чтобы его только правильные люди использовали — он всем даёт преимущества,

И недостатки

>а "доброта" C# до времени скрывает ошибки, котрые сразу вылезли бы в C++.

Добрые мы все за чужой (заказчика) счет. Ох, добрые...


>Хаскель, на самом деле, выход Его даже просто использовать — голову сломаешь.




PD>>И все же, как насчет 0.015 сек ? . Не выйдет ведь и со Stream. Потому что здесь вообще в/в неприменим, не даст он такой скорости даже на C++. Слишком много лишних действий.

SH>Несложно найти задачу, с которой не справится и С. Потому что она без явного использования SSE2/3/4 не решается, а компилятор так оптимизить не умеет. Ну и что?

Это вообще-то не свойство C, а свойство компилятора.

Если компилятор не умеет генерировать некий набор команд, ну что же... Для SSE я, правда, не писал, только для MMX, лет 8 назад.

    _asm
    {
        mov        eax, 32768
        movd        mm5, eax
        psllq        mm5, 32
        movd        mm7, eax
        paddd        mm5, mm7

А как на C# ?

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

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

PD>>А не наоборот ?

SH>yield, foreach, лямбды.

Да, технические проблемы могут быть, но не фатально это.

SH>потоки, наконец.

А они куда девались ? _beginthreadex и т.д.

PD>>Те же mmf, которые на С++ делаются элементарно, но C# можно только через PInvoke использовать, а потом непонятно. что с полученным указателем делать, так как бестиповый доступ к данным на C# противоречит его сути...

SH>mmf это же не встроенная возможность Это библиотека.

Это не библиотека. Это базовый механизм Windows. Это то, что будет всегда в Windows при обращении к любому файлу любым способом. И вопрос лишь в том, сделаю ли это я сам явно (и потрачу при этом минимум времени и памяти) или это сделает Windows (кэш ФС, загрузка DLL и т.д.) и потратит сама вообще-то столько же, но вот я после этого еще добавлю на ввод/вывод как он в языке понимается

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

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

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

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

вот как работает закоментированный вариант ...

Unhandled exception at 0x004114da in txt.exe: 0xC0000005: Access violation reading location 0x015d6000.

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

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

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

возможно, самое главное — это делал не я и мне это уже не придется делать ...

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

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

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

очень хотелось сначала получить работающий пример на С++/С
ну а пока трассируешь, можешь еще и вот этот пример из мсдн-а проверить

        using (FileStream fs = File.OpenRead(path)) 
        {
            byte[] b = new byte[1024];
            UTF8Encoding temp = new UTF8Encoding(true);
            while (fs.Read(b,0,b.Length) > 0) 
            {
                Console.WriteLine(temp.GetString(b));
            }
        }

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

PD>Это вообще-то не свойство C, а свойство компилятора.

Ну так и "Слишком много лишних действий" не свойство C#.

PD>Если компилятор не умеет генерировать некий набор команд, ну что же... Для SSE я, правда, не писал, только для MMX, лет 8 назад.

PD>

PD>    _asm
PD>    {
PD>        mov        eax, 32768
PD>        movd        mm5, eax
PD>        psllq        mm5, 32
PD>        movd        mm7, eax
PD>        paddd        mm5, mm7                

PD>

PD>А как на C# ?

По той же схеме. Пишем COM-компонент на С++ и используем его из C#.

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

FR>Тут конечно да все криво и в лоб но почти совпадающий с этим код вполне может все делать лениво ничего лишнего не выделяя, например на питоне:
FR>

FR>print sum((1 for _ in file("input.txt")))
FR>

Комментировать не могу, ибо со змеенышем не знаком, но ИМХО опять-таки не мешало бы знать детали реализации. Если реализация "правильная" — почему бы и нет ?

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

>>Вася Пупкин, который полгода назад открыл для себя способ рисовать формочки в Делфях такого анализа не делает. Но внимание! Вася Пупкин и в C++ и STL наворотит такого (свинья везде грязь найдёт).

PD>См. ответ SergH, мне нечего больше добавить.

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

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

SH>>потоки, наконец.

PD>А они куда девались ? _beginthreadex и т.д.

А это не свойство языка. Это библиотека.

Весь остальной язык на потоки не расчитан. В стандартной библиотеке кроме этих beginthreadex вообще ничего нет — ни средств синхронизации, ни средств общения потоков.

PD>Это не библиотека. Это базовый механизм Windows.

При чём здесь Windows??
А в юниксе? А на микроконтроллере?

Я писал именно про _встроенные_возможности_языка_ отвечая тов. CreatorCray, который предложил исключить их из рассмотрения.
С этой точки зрения плюсом С/С++ безусловно будет более простая интеграция с API существующих ОС. Это не удивительно, они все написаны именно в эпоху C. С# же компенсирует это более богатой стандартной библиотекой.

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

S>вот как работает закоментированный вариант ...
S>

S>Unhandled exception at 0x004114da in txt.exe: 0xC0000005: Access violation reading location 0x015d6000.

Дай текстовый файл. Можно и меньшего размера.