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

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

У меня кстати работала, но я что-то на автомате подправил, что не помню

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

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

SH>кроме того, некоторые встроенные возможности C# С++ может только с трудом эмулировать.
Ну, под разные задачи, в разное время созданные, с разным рантаймом.
Ждем выхода следующей ревизии С++.

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


S>

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

Хм, а при чем тут UTF8 ? Я ведь программу писал для Юникода, а не для UTF8! Для того Юникода, в котором на каждый символ ровно по 2 байта, а в начале стоит FEFF. Естественно, на UTF8 я не рассчитывал.

Вот мой файл, проверь на нем. Он маленький, если хочешь, загрузи его в Notepad и увеличь путем Copy-Paste. Я из него таким образом делал пример1.txt.

http://files.rsdn.ru/187/%d0%9f%d1%80%d0%b8%d0%bc%d0%b5%d1%80.txt

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


S>

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

Может, он и из MSDN... Я его слегка модифицировал — вместо UTF8Encoding поставил UnicodeEncoding (это не принципиально, надеюсь ?) и в качестве файла взял пример.txt из трех строчек, о котором уже писал, длина его 56 байт

            using (FileStream fs = File.OpenRead("D:\\Пример2.txt"))
            {
                string s;
                int read;
                byte[] b = new byte[1024];
                UnicodeEncoding temp = new UnicodeEncoding();
                while ((read = fs.Read(b, 0, b.Length)) > 0)
                {
                    s = temp.GetString(b);
                    int len = s.Length;
                    Console.WriteLine(len);
                }
            }

read = 56, а len почему-то 512, цикл выполняется один раз. Я что-то не так делаю ?

И , кстати, маленький вопрос. Что здесь будет, если длина строки окажется больше 512 символов (1024 байт) ?

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

PD>>А как на C# ?

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

Ну спасибо. Я пару строчек на __asm минут за 10 напишу. А ты предлагаешь мне засесть за изучение COM (предположим, я его не знаю), да еще и на неизвестном мне (допустим) C++. На это минимум неделя — две понадобится, и это очень оптимистичная оценка.

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

LVV>А не подскажете, как перевести значок "решетка" на русский язык?
переводить его не надо, названия не переводятся.
Более менее распространенные названия: решетка и диез
Но тогда уже "Си диез", но не "До диез"...

LVV>Или просто С-решетка говорить?
http://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29
Поскольку это название языка программирования то называть его стоит так, как назвали авторы.
Кроме того следует помнить о compatibility с остальным сообществом.

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

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

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

SH>По той же схеме. Пишем COM-компонент на С++ и используем его из C#.
И затраты на вызовы хавают почти весь выигрыш?

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

SH>Я писал именно про _встроенные_возможности_языка_ отвечая тов. CreatorCray, который предложил исключить их из рассмотрения.
Трудно отнести чтение файла построчно к встроенным возможностям языка. Это хэлпер.

SH>А в юниксе? А на микроконтроллере?
SH>С этой точки зрения плюсом С/С++ безусловно будет более простая интеграция с API существующих ОС. Это не удивительно, они все написаны именно в эпоху C. С# же компенсирует это более богатой стандартной библиотекой.
Которая нифига не переносима в полном объеме, если уж упоминали контроллеры и т.п. Потому как Windows Specific. Жалкую попытку порта под названием Mono — даже не упоминайте.
Впрочем и С++ стандартные библиотеки не везде могут быть реализованы.

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

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

Да зачем мне обижаться, если имеет место просто недоразумение UTF8 — Unicode. Конечно, не работает, ну не для этого типа файлов она сделана

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

CC>Ну дык сравнивали вроде как языки а не библиотеки.

Сравнивали комплекс сущностей, доступный в ощущениях программисту при использовании языка. Библиотеки туда входят.

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

Ну и что?

CC>Ну, под разные задачи, в разное время созданные, с разным рантаймом.

Отлично! Ты тоже с этим согласен. И я тоже считаю, что "под разные задачи, в разное время созданные". И считаю, что время изменилось и теперь задачи C# более актуальны. И что время C++ потихоньку уходит. И не понимаю, как ты, придерживаясь того же мнения можешь отстаивать преимущества С++.

Конечно, есть области, где C# отстанет. Но если он покрывает 99%..

CC>Ждем выхода следующей ревизии С++.

Жди. Я уже не жду.

Я боюсь, что следующая ревизия превратит С++ в язык, который плохо справляется со своими текущими задачами (из-за изменений), и плохо с новыми (из-за обратной совместимости). Поэтому я думаю переходить на более другие языки.

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

FR>У меня кстати работала, но я что-то на автомате подправил, что не помню

А время не замерил ? Интересно бы узнать. Вообще-то оно еще и от диска зависит, но для этого надо файл размером в сотню Мб взять, 0.015 — слишком мало для выводов.

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

PD>Ну спасибо. Я пару строчек на __asm минут за 10 напишу.

Так, а если ты асм не знаешь? Вообще не знаешь?

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

CC>ICC 10.1.x ?

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

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

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

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

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

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

А class Thread — это прямо таки свойство языка ?

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

Нет, верно. Можно без труда сделать, в MFC есть, к примеру.

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

SH>При чём здесь Windows??

При том, что memory-mapped files есть базовый механизм Windows. Он там везде и всюду, это единственный метод доступа к файлам в конечном счете. В Юниксе, насколько мне известно, это не так, да и вообще их там вроде нет.


SH>А в юниксе? А на микроконтроллере?

Если тебе известно что-то про mmf на микроконтроллере, поделись

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

И в нем нет средств доступа к возможностям ОС, если они не инкапсулированыы этой библиотекой.

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

CC>И затраты на вызовы хавают почти весь выигрыш?

Аналогичный вопрос для асма: и вызов функции (параметры в стек, сброс конвейера) сожрут весь выигрыш?
Нет, просто надо знать что, где и как оптимизировать.

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

CC>Трудно отнести чтение файла построчно к встроенным возможностям языка. Это хэлпер.

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

CC>Которая нифига не переносима в полном объеме, если уж упоминали контроллеры и т.п. Потому как Windows Specific. Жалкую попытку порта под названием Mono — даже не упоминайте.

Плохо переносится GUI часть. Остальное, имхо, перенести можно.

CC>Впрочем и С++ стандартные библиотеки не везде могут быть реализованы.

Действительно. Особенно если добавить к ним MMF и MFC, о которых говорит Павел.

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

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

PD>>Ну спасибо. Я пару строчек на __asm минут за 10 напишу.

SH>Так, а если ты асм не знаешь? Вообще не знаешь?

Ну что же, пусть так. Посчитаем.

C++ . Мне надо изучить asm. Никуда не денешься, эти MMX/SSE иначе не напишешь.
C#. Мне надо изучить asm (все равно надо), COM (знать о нем не хотел бы, да придется), C++ (тоже придется)

3:1 не в твою пользу

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

PD>Хм, а при чем тут UTF8 ? Я ведь программу писал для Юникода, а не для UTF8! Для того Юникода, в котором на каждый символ ровно по 2 байта, а в начале стоит FEFF. Естественно, на UTF8 я не рассчитывал.
Т.е. для UTF16 если его BOM = FEFF. Вот только незадача, у UTF16 символ может состоять из более чем 1 WORD-a. Двубайтовый "Уникод" с одним словом на символ это упрощенная (устаревшая) версия и называется UCS2. Работать с ней правда гораздо удобнее...
Воскуривать тут http://en.wikipedia.org/wiki/UCS2

Ну а полноценный Unicode это UTF32.
Вообще еще стоит покурить тут: http://www.unicode.org/standard/WhatIsUnicode.html , но после воскуривания начинаешь понимать что полноценный unicode это ужасный гемор на самом деле...

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

PD>Ну что же, пусть так. Посчитаем.

Не, ты не понял. Я не рекомендую на C# решать задачи, в которых нужен SSE. Я указал на способ повышения производительности — обращение к более подходящему для задачи языку, и на то, что C++ этот способ тоже использует.