Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, IT, Вы писали:
PD>Ну тогда, видимо, в Microsoft и Sun очень криворукие программисты . PD>В C (даже не С++) весь практически файловый (и не только) ввод/вывод можно сделать на полутора десятках функций из stdio.h, ну а там где не хватит, придется кое-что из io.h брать. . Если инкапсулировать их, то 2 класса получится. В крайнем случае еще Win32 добавим — еще пара десятков функций.
Абсолютно согласен! PD>А теперь берем C# PD>Ну можно и в Яву заглянуть. Тут побольше будет. PD>(Взял как есть из документации, так что если что-то лишнее попало — не ругайте. Суть дела это не изменит).
Я когда первый раз с Явой знакомился, все удивлялся абсолютному отсутствию систематичнсти во вводе-выводе. Большая куча не понять чего. Очень мне не понравилось.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[7]: Раннее знакомство с Java калечит судьбы программистов
Здравствуйте, sndanil, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>А теперь берем C#
PD>>Directory PD>>DirectoryInfo PD>>DriveInfo PD>>File PD>>FileInfo PD>>FileStream PD>>BufferedStream PD>>FileSystemInfo PD>>BinaryReader PD>>BinaryWriter PD>>StreamReader PD>>StreamWriter PD>>TextReader PD>>TextWriter
S>значит ли это что когда ты будешь писать в файл, то тебе придется использовать все эти классы?
Может, и не придется, но для того чтобы писать в файл грамотно, я должен знать, что именно использовать или можно то, что первым попадется ? Вот скажи просто так, не раздумывая, что лучше :
FileStream
public override int Read (
[InAttribute] [OutAttribute] byte[] array,
int offset,
int count
)
или
BinaryReader
public virtual byte[] ReadBytes (
int count
)
при условии, что ты начинающий программист на C#.
А на C тут и думать нечего : fread и все. Хоть в байтовый массив, хоть в небайтовый, хоть не в массив вообще.
> ... что бы действительно сравнить, просто набросай пример и все станет ясно ...
Вот и набросаю, а потом мне скажут, что я не тот метод использовал...
Думаешь, утрирую ? Отнюдь.
Вот тебе пример из моей личной практики, правда, Ява, а не C#
) порекомендовал PrintWriter. Я бы сам ни за что не догадался, разве что потратил бы несколько дней на изучение исходников всех стримов, ридеров, райтеров и т.д.
With best regards
Pavel Dvorkin
Re[6]: Раннее знакомство с Java калечит судьбы программистов
От:
Аноним
Дата:
25.01.08 11:32
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я ничего не забыл ? Да, еще с десяток exception-классов. Ну нельзя же конец файла обработать иначе, как не создав для этой цели EndOfStreamException PD>
Гнусная клевета. Достаточно проверки на null.
Re[8]: Раннее знакомство с Java калечит судьбы программистов
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Может, и не придется, но для того чтобы писать в файл грамотно, я должен знать, что именно использовать или можно то, что первым попадется ? Вот скажи просто так, не раздумывая, что лучше :
точно тебе говорю, не придется
PD>FileStream
PD>public override int Read ( PD> [InAttribute] [OutAttribute] byte[] array, PD> int offset, PD> int count PD>)
или StreamReader
PD>при условии, что ты начинающий программист на C#.
да, поначалу это не очевидно ...
PD>А на C тут и думать нечего : fread и все. Хоть в байтовый массив, хоть в небайтовый, хоть не в массив вообще.
думать ты начинаешь банально, когда те этим fread надо будет считать текст из файла в юникоде или в строго указанной кодировке ... особенно как ты гришь начинающему программисту, то вообще раздолье для раздумий
>> ... что бы действительно сравнить, просто набросай пример и все станет ясно ... PD>Вот и набросаю, а потом мне скажут, что я не тот метод использовал... PD>Думаешь, утрирую ? Отнюдь.
верю, сталкивался с таким и не раз ... ты главное попробуй (пример прочтения юникодного текстового файлы с выводом на консоль), беда ведь в том, что именно ты утверждаешь, что на шарпе будет больше писанины ... вот и убеди ...
Re[9]: Раннее знакомство с Java калечит судьбы программистов
Здравствуйте, sndanil, Вы писали:
S>да, поначалу это не очевидно ...
Вот именно. И не только поначалу, поскольку в любом пакете этих классов намного больше, чем сущностей.
PD>>А на C тут и думать нечего : fread и все. Хоть в байтовый массив, хоть в небайтовый, хоть не в массив вообще.
S>думать ты начинаешь банально, когда те этим fread надо будет считать текст из файла в юникоде или в строго указанной кодировке ... особенно как ты гришь начинающему программисту, то вообще раздолье для раздумий
Да о чем тут думать-то ? fgetws . Или fread (ей кодировки до лампочки) и MultiByteToWideChar или наоборот, WideCharToMultiByte.
>>> ... что бы действительно сравнить, просто набросай пример и все станет ясно ... PD>>Вот и набросаю, а потом мне скажут, что я не тот метод использовал... PD>>Думаешь, утрирую ? Отнюдь.
S>верю, сталкивался с таким и не раз ... ты главное попробуй (пример прочтения юникодного текстового файлы с выводом на консоль), беда ведь в том, что именно ты утверждаешь, что на шарпе будет больше писанины ... вот и убеди ...
Да уж...
int _tmain(int argc, _TCHAR* argv[])
{
setlocale(LC_ALL, "Russian_Russia.866");
wchar_t szLine[100];
FILE * f = _wfopen(L"D:\\Пример.txt", L"rb");
for( int i = 0; i < 3; i++)
{
fgetws(szLine,100,f);
wprintf(L"%s", i == 0 ? szLine + 1 : szLine);
}
fclose(f);
return 0;
}
В файле Пример.txt лежат 3 юникодные строки.
Только не надо флейм устраивать насчет того, почему я уверен, что 100 символов хватит.
Обращаю внимание — я не заводил никаких промежуточных буферов . Здесь нет ни одного массива, кроме, конечно, самого файла как проекции в память. Здесь меня совершенно не волнует длина строки — будь там в файле хоть одна строка на 100 Мб
Повтори на C#, please
With best regards
Pavel Dvorkin
Re[9]: Раннее знакомство с Java калечит судьбы программистов
S>верю, сталкивался с таким и не раз ... ты главное попробуй (пример прочтения юникодного текстового файлы с выводом на консоль), беда ведь в том, что именно ты утверждаешь, что на шарпе будет больше писанины ... вот и убеди ...
Уточнение. Не писанины на шарпе больше будет. а классов и прочих сущностей будет. Лишних действий меньше будет. Памяти расходоваться меньше будет. Быстрее работать будет.
Писанины, может, и меньше будет, если использовать классы, а не писать их.
Напиши свой вариант той же самой задачи. И давай попробуем на текстовом Юникодном файле размером так в 10-20 Мб.
Кстати, почему в C# большинство классов ввода/вывода sealed ? Чем им не угодит, если я наследника сделаю и кое-что там переопределю ? В С++ это никогда не запрещено.
With best regards
Pavel Dvorkin
Re[10]: Раннее знакомство с Java калечит судьбы программисто
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>Количество классов в количестве раз в 5 превышающим реально необходимое от языка не зависит. Это зависит от радиуса кривизны ручек. PD>Ну тогда, видимо, в Microsoft и Sun очень криворукие программисты .
Ну как бы обратного пока никто не доказал. Впрочем, как и не доказано это самое утверждения.
PD>В C (даже не С++) весь практически файловый (и не только) ввод/вывод можно сделать на полутора десятках функций из stdio.h, ну а там где не хватит, придется кое-что из io.h брать. . Если инкапсулировать их, то 2 класса получится. В крайнем случае еще Win32 добавим — еще пара десятков функций.
"В огороде бузина, а в Киеве дядька". Мы сравниваем стандартные библиотеки или написанный с помощью этих библиотек код? К библиотекам и фреймворкам предъявляются совершенно другие требования. В частности имено из-за бедности, я бы даже сказал из-за нищеты, стандартных библиотек C/C++, каждая уважающая себя C++ библиотека реализует в том или ином виде свой собственный класс XXXString. Да и вообще это первопричина всей той вакханалии с библиотеками, которая свирепствует в C/C++.
Но вернёмся к файлам, чтобы продемонстрировать всю нелепость сравнения теплого с мягким. Неважно сколько классов в стандартной библиотеке, важно сколько кода у меня получится после пременения всего этого добра. Вот так, например, в одну строчку я могу решить задачу чтения строки из небольшого файла по номеру:
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Может, и не придется, но для того чтобы писать в файл грамотно, я должен знать, что именно использовать или можно то, что первым попадется ? Вот скажи просто так, не раздумывая, что лучше :
Лучше скажи, что лучше memset или setmem?
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Раннее знакомство с Java калечит судьбы программисто
Здравствуйте, kaa.python, Вы писали:
А>>Судя по всему Вы преподаватель. Тогда откуда эта терминология — препод, прога, до диез....? Вы же уподобляетесь недоучкам. 2- KP>Кстати, а что такое "до диез"?
С# в музыкальной нотации называется До диез.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[9]: Раннее знакомство с Java калечит судьбы программистов
Здравствуйте, Аноним, Вы писали:
А>Судя по всему Вы преподаватель. Тогда откуда эта терминология — препод, прога, до диез....? Вы же уподобляетесь недоучкам. 2-
А что, преподы — не люди? Им жаргон запрещено использовать?
Поработайте преподом...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[7]: Раннее знакомство с Java калечит судьбы программистов
IT>Прошу заметить, что этот код абсолютно корректно обработает все исключительные ситуации и выбросит вменяемые исключения.
IT>Маэстро может привести свой вариант на C/C++, а мы посмотрим.
Уж не знаю что ответит Маєстро, но Ваш варинт можно немного упростить
Вот! Даже этот код можно упростить. И всё благодаря стандартным библиотекам. А на плюсах нам сейчас начнут возить указателями по памяти, надеясь где-нибудь нечаянно не промахнуться. В лучшем случае изобретут гору трёхколёсных велосипедов.
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: Раннее знакомство с Java калечит судьбы программистов
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>В C (даже не С++) весь практически файловый (и не только) ввод/вывод можно сделать на полутора десятках функций из stdio.h, ну а там где не хватит, придется кое-что из io.h брать. . Если инкапсулировать их, то 2 класса получится. В крайнем случае еще Win32 добавим — еще пара десятков функций.
IT>"В огороде бузина, а в Киеве дядька". Мы сравниваем стандартные библиотеки или написанный с помощью этих библиотек код? К библиотекам и фреймворкам предъявляются совершенно другие требования. В частности имено из-за бедности, я бы даже сказал из-за нищеты, стандартных библиотек C/C++, каждая уважающая себя C++ библиотека реализует в том или ином виде свой собственный класс XXXString.
А нельзя ли объяснить, какое отношение XXXString имеет к вводу/выводу ? Подмена объекта обсуждения — не лучший способ дискутировать. Что же касается string — я думаю, не надо объяснять, что он есть в STL, примерно с теми же возможностями, что и в C#.
>Да и вообще это первопричина всей той вакханалии с библиотеками, которая свирепствует в C/C++.
И в чем эта вакханалия заключается, если не секрет ? Что-то мы до сих пор ее как-то не замечали...
IT>Но вернёмся к файлам, чтобы продемонстрировать всю нелепость сравнения теплого с мягким. Неважно сколько классов в стандартной библиотеке, важно сколько кода у меня получится после пременения всего этого добра. Вот так, например, в одну строчку я могу решить задачу чтения строки из небольшого файла по номеру:
IT>
IT>Прошу заметить, что этот код абсолютно корректно обработает все исключительные ситуации и выбросит вменяемые исключения.
IT>Маэстро может привести свой вариант на C/C++, а мы посмотрим.
Печально, что дискуссия уходит в другую сторону. Я ведь не о том говорил, сколько кода получится, а о том, что в классах имеется избыточность, которая приводит к тому, что одно и то же можно сделать разными способами, а какой из них лучше — трудно сказать. Но раз уж ты перевел на это дело — изволь.
Да, твой код выглядит очень просто. Мой будет несколько сложнее, поскольку такого класса под руками нет. Могу написать, а впрочем, уже написал почти — см. http://rsdn.ru/forum/message/2811970.1.aspx
, легкая модификация его даст то, что ты хочешь, ну а что касается исключительных ситуаций — то в самом чтении строки их попросту не будет (кроме недопустимого номера, конечно), а что касается открытия файла и т.д. — это я не сделал там, но это работы на 5 минут. Инкапсулировать этот код в класс проблемы не составит.
Еще раз обращаю внимание, что в этом коде не используются никакие массивы, не делается ни одного лишнего действия.
А теперь берем твой File.ReadAllText и запускаем Reflector
public static string ReadAllText(string path, Encoding encoding)
{
using (StreamReader reader = new StreamReader(path, encoding))
{
return reader.ReadToEnd();
}
}
public virtual string ReadToEnd()
{
int num;
char[] buffer = new char[0x1000];
StringBuilder builder = new StringBuilder(0x1000);
while ((num = this.Read(buffer, 0, buffer.Length)) != 0)
{
builder.Append(buffer, 0, num);
}
return builder.ToString();
}
Красота! Сначала читаем в буфер размером почему-то в 0x1000 байт. Внутри этой Read стоит цикл
do
{
int num2 = this.Read();
if (num2 == -1)
{
return num;
}
buffer[index + num++] = (char) num2;
}
while (num < count);
что само по себе просто прелесть. Читать по одному байту из файла — это просто чудо.
Теперь этот буфер присоединяется к StringBuilder'у
Итак, в буфер перекачали весь файл побайтно. В виде одной строки.
Теперь Split. Тут и без рефлектора обойдемся. Хватит и MSDN
The Split methods allocate memory for the return value array object and a String object for each array element
Итак, из этой строки (== файл) сделали массив строк, размер которого никак уж не меньше исходной строки.
Итого — два буфера размером в исходный файл и чтение побайтно из этого файла.
Это к вопросу о том "важно сколько кода у меня получится после пременения всего этого добра".
ИМХО лучшей демонстрации того, как не надо делать, я еще не видел. Я в свое время, когда вел у студентов курс по структурам данным, за такое программирование безжалостно требовал переделки целиком.
Эх, ладно. Пропустим тест. Исходный файл имеет размер 12 Мб, состоит из повторяющегося фрагмента
1. Кэширование файла операционной системой — раз.
2. Суммарная строка — два.
3. Массив строк — три.
У меня
Memory-mapped file — раз
и ничего больше, поскольку никакого файлового в/в здесь нет. А, кстати, если бы он и был — потребность в памяти не увеличилась бы, так как файловый кэш и mmf были бы сделаны на одном и том же наборе страниц RAM. У Рихтера этот вопрос подробно рассмотрен, раздел "когерентность".
Итого — в 3 раза меньше. Минимум.
Понадобится — еще меньше сделаю, буду отображать файл не целиком, а кусками. Код, конечно, усложнится, скорость — несколько упадет (за счет многих системных вызовов Map/UnmapViewOfFile. Но если именно память критична, решу задачу на 64 Кбайтах — при любом размере файла
P.S. Задачу, подобную этой , я студентам даю в качестве упражнения по memory-mapped файлам.
With best regards
Pavel Dvorkin
Re[10]: Раннее знакомство с Java калечит судьбы программисто
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Повтори на C#, please
Вуаля ...
using System;
using System.IO;
namespace ConsoleApplication2
{
class Program
{
static void Main(string[] args)
{
using (StreamReader reader = new StreamReader("D:\\Пример1.txt"))
{
while (!reader.EndOfStream)
{
Console.WriteLine(reader.ReadLine());
}
}
}
}
}
вторым параметром в стремридере можешь указать кодировку если нужна, по умолчанию юникод ... ну как?
Re[10]: Раннее знакомство с Java калечит судьбы программисто
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Уточнение. Не писанины на шарпе больше будет. а классов и прочих сущностей будет. Лишних действий меньше будет. Памяти расходоваться меньше будет. Быстрее работать будет. PD>Писанины, может, и меньше будет, если использовать классы, а не писать их.
ниче не понял ... смотри выше на мой пример, чего там больше? все просто как желудь ...
PD>Напиши свой вариант той же самой задачи. И давай попробуем на текстовом Юникодном файле размером так в 10-20 Мб.
написал, пробуй ...
PD>Кстати, почему в C# большинство классов ввода/вывода sealed ? Чем им не угодит, если я наследника сделаю и кое-что там переопределю ? В С++ это никогда не запрещено.
это не ко мне ... есть класс стрим, наследуйся на здоровье ...
Re[10]: Раннее знакомство с Java калечит судьбы программисто
Здравствуйте, Pavel Dvorkin, Вы писали:
>>В лучшем случае изобретут гору трёхколёсных велосипедов.
PD>Пусть так, но ездит он в 33 раза быстрее твоего Мерседеса
Мне не нужно в 33 раза быстрее. Мне нужно в 33 раза проще.
PD>Напиши код на C#, который решит ту же задачу за 0.015 сек, тогда и поговорим. Напиши, очень прошу
Я его уже написал. На моей машине этот код выполняетя за 00:00:00.001000
Но главное не это. Вот попробуй не просто ответить на вопрос, а подумать о нём хорошенько — зачем?
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Раннее знакомство с Java калечит судьбы программистов
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А нельзя ли объяснить, какое отношение XXXString имеет к вводу/выводу ? Подмена объекта обсуждения — не лучший способ дискутировать.
Это имеет прямое отношение к стандартным библиотекам.
PD>Что же касается string — я думаю, не надо объяснять, что он есть в STL, примерно с теми же возможностями, что и в C#.
Редкостное дерьмо ваш STL, вы уж извините мне мой французский.
>>Да и вообще это первопричина всей той вакханалии с библиотеками, которая свирепствует в C/C++.
PD>И в чем эта вакханалия заключается, если не секрет ? Что-то мы до сих пор ее как-то не замечали...
А я замечал пока писал на C/C++ и могу сказать, что нужно очень крепко зажмуриться, чтобы этого не замечать.
IT>>Маэстро может привести свой вариант на C/C++, а мы посмотрим.
PD>Печально, что дискуссия уходит в другую сторону. Я ведь не о том говорил, сколько кода получится,
У меня вообще подозрение, что если сравнивать код C++ и (Java, C#), по числу строк, то надо за одну строку на C++ 5 строк Java давать. Столько там чистого оверхеда...
Твоё?
PD>Да, твой код выглядит очень просто. Мой будет несколько сложнее, поскольку такого класса под руками нет.
Он будет не просто сложнее, он будет в десятки раз сложнее. Вместо одной строчки у тебя будет 33. А если у меня будет код в 1000 строк, то у тебя будет все 33,000?
PD>Итого — два буфера размером в исходный файл и чтение побайтно из этого файла.
Ты, конечно, молодец, что так постарался и покопался в этом деле рефлектором. Но знаешь что я тебе скажу? Мне пофиг как оно там внутри работает. Оно работает, решает свою задачу с приемлемой для моих задач производительностью и мне этого достаточно. А вот то что я решаю это всё в одну строку — это огромный плюс, потому что строк у меня таких не одна, а десятки тысяч и увеличение объёма кода в 33 раза, как в твоём случае для меня неприемлемо. Я не из тех, кто любит хвастаться проектами в миллионы бестолковых строк.
PD>Это к вопросу о том "важно сколько кода у меня получится после пременения всего этого добра".
Конечно важно. У меня это 1 (одна) строка.
PD>Эх, ладно. Пропустим тест. Исходный файл имеет размер 12 Мб, состоит из повторяющегося фрагмента
Тут ты явно перестарался. Речь шла о небольших файлах. Впрочем и с большими разница не существенная. Гигабайтные файлы тоже в своё время приходилось обрабатывать. Не таким образом, но тоже на C#. Если не ошибаюсь, парсинг 3-х гигабайтного файла занимал что-то около 20 секунд, а потом шла вставка в БД 11 миллионов строк. Так вот, внимание, вставка в БД занимала почти час. Теперь ответь мне какая разница будет между C++ и C#, если на C# это занимает 20 секунд и 1000 строк, а на C++ одну секунду и 20,000 строк? А я тебе скажу. Написание всего того кода у меня заняло пару дней + нулевые усилия на сопровождение. Примерно в тоже время ко мне на интервью приходил чувак, которые точно такой же фигнёй занимался на C... теперь читаем внимательно... ЧЕТЫРЕ ГОДА!
PD>Время колеблется от 0.5 сек до 2.5 сек. Берем по минимуму, 0.5 сек.
PD>0.5/0.015 = 33 раза
Я сейчас умру от смеха
PD>С чем тебя и поздравляю. Воистину бесплатный сыр бывает только в мышеловках!
Этот сыр очень дорогого стоит. Небольшое падение производительности (которого, кстати, в моём случае на небольших файлах вовсе нет) — это ерунда. Мои продакшин сервера один фиг загружены максимум на 5%. А вот написание, отладка и поддержка кода, который в десятки раз больше — это существенный нюанс.
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.