Здравствуйте, DarkGray, Вы писали:
PD>>Пишу с другого компьютера, под рукой DevStudio нет. Так что по памяти...
PD>>DirectoryInfo di = new DirectoryInfo("путь"); PD>>FileInfo[] fi = di.GetFiles();
PD>>в каталоге "путь" 100,000 файлов.
DG>А зачем вам FileInfo на каждый файл?
DG>Почему не ? DG>
Ну,во первых, может не только имя понадобиться. Но не в этом все равно дело. Вопрос-то вот в чем — зачем меня вынуждают весь контейнер (коллекцию и т.п.) получить, когда мне ее енумеровать достаточно. Не создавая ее в памяти вообще. И такое не только здесь...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну,во первых, может не только имя понадобиться. Но не в этом все равно дело. Вопрос-то вот в чем — зачем меня вынуждают весь контейнер (коллекцию и т.п.) получить, когда мне ее енумеровать достаточно. Не создавая ее в памяти вообще. И такое не только здесь...
По моему Sinclair на это вполне полно отвечал(к сожалению не могу найти ответ). Все дело в том, что надо закрывать дескриптор поиска, при этом среда поддерживает GC, то есть недетерменированное убийство объекта.
В результате, что тут получается:
FindClose — должен быть вызван сразу после работы. Выгрузка через GC может произойти через значительное время, а может и вообще не произойти. А это вынуждает нас делать примерно такие вызовы
FinderFiles fs=GetFiles(bla);
for (int i=0;i<100;i++)
filename=fs.GetNextFile();
FinderFiles.Close();//мы обязаны сделать закат солнца вручную
или примерно так:
using (FinderFiles fs=GetFiles(bla))
{
for (int i=0;i<100;i++)
filename=fs.GetNextFile();
}
Это я примерно описал как оно могло бы выглядеть. Но если сравнить с:
DirectoryInfo.GetFiles(bla)
то это пушка по воробьям. Одним вызовом значительно удобнее. А поскольку система не предназначена для работы обязательно с большим количеством файлов, то удобство синтаксиса важнее. И я вполне согласен с ними. К тому-же запасной аэродром в виде вызовов Win32 api есть.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Да, плюсы или фортран тоже не все приняли.
Насчет Фортрана не знаю, я тогда не жил (1954)
Особенной оппозиции плюсам не помню.
ЗХ>Да, до плюсов и фортрана тоже были ОО языки и языки высокого уровня. ЗХ>Но массовый-то софт с компиляцией в байт-код начали писать именно на Java и C#.
Согласеню
ЗХ>>>Но вопрос не в том. Вопрос в том — что должно появиться, чтобы "все поняли, что...")
PD>>Хороший вопрос. Знать бы точно ответ
ЗХ>Вот этот вопрос я и пытался поставить в этом топике.
Лично мне кажется, что все же должна мсмениться как-то парадигма. Т.е. будущее ИМХО за чем-то, что не явялется языками "операторного" типа. Что именно будет — не знаю. И согласен с тем, что до сих пор ничего такого не было. Но — все мы паровозники. Появится ли здесь наконец тепловозник — трудно сказать.
Вспомни историю с Прологом и японским проектом 5 поколения. Замышлялась именно такая революция. Ничего не вышло, да. Но это не значит, что самам идея неверна. Может, здесь сыграло роль то, что для японцев создание ПО — не самый любимый национальный вид спорта . Может, американцы здесь большего добились бы, если бы взялись. Не знаю.
Но в одном уверен. Если что-то революционное появится — вряд ли это мы предскажем здесь. Если, конечно, не считать революцией такие события, как введение в С++ темплейтов или появление байт-кода. На мой взгляд — на революцию не тянет все это. Точно так же, как серьезной революции я не вижу в переходе от Эниака к Пентиуму 4. Чистая эволюция. Вот если наконец появятся машины нефон-Неймановской архитектуры, тогда это будет революцией.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Pavel Dvorkin, Вы писали:
GZ>По моему Sinclair на это вполне полно отвечал(к сожалению не могу найти ответ). Все дело в том, что надо закрывать дескриптор поиска, при этом среда поддерживает GC, то есть недетерменированное убийство объекта.
Помню его ответ. GZ>то это пушка по воробьям. Одним вызовом значительно удобнее. А поскольку система не предназначена для работы обязательно с большим количеством файлов, то удобство синтаксиса важнее. И я вполне согласен с ними. К тому-же запасной аэродром в виде вызовов Win32 api есть.
Еще раз — мой вопрос не в этом. Я не могу принять идею делать что бы то ни было с большими затратами ресурсов, чем надо. Неважно, 1000 там строк будет или 100000, если нужна одна. Вот с этим я не согласен в принципе. Почему — объясню потом, когда напишу сюда то, что собираюсь написать. Так что уж подожди немного
Здравствуйте, Pavel Dvorkin, Вы писали: PD> Если, конечно, не считать революцией такие события, как введение в С++ темплейтов или появление байт-кода.
Когда в далеких 60-ых для Лиспа сделали GC и LAP and SECD(почему бы не байт-код), никто о революции не говорил. И по моему никто и сейчас об этом не распространяется.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>? К примеру (банальный) решиться мне, скажем, на C# матричные операции производить или же С++ DLL для этого написать, а в Шарпе только вызывать ее.
А почему бы и нет, кстати?
Практически даже честный метод.
Здравствуйте, EXO, Вы писали:
PD>>? К примеру (банальный) решиться мне, скажем, на C# матричные операции производить или же С++ DLL для этого написать, а в Шарпе только вызывать ее.
EXO>А почему бы и нет, кстати? EXO>Практически даже честный метод.
Так в этом-то и вопрос. Что делать на managed коде, чему доверять, а чему нет...
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Pavel Dvorkin, Вы писали: PD>> Если, конечно, не считать революцией такие события, как введение в С++ темплейтов или появление байт-кода. GZ>Когда в далеких 60-ых для Лиспа сделали GC и LAP and SECD(почему бы не байт-код), никто о революции не говорил. И по моему никто и сейчас об этом не распространяется.
Ну не революции, так радикальное нововведение.
PD>Ну тогда надо признать, что появление template в C++ — тоже радикальное нововведение.
AVK>Да, конечно
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Рад видеть тебя и здесь .
Спасибо PD>А за каким богом мне тогда вопрос о memset задавать было ?
Вот и мне это интересно
PD>Именно. Потому что (еще раз объясняю) я не знаю, где тут возможные проблемы имеются. И когда вижу нечто, мне подозрительное, спрашиваю. нельзя ли это сделать способом, который мне хорошо знаком и никаких сомнений не вызывает.
О! Вот тут-то и кроется проблема. Ты подменяешь задачу ее решением. Это худший способ изучить новую технологию. "Как мне сделать виртуальный конструктор в С++?" кажется нормальным вопросом дельфисту.
PD>А начни я спрашивать про все конструкции — тогда для меня отдельный форум придется создать
Ну, для начала можно освоить поиск. Поверь, ты не первый, кто пересаживается с плюсов на дотнет. И все наступают на те же самые грабли.
PD>Я одно хочу знать — смогу ли я на нем делать с той же эффективностью то, что я умею делать.
Нет. То, что ты умеешь делать на плюсах, в рамках дотнета ты делать не сможешь. Некоторые концепции могут быть переиспользованы, но в целом легче изучать дотнет с нуля. Это примерно то же самое, как если бы ты после 25 лет чистого ассемблера 80с51 пересел на плюсы и задавался вопросом, как тебе применить колоссальные знания по ручному распределению регистров. В общем случае — никак. Можно, конечно, писать километровую ассемблерную вставку в main и плеваться. Но это никак не будет C++ программой.
PD>А тут мне предлагается инструмент, в котором эффективнсть бог знает какая, то ли компилятор, то ли интерпретатор, механизмы для меня непривычные, чему можно верить — не знаю, пробую элементарное (DirectoryInfo) — получаю кошмар. Где еще проблемы ТАКОГО рода скрыты? Не знаю. Подозреваю все. И new для value тоже.
Ну так и спрашивай напрямую. Не надо вокруг да около ходить, и кричать "да это очевидно неэффективно".
PD>Вот это уже лучше. Я и хочу это понять, Я и недоволен тем, что то, что должно быть эффективным (потому что я очень даже хорошо знаю, что здесь делается хоть на уровне kernel32, хоть ntdll.dll, хоть даже ntoskrnl, вдруг 57 Мбайт требует. И что еще меня подобное здесь ждет ?
Тебе решение уже предложили.
PD>Черта с два. Я просто знаю, на что он это компилирует. А если малейшие сомнения появятся, посмотрю дизассембленрный код. Но, конечно, я реально знаю, что и как можно делать.
Прекрасно. Тогда запасись профайлером, ildasm, а также смотри дизассемблированный код в отладчике. Вообще невредно заранее представлять, что фреймворк писали не полные дауны. Поэтому на ровном месте граблей нет. Прикладная библиотека, с другой стороны, написана людьми значительно менее квалифицированными. Поэтому многие вещи там отсутствуют, а те, которые есть, рассчитаны на 90% пользователей (а не на тех, кто складывает 1000000 файлов в один каталог). PD>Ну это особая тема. Если хочешь, можно подискутировать как-нибудь.
Не, не хочу. Я просто представляю себе ширину сегмента приложений, которым важна пиковая производительность, а также представляю себе стоимость ручной оптимизации кода под таргет процессор. С этой точки зрения, докручивать еще 4% к производительности — выбрасывать деньги на ветер. Если не слишком мешать компилятору, то он производит код близкий к оптимальному. А для управляемой среды можно получать еще большую производительность благодаря хотспоттингу, который в принципе недоступен плюсовому компилятору. PD>Дело в том, что есть задачи разных классов. И трудно сказать, где и что может всплыть. Я же не спорю, что Java для апплетов хорошо подходит. Но да помилуй бог того, кто вздумает PhotoShop на Java написать.
Ну как тебе сказать. Вот тут недавно выложили векторную рисовалку на дотнете с субпиксельной графикой. Не сказать, чтобы Visio прямо уж так был быстрее.
PD>Был там. Естественно, это хорошо, но проблему не решает. Я там могу Win32 функции вызывать, ну а свои собственные ?
Гм. А чем твои собственные функции хуже стандартных? Пинвоку по барабану, кого вызывать. PD>К примеру (банальный) решиться мне, скажем, на C# матричные операции производить или же С++ DLL для этого написать, а в Шарпе только вызывать ее.
Ты не пробовал, к примеру, вот здесь
S>О! Вот тут-то и кроется проблема. Ты подменяешь задачу ее решением. Это худший способ изучить новую технологию. "Как мне сделать виртуальный конструктор в С++?" кажется нормальным вопросом дельфисту.
Это детали. Также можно и о метаклассах (так ты их, кажется назвал, я их типами назвал) поговорить — почему их в С++ нет... Непринципиально.
PD>>Я одно хочу знать — смогу ли я на нем делать с той же эффективностью то, что я умею делать. S>Нет. То, что ты умеешь делать на плюсах, в рамках дотнета ты делать не сможешь.
Вот это и есть гланая проблема. Потому что ситуация такова, что мне , возможно, придется на этом С# писать. А задачи там не те, о которых ты думаешь. Там математика и статистика. Только бога ради, не надо объяснять, что тут лучше не Шарп, а что-то иное использовать. Я и сам бы рад. Да не получится. И мне надо знать, как из этой ситуации выходить. Вариант отказа не рассматривается. Вариант убедить заказчика тоже. Вот и все. И в этой ситуации , возможно, предстоит действовать.
S>Ну так и спрашивай напрямую. Не надо вокруг да около ходить, и кричать "да это очевидно неэффективно".
Хорошо. Следующий раз так и спрошу
S>Тебе решение уже предложили.
Да, с выходом на API. А теперь представь себе — я каждый раз должен очередную конструкцию тестировать или продумывать, не является ли она жутко неэффективной и надо выходить на API или unmanaged code ... Веселенькая перспектива.
S>Прекрасно. Тогда запасись профайлером, ildasm, а также смотри дизассемблированный код в отладчике.
Это-то я понимаю, но это же можно и для С++ посоветовать — для тех , кто его не знает. Только здесь очень быстро понимаешь, что дальше это ни к чему — библиотеки написаны довольно эффективно, компилятор код генерит в общем, тоже. А тут черт знает.
>Вообще невредно заранее представлять, что фреймворк писали не полные дауны. Поэтому на ровном месте граблей нет. Прикладная библиотека, с другой стороны, написана людьми значительно менее квалифицированными.
Вот тот-то и оно. А вот прикладная библиотека С++ (хоть С-шную RTL возьми, хоть STL , хоть MFC, хоть VCL — в исходниках дана). И этого мне, если что, достаточно. А здесь...
>Поэтому многие вещи там отсутствуют, а те, которые есть, рассчитаны на 90% пользователей (а не на тех, кто складывает 1000000 файлов в один каталог).
Во-первых, 100000, а не 1000000. 1000000 — я еще не пробовал . А во вторых, я просто не принимаю концепцию, когда мне предлагается неэффективное решение, когда есть эффективное.
S>Не, не хочу. Я просто представляю себе ширину сегмента приложений, которым важна пиковая производительность,
Я отложу ответ на эти соображения. Выскажу их потом, я об этом собираюсь здесь кое-что написать.
S>Ну как тебе сказать. Вот тут недавно выложили векторную рисовалку на дотнете с субпиксельной графикой. Не сказать, чтобы Visio прямо уж так был быстрее.
Может быть.
S>Гм. А чем твои собственные функции хуже стандартных?
А тем, что мне решать придется — стоит ли это на C# делать, или на unmanged переносить. В отличте от Win32, который переписывать мне не требуется.
>Пинвоку по барабану, кого вызывать.
А мне нет — как писать
PD>>К примеру (банальный) решиться мне, скажем, на C# матричные операции производить или же С++ DLL для этого написать, а в Шарпе только вызывать ее. S>Ты не пробовал, к примеру, вот здесь
Прочитал, спасибо. Увы, этого мне недостаточно. Во-первых, хотелось бы еще знать, сколько памяти они при этом потребили. Во-вторых, здесь используется совсем небольшие объемы данных, а вот что будет при обработке массивов размером в Мбайты ? Насколько эффективен доступ к массивам ? Тебе не хуже меня известно, что даже в чистом С++ при неудачном размере строки масиива (например, 4097 байт) можно сильно проиграть. И т.д. И т.д.
Здравствуйте, Pavel Dvorkin, Вы писали:
S>>Тебе решение уже предложили.
PD>Да, с выходом на API. А теперь представь себе — я каждый раз должен очередную конструкцию тестировать или продумывать, не является ли она жутко неэффективной и надо выходить на API или unmanaged code ... Веселенькая перспектива.
Я не сторонник managed языков (Java так вообще для меня как красная тряпка ), но вот здесь сразу вспоминается "Premature optimization is root of all...". Может сначала сделать правильно работающее решение без заморочек, а затем с помощью профайлера выяснить, чтоже лучше подправить?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот это и есть гланая проблема. Потому что ситуация такова, что мне , возможно, придется на этом С# писать. А задачи там не те, о которых ты думаешь. Там математика и статистика. Только бога ради, не надо объяснять, что тут лучше не Шарп, а что-то иное использовать. Я и сам бы рад. Да не получится. И мне надо знать, как из этой ситуации выходить. Вариант отказа не рассматривается. Вариант убедить заказчика тоже. Вот и все. И в этой ситуации , возможно, предстоит действовать.
Почему бы и не С#. Вопрос не в том что использовать, а как использовать. Если учитывать особенности той или иной среды, то можно и на VB6 вполне качественно писать.
PD>Прочитал, спасибо. Увы, этого мне недостаточно. Во-первых, хотелось бы еще знать, сколько памяти они при этом потребили. Во-вторых, здесь используется совсем небольшие объемы данных, а вот что будет при обработке массивов размером в Мбайты ? Насколько эффективен доступ к массивам ? Тебе не хуже меня известно, что даже в чистом С++ при неудачном размере строки масиива (например, 4097 байт) можно сильно проиграть. И т.д. И т.д.
И из 2 вопросов и одной догадки корректен только один вопрос.
Вся проблема в знаниях. Для ясного понимания как эффективно решить эту задачу, надо понимать три вопроса:
1. Механика различий между value-не value объектов.
2. Работа и особенности коллекций.(лучше в контексте Net 2.0 c генериками).
3. Работа GC с их популяциями.
Это конечно не все, но тот минимум который надо обязательно знать.
Информацию по всем этим вопросам можно найти на rsdn. здесь
Я думаю после прочтения данных статей, вопросы примут более корректный характер и будет перенесен в разряд "хочу выяснить интересную мелочь". Но не вопросы сравнение с unmanaged кодом.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да, с выходом на API. А теперь представь себе — я каждый раз должен очередную конструкцию тестировать или продумывать, не является ли она жутко неэффективной и надо выходить на API или unmanaged code ... Веселенькая перспектива.
Нет. Нужно просто писать так чтобы связаность программы была минимальна.
Если это условие соблюдено то в случае если получится недостаточно производительности берешь профайлер и переписываешь тормозной участок.
PD>Это-то я понимаю, но это же можно и для С++ посоветовать — для тех , кто его не знает. Только здесь очень быстро понимаешь, что дальше это ни к чему — библиотеки написаны довольно эффективно, компилятор код генерит в общем, тоже. А тут черт знает.
Тут тоже все нормально.
PD>Вот тот-то и оно. А вот прикладная библиотека С++ (хоть С-шную RTL возьми, хоть STL , хоть MFC, хоть VCL — в исходниках дана). И этого мне, если что, достаточно. А здесь...
А здесь есть Reflector
PD>Прочитал, спасибо. Увы, этого мне недостаточно. Во-первых, хотелось бы еще знать, сколько памяти они при этом потребили. Во-вторых, здесь используется совсем небольшие объемы данных, а вот что будет при обработке массивов размером в Мбайты ? Насколько эффективен доступ к массивам ? Тебе не хуже меня известно, что даже в чистом С++ при неудачном размере строки масиива (например, 4097 байт) можно сильно проиграть. И т.д. И т.д.
Нормально там все. Я лично написал на чистом шарпе diff который находит разницу между двумя файлами размером в несколько гигабайт(бэкап базы RSDN)
Единственное что пришлось делать руками это писать свою хеш-таблицу на value-типах ибо миллионы мелких объектов для ГЦ тяжеловато темболие если есть value-типы.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, henson, Вы писали:
VD>Это из серии у кого чего болит.
Точно!
H>>Лично мне пока хотелось иметь такие вещи: H>>1) XML диалект для описания объектной модели приложения с инструментом для динамической генерации исходников на C# и Java (хотя бы), а также структуры базы данных, чтобы окончательно отделить логику приложения от исходных текстов программы VD>XSLT к твоим услугам.
Представляете, я им даже пользуюсь! Но это ни на шаг не приближает меня к описанию объектной модели. Да чтобы я мог ей еще и поделиться и меня при этом поняли все, а не узкий круг ограниченных людей. Нужен готовый цельный стандарт, а не самодеятельность на заданную тему.
H>>2) XML диалект для унифицированного описания GUI приложения, чтобы отделить интерфейс от логики и исходных текстов приложения H>>3) Везде перейти от абсолютного позиционирования элементов GUI к относительному VD>Avalon к твоим услугам.
Где? Это пока только проба пера. И только под бету системы ожидаемой только через год. И почему это вообще должно быть связано с операционкой?
H>>4) Перейти к системам контроля версий (CVS) оперирующими не файлами, а объектами приложения VD>Это нафиг не упало. Но сделать можно.
Если есть объектная модель зачем возня с файлами?
H>>5) Библиотеки функций и алгоритмов в Интернет/Интранет, ставишь в исходном коде ссылку и все, получается как WebService, но на уровне исходных текстов VD>Это есть начиная с VS 2002.
Это шутка? Есть вызов WebService'ов, а не вставка кусков кода.
H>>В общем основное IMHO — это что сейчас необходимо совершенствование не самих языков, а средств проектирования и разработки приложений, пора уже идти дальше UML и RUP, пора закрыть вопросы, связанных с форматированием кода, все должно быть автоматически: нужное количество табуляций и пробелов, положение { и } и т.п. VD>Это есть если установить ReSharper или VS2005.
Угу, только большинство этим не пользуются иначе бы каждая контора не лепила свои правила оформления исходного кода
VD>Ты спал что ли последние 5 лет?
Да бросьте Вы, есть решения изначально правильные, а есть по принципу "если очень хочется, то можно".
Видимо Вам существующих инструментов достаточно для разработки, мне нет
Здравствуйте, VladD2, Вы писали:
H>>2) XML диалект для унифицированного описания GUI приложения, чтобы отделить интерфейс от логики и исходных текстов приложения H>>3) Везде перейти от абсолютного позиционирования элементов GUI к относительному VD>Avalon к твоим услугам.
Что значит "абсолютное и относительное позиционирование"?
И можно ли считать расположение виджетов на форме (в Delphi, к примеру) по принципу выравнивания: "по какому-то краю", "на всю незанятую область" и т.д. — "относительным" позиционированием?
Менеджеры (Layouts Managers) проблему разве не решают? Напишите свой!
H>>4) Перейти к системам контроля версий (CVS) оперирующими не файлами, а объектами приложения VD>Это нафиг не упало. Но сделать можно.
Что есть "объект" в такой системе? Описание всего класса? А как быть с анонимными классами?
H>>5) Библиотеки функций и алгоритмов в Интернет/Интранет, ставишь в исходном коде ссылку и все, получается как WebService, но на уровне исходных текстов VD>Это есть начиная с VS 2002.
Что-то я не совсем понимаю.
В Java есть переменная среды CODEBASE, которая может указывать куда угодно даже во время написания кода.
Это ОНО?
H>>В общем основное IMHO — это что сейчас необходимо совершенствование не самих языков, а средств проектирования и разработки приложений, пора уже идти дальше UML и RUP, пора закрыть вопросы, связанных с форматированием кода, все должно быть автоматически: нужное количество табуляций и пробелов, положение { и } и т.п. VD>Это есть если установить ReSharper или VS2005.
Зачем такие сложности?
В независимых (от операционной системы) средах программирования (NetBeans, IDEA, Eclipse и др.) это давно и успешно работает, достаточно нажать определённую комбинацию клавиш, заведующую форматированием кода.
Странно, что большое число компаний устанавливают какие-то внутренние "стандарты" оформления кода, когда проблема-то решается на местах "горячей клавишей" в среде того человека, кто этот код читает.
Проблема надуманна и раздута.
VD>Ты спал что ли последние 5 лет?
(Вопрос, конечно, не ко мне, но откомментирую)
Почему именно 5? XML, XSLT, продвинутые среды программирования и т.д. появились гораздо раньше VS. И не стоит ограничивать кругозор только этой (далеко не самой лучшей) средой.
А henson, по-моему наблюдению, занимается этими фишками достаточное продолжительное время.
Да, henson?
Здравствуйте, eao197, Вы писали:
E> Фактически, подмешанные модули становятся суперклассами.
Маленькая поправочка: классические подмешивания становятся как-бы подклассами. То есть, если в подмешивание П, добавить в класс К, то в результате появится некий тип у которого К базовый класс, а П — дочерний. То есть подмешивание это абстрактный подкласс. Если использовать из подмешивания псевдопеременную super (base, или что-там есть для обращения к родительскому классу), то она должна привести к обращению к методам класса, к которому подмешивали. Этакий декоратор получается.
Вероятно из-за такого неочевидного поведения они и не получиди широкого распространения. Традиционная схема наследования применяется в traits (можно поискать по этому форуму ссылки).
Появилась такая странная схема в Flavors, разработанном для Symbolics и который был одним из предшественников CLOS. Вообще, множественное наследование в CLOS реализовано оч-чень оригинально. Если класс В унаследован и от А и Б, который тоже унаследован от А, то компилятор "выпрямляет" иерархию так, что получается, что класс В унаследован от Б, который унаследован от А. Плюс при выпрямлении оставляется только один класс в иерархии.
То есть не такое:
А
/\
| Б
\/
В
а такое:
А
|
Б
|
В
Подмешивания же при добавлении в иерархию всегда ставятся в её конец.
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, GlebZ, Вы писали:
GZ>>(eao197: class method в Ruby является синонимом статического метода в C++)....(eao197: instance method в Ruby является синонимом не статического метода в C++)?".
GZ>>Терминология мне жутко понравилась. Просто и ясно, без синтетического static.
Кё>В С++ дофига таких ляпов То же static в другом контексте означает изменение видимости символа для линкера.
Это не ляпы, а перегрузка ключевых слов. Ты знаком с историей C++?
PD>то это срабатывает мгновенно, и памяти программа по TaskManger — Mem Usage занимает 672 Кб.
А почему счётчик аж до 100? До 10 ещё быстрее страбатывало бы
Вообще-то на .NET это будет выглядеть один в один. На MC++. На шарпе можно поизрвщаться немного с DllImport и получится тот же результат.
В общем, в очередной раз, как я и подозревал, в наличии необоснованные наезды
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Просто и ясно, без синтетического static.
Если нам не помогут, то мы тоже никого не пощадим.
