Т>Программист C++ не может ничего сделать такого, чья функциональность выходит за пределы STL/ATL/WTL/MFC. Чуть что — бежит в инет в поисках нужной библиотеки.
Вы знаете, может. Пример тому — www.codeproject.comwww.rsdn.ruwww.boost.org. Обычно пишется что-то такое, что расширяет уже существующую функциональность или добавляет новую, а потом выкладывается для публичного пользования. Дельфист обычно знает, как пользоваться канвасом и THandle, присвоить свойству другое значение, и непосредственное обращение к winapi для него — уже высший пилотаж.
E>Ты не прав! Имхо, большинство C++ программистов норовят переписать самостоятельно даже существующие библиотеки. А уж когда готовой сразу под рукой нет, то искать -- это вообще бесполезная трата времени. Нужно незамедлительно писать свою! E>)
Все так бывает даже, что пишет аналог того, что уже написал сосед, просто от того, что считает свое решение более удачным. Бывает, что действительно нужно обойти ограничения/улучшить скорость, а бывает и просто чтобы померяться мужским достоинством
Здравствуйте, ArtemGorikov, Вы писали:
AG>Зачем мне для каждого вызова метода делать AddRef/Release?
При передаче ссылок.
AG>Зачем делать QI?
При приведении типов.
AG> В .NET, думаю, проверки встроены на уровне платформы.
В дотнете нет проверок, так как нет AddRef/Release-ов.
AG>Ну я сравнил виртуальные с виртуальными.
Дык дело в том, что в КОМ методы виртуальны без особой необходимости. В дотонете на это можно забить, и как следствие получить серьезный выигрыш в скорости.
VD>>А как насчет дисп-интерфейсов? Ведь все события идут через них. AG>У кого идут? У VB?
У всех. Про IConnectionPoint слышал? Стандратно в качестве интерфейсов обратного вызова используется именно IDispatch. Иначе многие среды просто навертываются. ВБ в том числе.
AG>Это как же надо постараться, чтобы одну базу открыть 2 экземплярами оутлука.
Легко. Открывали с двух разных машин по очереди. Прописали пути в реестре на сервер... Пару раз открыли сразу с двух машин. Резельтат... данные попортились.
AG> Ведь на одной машине они оба не запустятся. А целенаправленно можно и NT-ю повалить, и .NET фреймворк, надо только места знать
Вот представь себе Янус без проблем запускается параллельно с одной БД. Видимо потому что БД не самопал.
AG>Вообще-то long и есть int32.
Где как. В С/С++ это вообще не определено. В C# — это 100%-но Inr64.
AG>Ясен пень, что уникальные. Вот где быстрее будет поиск: на несортированном массиве (хешей) или на сортированном массиве методом половинного деления?
Если значения уникальные? Естественно на хэш-таблице. Ты бы изучил как они работают, тогда и таких вопросов не возникло бы. Хэш-таблица не ищет значение. Она из хэш-значения вычисляет слот в котором лежит значение и получает его. Если коллезий нет или их мало, то скорость поиска константная, т.е. каково бы не было количество элементов все равно скорость поиска будет одинакова. При поиске полвоинном делением скорость деградирует хотя и лагорифимически.
AG>Не надо целенаправленно вредить, и все будет ок.
Никто специльно себе проблем не создает. Но я как то нарвался на проблему. Уже не помню сути, но выл AV.
VD>>2. Слишком много траха. Хэширование — трах. Вынуть списко ключей/значений — трах.
AG>Написать CAtlMap<CAtlString, ...> — трах с хешированием?
1. Не всегда получается написать "просто".
2. Кроме объявления переменной ее нужно еще и использвать. А тут почему-то начинается трах. Интуитивностью все это дело не страдает.
Вотс кажи зачем мне разбираться с какими-то POSITION-ами? Или зачем мне разбираться во всех этих KINARGTYPE, KOUTARGTYPE, VINARGTYPE, VOUTARGTYPE.
А когда я беру Dictionary, то все пишется быстро и легко. Чтобы не быть голословным, я наклепал классический прмер — конкорданс (т.е. программа подсчитывающая слова в файле):
using System;
using System.Collections.Generic;
using System.IO;
class Program
{
static void Main(string[] args)
{
Dictionary<string, int> concordance = new Dictionary<string, int>();
// Перебираем слова...foreach (string word in GetWord(File.ReadAllText(args[0])))
{
int count;
// Пробуем получить значение. Если оно не задано count будет равен 0.
// что нам и надо.
concordance.TryGetValue(word, out count);
concordance[word] = count + 1;
}
// Копируем список ключей хэш-таблицы в динамический массив и сортируем его.
List<string> keys = new List<string>(concordance.Keys);
keys.Sort();
// Выводим информацию о каждом слове.foreach (string key in keys)
Console.WriteLine("Слово {0,20} встретилось {1,3} раз[а].",
key, concordance[key]);
}
// Возвращает список слов из мереданного текста.static IEnumerable<string> GetWord(string text)
{
// Перебираем все символы...for (int i = 0; i < text.Length; i++)
{
char ch = text[i];
// Если это начало слова...if (char.IsLetter(ch))
{
int strat = i;
// Ищем его конец.for (++i; i < text.Length; i++)
{
if (!char.IsLetterOrDigit(ch = text[i]))
{
// Если конец найден, получаем подстроку и вызвращем его в итераторе.yield return text.Substring(strat, i - strat);
break;
}
}
}
}
}
}
На написание и отладку ушло около 15 минут (точнее 14). Причем основное время убил на вычленение слов (функцию GetWords). Потребовалось два запуска для того, чтобы пример заработал корректно. И еще один для правильного подбора отступа в строках. Попробуй ради хохмы написать тоже самое на С++ с использованием АТЛ и сравним объем кода, его читаемость и время/количество отладочных запусков.
Вот результат этого примера если его натравить на свой же исходный код:
Слово args встретилось 2 раз[а].
Слово break встретилось 1 раз[а].
Слово ch встретилось 3 раз[а].
Слово char встретилось 3 раз[а].
Слово class встретилось 1 раз[а].
Слово Collections встретилось 1 раз[а].
Слово concordance встретилось 5 раз[а].
Слово Console встретилось 1 раз[а].
Слово count встретилось 4 раз[а].
Слово Dictionary встретилось 2 раз[а].
Слово File встретилось 1 раз[а].
Слово for встретилось 2 раз[а].
Слово foreach встретилось 2 раз[а].
Слово Generic встретилось 1 раз[а].
Слово GetWord встретилось 2 раз[а].
Слово i встретилось 10 раз[а].
Слово IEnumerable встретилось 1 раз[а].
Слово if встретилось 2 раз[а].
Слово in встретилось 2 раз[а].
Слово int встретилось 5 раз[а].
Слово IO встретилось 1 раз[а].
Слово IsLetter встретилось 1 раз[а].
Слово IsLetterOrDigit встретилось 1 раз[а].
Слово key встретилось 3 раз[а].
Слово keys встретилось 3 раз[а].
Слово Keys встретилось 1 раз[а].
Слово Length встретилось 2 раз[а].
Слово List встретилось 2 раз[а].
Слово Main встретилось 1 раз[а].
Слово new встретилось 2 раз[а].
Слово out встретилось 1 раз[а].
Слово Program встретилось 1 раз[а].
Слово ReadAllText встретилось 1 раз[а].
Слово return встретилось 1 раз[а].
Слово Sort встретилось 1 раз[а].
Слово static встретилось 2 раз[а].
Слово strat встретилось 3 раз[а].
Слово string встретилось 9 раз[а].
Слово Substring встретилось 1 раз[а].
Слово System встретилось 3 раз[а].
Слово text встретилось 6 раз[а].
Слово TryGetValue встретилось 1 раз[а].
Слово using встретилось 3 раз[а].
Слово void встретилось 1 раз[а].
Слово word встретилось 3 раз[а].
Слово WriteLine встретилось 1 раз[а].
Слово yield встретилось 1 раз[а].
AG>Ок, сколько коробочных продуктов выбрало .NET для своего GUI?
Думаю море. Вот только тут не слова нужна, а статистика. А ее у мне нет. Можно поглядеть на количество открытх проектов на сорсфордже.
AG>Примеры коммерческого использования Mono — в студию
Ты гуглем не умешь пользоваться? Сейчас море хостеров на Линуксах предлагают Моно в качестве одной из попций.
AG>А что тогда на нем делать? веб-приложения?
Ага. Для этого, как я понимаю, он в основном и разрабатывался.
Хотя разные консольные приблуды и демоны тоже можно.
AG>Вот именно. Это была цель Delphi с ее VCL. Результаты мы все уже видели.
А что плохие результаты? 80 бывшего СССР на ней работало.
AG> Программист дельфи не может ничего сделать такого, чья функциональность выходит за пределы палитры компонентов.
Это в тебе говорит снобизм. Есть разные Дельфи-программисты. Как в прочем и С++-программисты тоже, как не странно, разными бывают. Зайди в форм по С++ и увидишь, сколько там ламерских вопросов. Тот же Синклер из нешей команды тоже Дельфи-программист вроде, но это не мешает ему быть в топе.
AG> Чуть что — бежит в инет в поисках нужного компонента.
А средний С++-ник кидается все написать сам. Это крайности. Разумный человек думает. Не нужно вешать ярлыков.
AG> Как следствие, квалификация распространяется тока на БД и "мышевозительство". AG>Такая простота окажет медвежью услугу тем, кто пришел сразу на C# и не имеет опыта C++/WinAPI/MFC.
Ну, MFC — это на сегодня просто бессмысленный опыт. WinAPI еще лет 5, а то и 10 будет полезен и его можно выучить без С++. Ну, а С++ это, скажем так, неплохая разминка для мозгов. Программировать на нем я бы сейчас не стал, но о том что его знаю лично я не жалею.
Если выключить снобизм, то довольно быстро становится понятным, что во все времена есть люди которые стремятся к саморазвитию. Такие люди никогда не утопнут в RAD-остях и GUI-ёвостях. Они будут неплохо программировать и не имея опыта С++ за спиной. Вместо этого они будут изучать паттерны, технологии, новые более перспективные языки и т.п. И будут те кому и так достаточно. Вот они будут похоже на тех кого ты ассоциируешь с дельфистами.
AG>Респект но пока я еще не подсел на C#, можно пофлеймить
Можно. Но уверяю тебя, что после полугода на Шарпе обратно уже возвращаться противно. Никакие Бустовские фишки не заменяют той простоты и ясности.
AG>А что результат на C# всегда красивый? Или все-таки это больше от человека зависит?
Не. Не всегда. Но тем не менее намного чаще чем на плюсах. На то работает буквально все. И более простые библиотеки. И более ясные паттерны. И заточенность Шарпа на более простые решения. И IDE с ее рефакторингом и интелисенсом. И даже быстрый цикл компиляция/отладка. Все это позволяет сделать код.
AG>>>В STL нет простоты? Что может быть проще, чем написать std::vector<int>?
VD>>Написать: VD>>
VD>>List<int>
VD>>
VD>>
AG>И в чем проще? что в слове List на 1 букву меньше?
Ну, все же проще.
Смотреть конечно унжно на более рельном коде. Ну, да я тебе его уже выше привел. Повтори его на МФЦ, АТЛ и СТЛ. Сравним что получилось.
AG>А в чем проблема использовать в COM?
А ты попробуй. Твои делегаты сущность времени компиляции. А КОМ понимает только интерфейсы.
AG> Более того, у делегата можно взять совершенно обычный C-указатель на функцию и дать его куда-нибудь в сишный колбэк, например, в WinAPI.
А КОМ-у твои указатели неизвесны.
AG> С анонимными методами действительно никак
Ну, те так чтобы уж совсем. Какие-то извраты в Бусте вроде есть. Но это извраты еще те.
AG> Пусть это будет ограничением C++. Но ведь у C# ограничений заметно больше UP, и никто из пишуших на нем от этого не страдает
Дык его ограничения — это как бы культура программирования. Он ограничивает тебя рамками ООП/КОП, но в этих рамках дает поистене отличные инструменты.
AG>Не обязательно реализовывать его весь.
Ну, тогда да.
AG>В функцию передали указатель по значению, затем значение указателя, т.е. адрес в памяти, модифицировали. При этом после выхода из функции все осталось как прежде. Надо было написать так: int*& p , тогда бы получили желаемую порчу стека.
А, да конечно... торможу. Нужно было двойой указатель делать. Но сути дела это не меняет.
AG>Т.е. где-то сложности убавилось, а где-то прибавилось.
Она в основном убавилась.
AG>COM-синглтон вообще кладет на подсчет ссылок и не разрушается сам.
Это АТЛ-ьный. А ты зацепи за него пару других объектов и посмейся когда будешь забираться с политикой владения.
AG> Подразумевается, что винда сама освободит память и ресурсы программы при ее завершении. Так что этот пример не из той оперы.
А если это компонет в сервере приложений? Ну, бизнес объект...
VD>>Главное, что нужно понимать — GC снимает с программиста необходимость следить за памятью. А это очень не мло и при проектировании, и ири реализации. AG>И добавляет pinned-poinеrs для обхода этого блага.
Не в коем случае! Если ты не лезишь в интероп, то никакие поинтеры. Теболее пиннед тебе не нужны вовсе.
VD>>В итоге код с GC становится меньше и проще. А это как раз то, что требовалось. AG>При этом время разрушения утраченного объекта недетерминировано,
Неверно. Его просто нет. Объект мертв если не доступен. И не нужно на него вообще обращать внимание.
AG> и уже нельзя ничего освобождать в деструкторе,
А нечего освобождать. Он если и держит, то тоже память. Или у него есть Dispose с финалайзером.
AG> плюс, прилага подвисает в самый неподходящий момент — пример — студия 2003.
Это тут причем? Студия вообще онменеджед продукт.
AG> Если запущено несколько студий, и одна из них собирает проект, то другая или обе начинают подвисать при попытке сохранить исходник или просто что-то набрать в редакторе.
У меня такого нет. Но даже если бы было, это никак не доказывает каких-то пробелм ЖЦ.
AG> После подвисания у этой студии мигает каретка, а заголовок окна неактивный — вот и хваленый WinForms. У нее вообще часто каретка живет своей жизнью, а окно — своей.
Редактор нэйтивный. Работа с файлами идет через КОМ. Так что о чем ты я не знаю. В моих программах проблем с ресурсами нет. И я вообще о них почти не забочусь. Попробуй и поймешь что это очень удобно.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AG>>В таком случае честно будет сравнивать скорость вызова метода класса C# и метода класса С++, который, к тому же, можно сделать инлайновым.
VD>Да. И разницы никакой нет.
AG>> В самом деле, надо провести тест — на сколько порядков будет разница — на 1 или 2?
VD>С чего бы ей быть? Ну, если только в одном случае заинлайнится, а в другом нет. Но это и 10% на суровом алгоритме не даст, а в приложении ты это и не заметишь.
Не надо мне ликбез читать. Я имел в виду, что не надо для каждого вызова метода делать AddRef/QI.
AG>> В .NET, думаю, проверки встроены на уровне платформы.
VD>В дотнете нет проверок, так как нет AddRef/Release-ов.
При чем тут опять эти AddRef/Release-ов ?
VD>У всех. Про IConnectionPoint слышал? Стандратно в качестве интерфейсов обратного вызова используется именно IDispatch. Иначе многие среды просто навертываются. ВБ в том числе.
Это если _надо_использовать_connection_point. Если не надо, то в C++ программе вполне сгодится IUnknown.
AG>>Это как же надо постараться, чтобы одну базу открыть 2 экземплярами оутлука.
VD>Легко. Открывали с двух разных машин по очереди. Прописали пути в реестре на сервер... Пару раз открыли сразу с двух машин. Резельтат... данные попортились.
Я понял, что с разных. Это я и называю "целенаправленно портить". Делали ставки, повалится или нет? Нормальный юзер никогда так не сделает.
AG>> Ведь на одной машине они оба не запустятся. А целенаправленно можно и NT-ю повалить, и .NET фреймворк, надо только места знать
VD>Вот представь себе Янус без проблем запускается параллельно с одной БД. Видимо потому что БД не самопал.
Молодцы, умеете прикрутить БД к любой софтине. Предлагаю продолжить эту славную традицию и прикрутить БД к Winamp, winword, excel, mediaplayer, Doom, Quake, HL, и ICQ.
AG>>Вообще-то long и есть int32.
VD>Где как. В С/С++ это вообще не определено. В C# — это 100%-но Inr64.
В VC++ это именно int32.
AG>>Ясен пень, что уникальные. Вот где быстрее будет поиск: на несортированном массиве (хешей) или на сортированном массиве методом половинного деления?
VD>Если значения уникальные? Естественно на хэш-таблице. Ты бы изучил как они работают, тогда и таких вопросов не возникло бы. Хэш-таблица не ищет значение. Она из хэш-значения вычисляет слот в котором лежит значение и получает его. Если коллезий нет или их мало, то скорость поиска константная, т.е. каково бы не было количество элементов все равно скорость поиска будет одинакова. При поиске полвоинном делением скорость деградирует хотя и лагорифимически.
Ок, вычислила из лонга хэш и как дальше ищет слот? Простым перебром слотов или как?
AG>>Не надо целенаправленно вредить, и все будет ок.
VD>Никто специльно себе проблем не создает. Но я как то нарвался на проблему. Уже не помню сути, но выл AV.
VD>>>2. Слишком много траха. Хэширование — трах. Вынуть списко ключей/значений — трах.
AG>>Написать CAtlMap<CAtlString, ...> — трах с хешированием?
VD>1. Не всегда получается написать "просто". VD>2. Кроме объявления переменной ее нужно еще и использвать. А тут почему-то начинается трах. Интуитивностью все это дело не страдает.
Есть typedef в помощь.
VD>Вотс кажи зачем мне разбираться с какими-то POSITION-ами? Или зачем мне разбираться во всех этих KINARGTYPE, KOUTARGTYPE, VINARGTYPE, VOUTARGTYPE.
В самом деле, зачем? Чтобы ковыряться во внутренностях CAtlMap? Для его использования в них разбираться не надо.
VD>А когда я беру Dictionary, то все пишется быстро и легко. Чтобы не быть голословным, я наклепал классический прмер — конкорданс (т.е. программа подсчитывающая слова в файле):
Думаю, на С++ можно было написать также коротко. Единственно что легче — писать foreach.
VD>На написание и отладку ушло около 15 минут (точнее 14). Причем основное время убил на вычленение слов (функцию GetWords). Потребовалось два запуска для того, чтобы пример заработал корректно. И еще один для правильного подбора отступа в строках. Попробуй ради хохмы написать тоже самое на С++ с использованием АТЛ и сравним объем кода, его читаемость и время/количество отладочных запусков.
Ок, завтра.
AG>>Ок, сколько коробочных продуктов выбрало .NET для своего GUI?
VD>Думаю море. Вот только тут не слова нужна, а статистика. А ее у мне нет. Можно поглядеть на количество открытх проектов на сорсфордже.
Из этого моря на моей машине студия и раньше был янус.
VD>Ну, MFC — это на сегодня просто бессмысленный опыт. WinAPI еще лет 5, а то и 10 будет полезен и его можно выучить без С++. Ну, а С++ это, скажем так, неплохая разминка для мозгов. Программировать на нем я бы сейчас не стал, но о том что его знаю лично я не жалею.
Да, мне он давно уже разонравился.
AG>>Респект но пока я еще не подсел на C#, можно пофлеймить
VD>Можно. Но уверяю тебя, что после полугода на Шарпе обратно уже возвращаться противно. Никакие Бустовские фишки не заменяют той простоты и ясности.
Я вот, когда с дельфи пересел на C++, тоже противно стало на нем присать. IMHO дело привычки.
CS>>Интересно а что произойдет если it1 и it2 взяты от разных последовательностей? J>я думаю, ты и сам знаешь, что произойдет в общем случае. И что с того? Предлагаешь затеять войну на тему "Что безопаснее"?
И откуда вы вообще такие ошибки берёте?
Вроде STL пользую, а такого ляпа не делал. И даже как-то в голову не приходило, что там ляп может быть...
Здравствуйте, ArtemGorikov, Вы писали:
AG>Ок, вычислила из лонга хэш и как дальше ищет слот? Простым перебром слотов или как?
Почитай http://www.optim.ru/cs/2000/4/bintree_htm/hash.asp
VD>>1. Не всегда получается написать "просто". VD>>2. Кроме объявления переменной ее нужно еще и использвать. А тут почему-то начинается трах. Интуитивностью все это дело не страдает.
AG>Есть typedef в помощь.
Ну, вот воспроизведи пример и сравним.
AG>В самом деле, зачем? Чтобы ковыряться во внутренностях CAtlMap? Для его использования в них разбираться не надо.
А зачем они есть и документированы? Почему Dictionary<K, V> без всего успешно обходится?
AG>Думаю, на С++ можно было написать также коротко. Единственно что легче — писать foreach.
Я почти уверен. Но почему-то не пишут. Вот и интересно почему?
VD>>На написание и отладку ушло около 15 минут (точнее 14). Причем основное время убил на вычленение слов (функцию GetWords). Потребовалось два запуска для того, чтобы пример заработал корректно. И еще один для правильного подбора отступа в строках. Попробуй ради хохмы написать тоже самое на С++ с использованием АТЛ и сравним объем кода, его читаемость и время/количество отладочных запусков.
AG>Ок, завтра.
Ну, как?
AG>Из этого моря на моей машине студия и раньше был янус.
У тебя на машине еще маковских приложений нет. Но это же не значит что их нет вообще. Ты же не бухгалтер или продавец?
AG>Я вот, когда с дельфи пересел на C++, тоже противно стало на нем присать. IMHO дело привычки.
Может быть. Только противно почему-то переходиь к плюсам. А обратно без проблем.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Меня улыбнуло
Твой код удалил не оверквотига ради, а токмо ради сравнения:
VD>
VD>using System;
VD>using System.Collections.Generic;
VD>using System.IO;
VD>class Program
VD>{
VD> static void Main(string[] args)
VD> {
VD> Dictionary<string, int> concordance = new Dictionary<string, int>();
VD> // Перебираем слова...
VD> foreach (string word in GetWord(File.ReadAllText(args[0])))
VD> {
VD> int count;
VD> // Пробуем получить значение. Если оно не задано count будет равен 0.
VD> // что нам и надо.
VD> concordance.TryGetValue(word, out count);
VD> concordance[word] = count + 1;
VD> }
VD> // Копируем список ключей хэш-таблицы в динамический массив и сортируем его.
VD> List<string> keys = new List<string>(concordance.Keys);
VD> keys.Sort();
VD> // Выводим информацию о каждом слове.
VD> foreach (string key in keys)
VD> Console.WriteLine("Слово {0,20} встретилось {1,3} раз[а].",
VD> key, concordance[key]);
VD> }
VD> // Возвращает список слов из мереданного текста.
VD> static IEnumerable<string> GetWord(string text)
VD> {
VD> // Перебираем все символы...
VD> for (int i = 0; i < text.Length; i++)
VD> {
VD> char ch = text[i];
VD> // Если это начало слова...
VD> if (char.IsLetter(ch))
VD> {
VD> int strat = i;
VD> // Ищем его конец.
VD> for (++i; i < text.Length; i++)
VD> {
VD> if (!char.IsLetterOrDigit(ch = text[i]))
VD> {
VD> // Если конец найден, получаем подстроку и вызвращем его в итераторе.
VD> yield return text.Substring(strat, i - strat);
VD> break;
VD> }
VD> }
VD> }
VD> }
VD> }
VD>}
VD>
С++ с голимым концептуально неверным STL-ем:
#include <map>
#include <string>
#include <fstream>
#include <iostream>
using namespace std;
int main(int argc, char * argv[])
{
string str;
map<string, long> concordance;
ifstream input(argv[1]);
if (!input.is_open())
cerr << "Не могу открыть файл" << endl;
while (input >> str)
++concordance[str];
for (map<string, long>::const_iterator i = concordance.begin(); i != concordance.end(); ++i)
cout << "Слово " << i->first << " встретилось " << i->second << " раз[а]" << endl;
return 0;
}
ЗЫ: 6 мин, компилировал 1 раз — первый раз написал while (getline(input, str))
Вывод: нефиг пиписьками меряться, для данной конкретной задачи STL подходит лучше .
А дотнет ... про него ничего тебе не скажу — боюсь . Хотя как таковое творение
микрософтовцев оченна уважаю.
Здравствуйте, jedi, Вы писали:
J>Меня улыбнуло J>Твой код удалил не оверквотига ради, а токмо ради сравнения:
J>С++ с голимым концептуально неверным STL-ем:
Слово args встретилось 2 раз[а].
Слово break встретилось 1 раз[а].
Слово ch встретилось 3 раз[а].
Слово char встретилось 3 раз[а].
Слово class встретилось 1 раз[а].
Слово Collections встретилось 1 раз[а].
Слово concordance встретилось 5 раз[а].
Слово Console встретилось 1 раз[а].
Слово count встретилось 4 раз[а].
Слово Dictionary встретилось 2 раз[а].
Слово File встретилось 1 раз[а].
Слово for встретилось 2 раз[а].
Слово foreach встретилось 2 раз[а].
Слово Generic встретилось 1 раз[а].
Слово GetWord встретилось 2 раз[а].
Слово i встретилось 10 раз[а].
Слово IEnumerable встретилось 1 раз[а].
Слово if встретилось 2 раз[а].
Слово in встретилось 2 раз[а].
Слово int встретилось 5 раз[а].
Слово IO встретилось 1 раз[а].
Слово IsLetter встретилось 1 раз[а].
Слово IsLetterOrDigit встретилось 1 раз[а].
Слово key встретилось 3 раз[а].
Слово keys встретилось 3 раз[а].
Слово Keys встретилось 1 раз[а].
Слово Length встретилось 2 раз[а].
Слово List встретилось 2 раз[а].
Слово Main встретилось 1 раз[а].
Слово new встретилось 2 раз[а].
Слово out встретилось 1 раз[а].
Слово Program встретилось 1 раз[а].
Слово ReadAllText встретилось 1 раз[а].
Слово return встретилось 1 раз[а].
Слово Sort встретилось 1 раз[а].
Слово static встретилось 2 раз[а].
Слово strat встретилось 3 раз[а].
Слово string встретилось 9 раз[а].
Слово Substring встретилось 1 раз[а].
Слово System встретилось 3 раз[а].
Слово text встретилось 6 раз[а].
Слово TryGetValue встретилось 1 раз[а].
Слово using встретилось 3 раз[а].
Слово void встретилось 1 раз[а].
Слово word встретилось 3 раз[а].
Слово WriteLine встретилось 1 раз[а].
Слово yield встретилось 1 раз[а].
Тестовый файл, естественно, одинаковый.
Если тяжело понять разницу, то поясню. Разбираются не слова, а черти что. Про кодировку в консоли вообще лучше промолчать.
J>Вывод:...
Если результат не важен, то СТЛ рулит.
ЗЫ
Таки все же интересно глянуть на тоже самое на АТЛ-е.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Дай определение слова. В моем понимании это то что разделено пробельными символами — в твоем это видимо идентификаторы и ключевые слова С# (кстати ты не учел "слова" начинающиеся с символа подчеркивания).
ЗЫ про кодировки — это проблема совсем другого плана и в контексте данного алгоритма абсолютно не важна.
...При другом подходе к хешированию таблица рассматривается как массив связанных списков или деревьев ...
Т.е. при получении hash из простого типа (например, long), мы будем иметь в лучшем случае то же дерево, что и stl::map, плюс еще доп. расход памяти — ключи + хэши к ним против только ключи у stl::map. Hash — массивы оправданны только в тех случаях, когда размер типа хэша меньше размера типа ключа.
Здравствуйте, ArtemGorikov, Вы писали:
AG>Здравствуйте, VladD2, Вы писали:
VD>>Почитай http://www.optim.ru/cs/2000/4/bintree_htm/hash.asp
AG>Статья рулит
AG>Вот там написано:
AG>...При другом подходе к хешированию таблица рассматривается как массив связанных списков или деревьев ...
+1
AG>Т.е. при получении hash из простого типа (например, long), мы будем иметь в лучшем случае то же дерево, что и stl::map, плюс еще доп. расход памяти — ключи + хэши к ним против только ключи у stl::map. Hash — массивы оправданны только в тех случаях, когда размер типа хэша меньше размера типа ключа.
А вот это, насколько я понимаю, неверно.
В предыдущей цитате ключевое слово — массив. Хэшированные структуры организуют данные таким образом, что в лучшем случае (при отсутствии коллизий) доступ к элементу с заданным индексом сводится к прямому доступу к ячейке этого самого массива, плюс проверка на то, что мы нашли именно нужный элемент, а не абы что.
Разрешите и мне чуть-чуть кулаками помахать. MS>Честно сказать, мне концепция итераторов вообще не нравится.
Но тов. Степанову огромное спасибо за то, что он их такими придумал. Есть чего совершенствовать.
Есть такой деятель -- Dietmar Kuehl, член Комитета (не КГБ), бустер, модератор comp.lang.c++.moderated, спортсмен, комсомолец и просто красавец: .
Ему тоже итераторы не нравятся, но у него есть конкретные предложения, и он работает над их реализацией. Основная идея -- разделение обхода структуры данных (курсоры) и доступа к ее элементам (property maps). К сожалению, целиком это нигде не сформулировано, а рассеяно по разным тхредам конференций, типа комп.ланг.с++ и т.д.
Например: http://lists.boost.org/Archives/boost/2002/03/26297.php
Iterators confuse two separate concepts! Separating property access from
object identification clears things up. Of course, everybody is now used
to iterators confusing these two things liberally but this should be
corrected since it causes all kinds of problems. To me the only question
is how the interface is effectively supposed to look like. The question
is not whether iterators and property maps should be separated: That's a
given! For me, at least...
...
here is a list of problems:
— const_iterator vs. iterator:
— can these be compared and/or converted?
— can both be used to specify positions in containers?
— how to get an iterator from a const_iterator?
— value_type
— how to deal with multiple values? map's approach does not scale and
causes eg. problems to key/value organization?
— how to search for key in a sequence of pairs (eg. to implement a
vector based map)?
— how to sort a container with polymorphic object but with a value
like feeling? (the problem is the missing distinction between the
value for the comparison and the holder maintaining the object)
— how to create a proxy container?
— harder to extend:
— creating eg. a filtering iterator requires details on iterator's
member functions
— how to add a derived attribute and use the iterator with find on
the derived attribute?
...
Здравствуйте, ArtemGorikov, Вы писали:
AG>Т.е. при получении hash из простого типа (например, long), мы будем иметь в лучшем случае то же дерево, что и stl::map, плюс еще доп. расход памяти — ключи + хэши к ним против только ключи у stl::map. Hash — массивы оправданны только в тех случаях, когда размер типа хэша меньше размера типа ключа.
Где смеяться? Что не так? Хэш таблица ускоряет доступ к элементам за счет памяти не зависимо от того, что хэшируется.
Здравствуйте, ArtemGorikov, Вы писали:
AG>Статья рулит
AG>Вот там написано:
AG>...При другом подходе к хешированию таблица рассматривается как массив связанных списков или деревьев ...
AG>Т.е. при получении hash из простого типа (например, long), мы будем иметь в лучшем случае то же дерево, что и stl::map, плюс еще доп. расход памяти — ключи + хэши к ним против только ключи у stl::map. Hash — массивы оправданны только в тех случаях, когда размер типа хэша меньше размера типа ключа.
Это из серии "гляжу в книгу — вижу фигу". Прочти еще раз зачем там нужен список или дерево. Могу дать наводящее слово "коллизии".
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jedi, Вы писали:
J>Дай определение слова. В моем понимании это то что разделено пробельными символами —
Слово это нечто осмысленное. Уж скобки и т.п. точнро ими являться не должны.
J>в твоем это видимо идентификаторы и ключевые слова С#
Именно. И мне казалось, что это очевидно из приведенного кода.
J>(кстати ты не учел "слова" начинающиеся с символа подчеркивания).
Тут ты прав. Но это мелочь. Нужно всего лишь добавить одну проверку.
J>ЗЫ про кодировки — это проблема совсем другого плана и в контексте данного алгоритма абсолютно не важна.
Нет это тоже проблема и ее решение тоже увеличивает объем кода. А в таком виде это — лажа в которой разобраться то нельзя.
... << RSDN@Home 1.2.0 alpha rev. 606>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
бывает даже, что пишет аналог того, что уже написал сосед, просто от того, что считает свое решение более удачным. Бывает, что действительно нужно обойти ограничения/улучшить скорость, а бывает и просто чтобы померяться мужским достоинством 
Но уверяю тебя, что после полугода на Шарпе обратно уже возвращаться противно. Никакие Бустовские фишки не заменяют той простоты и ясности.
Не надо мне ликбез читать. Я имел в виду, что не надо для каждого вызова метода делать AddRef/QI.
