Здравствуйте, Глеб Алексеев, Вы писали:
E>>Нужно только понимать, что для каждой задачи нужен свой язык. ГА>Да, да, да! Так и есть! И можно а) выбрать его из всего доступного инструментария — (Питоны, ОКамлы, ХАскели, Перлы, и Явы, C и C++, естественно) или б)реализовать на единственном языке, который знаешь от и до. Мне вариант а) больше импонирует.
До тех пор, пока не придется впрягать в проект людей, менее увлеченных программированием, чем ты.
Или увлеченных другим направлением в программировании.
Проверено, на личном опыте
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
>> Последний раз — GC не запрещает вручную выделять память. И попробуйте >> сказать обратное. C>Не запрещает. Но делает это очень неудобным для использования, да еще и
Это чем оно делает неудобным?
C>добавляет проблем — GC во время циклов сборки должен сканировать C>выделенные пользователем блоки памяти.
Да ну?
C>Это создает проблемы с расшареной памятью — может возникнуть race C>condition с другим процессом.
Сразу видно человека, который не любит теорию. Это кстати и к сканированию памяти относится.
C> Массивы объектов тоже должны особым C>образом инициализироваться. В общем, RTFM стандарт C++/CLI — там C>подробно эти сложности расписаны.
Меня не интересует С++/CLI
В общем-то меня не интересует как С++, так и CLI по отдельности.
Я люблю высокие технологии, а не непонятно с какого века оставшиеся.
Так что их проблемы — не мои проблемы. И проблемы С++ — не мои.
А вы мне зачем-то пытаетесь продать эти проблемы под видом конфет.
>> При это по ссылке приведены функции, аналог которых попробуйте найдите >> в С++.
C>С++/CLI или Boehm GC — для тех кому это нужно. В большинстве случаев GC C>_не_ нужен.
Знаете, я вам вот что скажу. GC — это вещь фундаментальная для языков программирования. Она или есть или ее не может быть. В с++ — не может. Boehm проблем не решает как организационно, так и с производительностью.
Говорить мне, что мне GC не нужен — не стоит. Он мне нужен и прямо сейчас.
И что его не только отсутствие, а невозможность сделать в принципе — это достоинство, это полная дичь.
>> C>В С++ для этого есть другие средства. Зачастую более адекватные. >> Покажите как в С++ дефрагментировать кучу
C>1. Не фрагментировать ее. Тем более, что в С++ достаточно для этого средств.
гениально. получите апплодисменты.
C>2. Использовать memcpy-moveable-объекты.
где использовать-то? внутри third party библиотек?
C>3. Сделать move constructor объектам и дефрагментировать на здоровье.
о да, это тоже гениально
C>4. Использовать уплотняющий GC.
ну дайте же мне уплотняющий GC для C++
дайте tracing copying incremental mark-n-sweep GC, пусть он будет двадцатилетней давности
я ведь такую мелочь прошу, я ведь не прошу вас обеспечить С++ region inference
C>5. Еще что-то можно придумать.
Конечно, что мы, не гении чтоли, впрямь
>> Скажите зачем вам нужно выделять руками память и освобождать ее.
C>Это не требует GC. Консервативный GC ведь вам не нравится, а точный GC C>тянет за собой слона.
Не тянет. Если это не С++
>> C>Руками освобождать ресурсы. Дикость в современном С++. >> Это дикость везде.
C>Только не в языках с GC. Там это норма.
в языках с GC норма — руками освобождать ресурсы?
по-моему вы уже заговариваетесь.
>> Но в данном случае вы говорили про ручное управление. Вас шатает из >> стороны в сторону. Держитесь.
C>Простите, но связь между этими двумя понятиями — одно из самых больших C>преимуществ. И вы после этого говорите, что знаете С++????
Я там вам выше уже все написал про продажу прошлогоднего снега.
Еще раз — С++ не является самым оптимальным как в плане мемори менеджмента, так и в плане расширяемости языком.
Если С++ смогли как-то расширить, чтобы засунуть в библиотеки какие-то вещи (потому что без них он совсем отстой), это еще не значит, что нигде это больше невозможно. А вот нормальный GC в С++ невозможен. А у других он просто есть.
>> Или хотите сказать, в Cyclone нельзя делать этого автоматически?
C>Нет. В Cyclone нет деструкторов с С++ной семантикой вызова.
да вы что. серьезно? чего еще там нет?
>> C>Нет, благодаря *средству языка* (а именно placement new) можно >> C>реализовать свое управление памятью для объектов. И в частности данную >> C>систему. >> Вот этого я не понял. Хотите сказать, синтаксическая возможность >> написать new (buffer) — это достижение и уникальная особенность?
C>Да (достижение, хотя и не уникальное). Как мне такое сделать в OCaml? Вы C>подумайте как это сделать, и что это за собой влечет для GC.
Что, как отщипнуть от готового буфера кусок? написать функцию new?
Или hello world написать?
А че для камловского GC это влечет? по-моему, вообще ничего. А по-вашему?
>> C>И что? Можно и точный GC для С++ сделать, но это потребует >> кооперации со >> C>стороны программиста. В библиотеке Boost.Regex, например, есть такой >> C>один (хотя и примитивный). >> Нельзя.
C>Можно. Смотрите tracking_ptr.hpp из xpressive в Boost'е, например. В C>xpressive используется простой _точный_ GC.
Вы видимо принципиально не понимаете о чем вообще речь.
Что со своими аллокациями я могу разобраться, я в курсе. Но речь не обо мне, а о С++
и о чужих объектах с адресной арифметикой и прочим говном.
И не нужно говорить, что проблема решаема. Поскольку вы предпочитаете обычно теорию не знать, я вам скажу, что эта проблема в общем случае не решается. Можете конечно потратить пару лет своей жизни, чтобы доказать всем какой С++ крутой и убедиться в конце в этом на практике.
>> Или покажите мне как взять например wxwidgets и запустить его под >> инкрементальным GC который еще автоматом отучит каждый объект при >> создании требовать указания родителя.
C>А нафига это в wxWidgets нужно? Там вполне хватает ручного управления C>памятью.
НЕТ. МНЕ не хватает. Я не хочу ничем управлять и создавать объекты в строгой последовательности.
хочу красивой жизни как в нормальных средах.
>> C>Да? Читаем: автоматические объекты — одна из центральных фич языка. >> Это не фича, это баг.
C>Ну да. Их же нет в OCaml'е....
Ха.
>> C>Умные указатели — требуют перегрузки оператора разыменования, так что >> C>это тоже языковая особенность. Placement new — одна из форм ключевого >> C>слова new. >> И таким образом все эти уникальные особенности сводятся к возможности >> перегружать операторы?
C>Как мне в OCaml перегрузить оператор обращения к члену структуры?
Что вы там говорили про свое программирование на окамле? не повторите?
Вы на нем программировали и на хаскеле еще и решили, что они — так себе?
Видимо нужно заканчивать эту глупую беседу.
>> C>Вы не понимаете значение слова "гибкость"? Или наивно полагаете, что >> C>можно предусмотреть все случаи использования заранее? >> Это не гибкость, это затычки для тех дыр, которые можно кое как >> заткнуть в С++. >> Сделать такое хоть в хаскеле не представляется проблемой. >> но там это просто _не нужно_.
C>Почему-то вы считаете GC — панацеей. И в упор не видите проблем, которые C>он создает.
Это у вас странное представление как о GC так и об окамле с хаскелем.
И вы в упор не видите проблем, которые не только вам, но и всем вокруг создает С++ и весь этот закат солнца вручную.
>> C>Имеем: библиотека VTK, все объекты в ней создаются с помощью >> C>статического метода New, а уничтожаются методом Delete. Требуется >> C>написать функцию, которая будет создавать объект, чего-то с ним >> делать и >> C>возвращать его. При этом я не должен заботиться о необходимости ручного >> C>вызова Delete. >> Хотите сказать, где-то так нельзя? C>Да.
Вообще здорово. А че мешает? Никогда вот delete не вызываю.
C>Например в OCaml. Внимание на строчку про "не должен заботиться о C>необходимости ручного C>вызова Delete". В финализаторе, естественно, это делать тоже нельзя.
дада, операторы не перегрузишь, потому что их нет, следовательно рефкаунтер не сделаешь
бросьте эти дурацкие языки, действительно.
>> Я вам там кидал ссылку на то, что в стандартной библиотеке хаскеля это >> делает.
C>Ткните пальцем.
тык: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign.html
>> C>Когда я в последний раз смотрел — еще не было. Теперь добавили, но все >> C>равно с ограничениями. >> Знаете, это не разговор. Ручное управление памятью — это очень низкого >> уровня класс задач. >> И Cyclone при этом дает ее выполнять с помощью гораздо более >> высокуровневых инструментов, чем С++ >> и гораздо мощнее.
C>Не вижу тучи проектов на этом супермощном языке. А лет ему немало уже — C>я его в 2001 еще смотрел (если не раньше).
а я вот не вижу моря из окна
>> C>Это _использование_ C через проксики, а не полноценная >> C>интероперабельность с ним. А то так можно взять SOAP и сказать, что с >> C>помощью него можно с С интероперировать. >> Можно, а что вас не устраивает, кстати?
C>1. Скорость. C>2. Уровень интеграции. C>3. Трудоемкость сложной интеграции.
Скорость чего? врапперов?
Прикольно.
>> C>Битовые поля? union'ы? #pragma pack? Поддержка __stdcall, __fastcall и >> C>других calling conventions. Поддержка сторонних аллокаторов. >> ЭЭ... foreign import stdcall в хаскеле? Ну и я там ссылку кидал на >> модуль Foreign.*
C>А __thiscall с __fastcall'ом? В доке по FFI написано про всего две C>конвенции — "по умолчанию" и stdcall. Я кстати еще про распространенную C>pascal-конвенцию забыл.||*||*
>> Что мешает _кому угодно_ завести такую поддержку?
C>Так ведь не сделали? Значит, что-то мешает.
А еще не сделали оператор delete, наверное что-то мешает
и auto_ptr
>> Да, C# движется, пока не дойдет до F# >> а F# движется пока не дойдет до окамла.
C>Мечтатель...
>> О чем вы там вообще? Что еще за JIT и каким образом это относится к >> окамлу? >> Ну и мельчайшие подробности. Вы откуда это взяли?
C>Кхм. Вообще-то JIT — это Just-In-Time компляция, не знать этого стыдно C>(кстати, в OCaml'е оно есть для байт-кодов). И читайте всю тему, а не C>одно сообщение.
@#$%@#$% я знаю что такое JIT, я не понял какого хрена он делает в разговоре об окамле и его GC
и тему не хочу читать. я и так слишком много всего прочитал уже лишнего и глупого.
C>Ну да, если я уверен, что в моем коде нет алиасинга, то я могу дать хинт C>оптимизатору с помощью атрибута restrict.
Я в общем-то желаю вам программировать на С++ как можно дольше. Мне кажется это правильно вообще, да.
Я вообще сторонник здоровой экологии.
GlebZ wrote: > > Почти все правильно. Основной плюс функциональных языков — это > математика. Очень большой плюс. Основной минус функц. языков — это > математика. Слишком на эту математику все завязано. А это не панацея. > Большинство коммерческих продуктов — это большое количество сущностей с > простейшими алгоритмами. На императиве можно меньше думать и больше > делать. В случае функциональных языков для подобных задач приходится
Идея меньше думать и больше делать на мой взгляд губительна для
компутерной индустрии. У нее есть только один плюс: можно включить в
проект произвольное количество индусов, и производительность будет расти
прямо пропорционально количеству исполнителей (а не как, например,
логарифм от нее).
Остальное — сплошные минусы. Например то, что компутеры имеют устойчивую
репутацию ненадежной вещи, склонной к глюкам и отказам, это прямое
следствие широкого применения этой идеи.
Глеб Алексеев wrote: > > Как раз с точностью наоборот. Unix'ы были созданы в американских > университетах, и все новые языки появляются в первую очередь именно под > юниксами. С инструментальной поддержкой (отладчики, интегрированные
Забавно, что C# это первый язык, который добился широкой известности, не
будучи перед этим рожденным в юниксовской среде.
Интересно, можно ли на этом основании делать вывод, что C# умрет, так и
не осуществив возлагаемых на него надежд? Я склонен думать, что да.
Микрософт при этом совершает совершенно героический поступок, поставив
все фишки на технологию, которая не была 20 лет обкатана на юниксе...
Здравствуйте, Pzz, Вы писали:
Pzz>Микрософт при этом совершает совершенно героический поступок, поставив Pzz>все фишки на технологию, которая не была 20 лет обкатана на юниксе...
Как будто MS-DOS и Windows были обкатаны на Unix-е
И ничего, справились
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, reductor, Вы писали:
C>>Только не в языках с GC. Там это норма.
R>в языках с GC норма — руками освобождать ресурсы? R>по-моему вы уже заговариваетесь.
Вообще-то, в словах "управление памятью" напрямую указано, каким именно ресурсом может оперировать сборщик мусора. Но, увы, ресурсом, является не только память программы.
eao197 wrote: > > Pzz>Микрософт при этом совершает совершенно героический поступок, поставив > Pzz>все фишки на технологию, которая не была 20 лет обкатана на юниксе... > > Как будто MS-DOS и Windows были обкатаны на Unix-е > И ничего, справились
MS-DOS, так сказать, не добавляет ничего нового. Те немногочисленные
идеи, которые в него все же были заложены, так или иначе на Unix'е были
обкатаны.
Идеи Windows'а были обкатаны на VMS'е. Наверное, это можно считать хоть
и плохой, но заменой. Кроме того, своих идей в Windows'е не так уж и
много. Windows в основном, это не полет фантазии, а тяжкий физический труд.
C# это другое дело. Это все-таки язык программирования. Штука,
нуждающаяся в высокой культуре. А без оной культуры получится очередной
Visual Basic
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Например, из заметных публично, в Civilization IV используется по крайней мере Boost.Python
Интересно, это по этой причине мне так и не удалось построить три чуда за один тур? (Процесс civilization4.exe съедает 2 Гб виртуальной памяти, после чего игра просто закрывается.)
Здравствуйте, Pzz, Вы писали:
Pzz>Забавно, что C# это первый язык, который добился широкой известности, не Pzz>будучи перед этим рожденным в юниксовской среде.
Pzz>Интересно, можно ли на этом основании делать вывод, что C# умрет, так и Pzz>не осуществив возлагаемых на него надежд? Я склонен думать, что да.
Pzz>Микрософт при этом совершает совершенно героический поступок, поставив Pzz>все фишки на технологию, которая не была 20 лет обкатана на юниксе...
Она так или иначе была обкатана в виде Явы (а теперь точно минусов нахватаюсь).
Здравствуйте, Pzz, Вы писали:
Pzz>Идея меньше думать и больше делать на мой взгляд губительна для Pzz>компутерной индустрии. У нее есть только один плюс: можно включить в Pzz>проект произвольное количество индусов, и производительность будет расти Pzz>прямо пропорционально количеству исполнителей (а не как, например, Pzz>логарифм от нее).
Абсолютно верно. Но давай посмотрим на процесс разработки больших программ.
1. Постановка функциональных требований
2. Архитектура
3. Дизайн и программирование (часто они идут вместе, но если дизайн делает знающий человек, то тут ни один индус не поможет).
4. Тестирование и стабилизация.
Пункт 3 не самый затратный. Остальные пункты значительно важнее в смысле ответсвенности и качества. Да, я вынужден признать что в силу ограниченности функциональных языков(а поднятие императива на функциональном языке мне очень не сильно нравится) требуется повышенное внимание к дизайну. Тут хочешь или не хочешь будешь им заниматься. А для большой программы, будешь заниматься долго и нудно. И именно это компенсирует ту быстроту написания кода которую дают функциональные языки. Для небольшой программы все будет OK. Если тебе надо связать большое количество сущностей и взаимосвязей, то будет уже не все так весело.
?
Принимается Из недостатков — вызов функции (помним, что слово "inline" компилятор ни к чему особенному не обязывает). Как отсутствие этого недостатка — дублирование кода. Но из-за "мелкости" этой проблемы (дубляж не более чем 10-15 байт) ею пренебрегаем. Но... даже из-за 15 байт жаба душит, но это — субьективное...
Как более серьезный недостаток — ухудшение понимания. В моем варианте — проблемная точка — программист должен "грокнуть" факт что перед началом цикла текущий бит всегда "1" и комментарий это облегчает.
В твоем случае — он должен "грокнуть" функцию "shift_mask" которая находится где угодно, но не в месте вызова. Т.е. программист должен пробраузить к этой функции, сопоставить ее аргументы (и не забыть хытрую ссылку-на-указатель) с аргументами вызова, вернуться назад. И так — два раза. И еще, имя shift_mask такое "describing", что просто ататат.
E>то пусть указывают... точный источник: издание, главу и, желательно, страницу.
Журнал "Монитор" за 19забытый год, N3, стр 25
В данном случае, это "Handbook of Applied Cryptography", алгоритм 14.76
DEA>>ЗЫ. Когда приходят к нам наниматься, я прошу кандидата с написать с нуля любой алгоритм E>А на какую позицию они претендуют?
Программист. Причем, этот тест не влияет на вопрос "принятия". А вот на величину начальной зарплаты и последующую работу — таки да... Непроходимцам поручается самое тупое и неинтересное. По крайней мере поначалу.
E>Я бы, например, с ходу бы задумался, прежде чем вспомнить какую-нибудь сортировку. E>А потом бы еще покурил, прежде чем написал код. И все равно не был бы уверен в корректности E>его работы без тестов.
Ну... у тебя есть контупер со средой (VS7.1) и неограниченное время. (На самом деле "неограниченное" означает полчаса — т.е. я приду и поинтересуюсь результатом а через час — выгоню). Для борландистов, есть Notepad и всепрощающий я, который по первой просьбе скомпилирует код с командной строки при помощи того же MSVC. Или... та же среда программирования. Программируй, отлаживайся — делай че хочешь.
E>Просто потому, что писать реализации алгоритмов сортировки мне приходилось только во время учебы.
Кое-какие вещи надо помнить... Или вспомнить... Или "изобрести"... Неважно.
Просто эта сортировка — одна из простейших проблем. Очень хорошо подходит для тестов. По крайней мере, она показывает насколько кандидат умеет пользоваться мозгами в применении к программированию.
__________
16.There is no cause so right that one cannot find a fool following it.
AVC wrote: > > Pzz>Но влияние-то оказывает > > Меня как раз тут в свое время "уличали" (eao197 и CrystaX), что я пишу > на Си с классами, а не на "современном" Си++ (с шаблонами и большим > boost-ом). > Так что на меня шаблоны оказывают весьма умеренное влияние (в основном — > в виде ночных кошмаров).
А ночные кошмары, это не влияние?
> А ML — вообще никакого. (Допускаю, что обо этом как раз следует пожалеть). > Чтобы не выглядеть совсем уж троглодитом, немного поясню свою позицию. > Вот здесь Cyberax писал (в посте к reductor), что знание математики, > алгоритмов и т.д. должно быть где-то в "background". > Как видно, в foreground он любовно разместил ("современный") Си++ и > подобные ему языки. Весь этот, с позволения сказать, инструментарий > съедает 90% (а то и более) времени программиста. И выходит так, что > хвост виляет собакой. > Я же полагаю, что как раз язык следует разместить в background. А то и > вообще в "подкорке", чтобы не отвлекал от самой задачи.
Согласен.
И добавлю: C++ тем и плох, что приходится слишком много плясать вокруг
языка, а не собственно проблемы.
Можно сказать и по-другому, более оптимистично: для любой реальной
проблемы в языке C++ существует прямая поддержка (т.е., любая проблема в
какой-то момент превращается в проблему с языком).
Я как-то был поражен, зайдя в знакомую контору, и обнаружив, что там
собралась толпа программистов, и обсуждеает, как им выкрутиться из
очередной нетривиальной проблемы, которую поставил перед ними C++. Как
эта проблема содержательно соотносилась с решаемой задачей, я так и не
понял...
Здравствуйте, Pzz, Вы писали:
Pzz>Я бы написал сортировку пузырьком, чтобы не рисковать в стрессовых условиях собеседования.
И прошел бы. А вот за "quicksort", подвергся бы жестоким нападкам на тему "А докажи что это работает". Ведь это не тест на "память", а тест на умение пользоваться мозгами. И тебе (не без оснований заподозренному в "зубрежке" или "абсолютной памяти") пришлось бы доказывать... Если у тебя "абсолютная память", то доказал бы... или, если додумался "зазубрить" и доказательство... Педантичность такого рода тоже приветствуется.
Pzz>Опыт показал, что такой подход позволяет очень хорошо узнать человека как специалиста,
Именно. А насчет идеи "набора задач" — спасибо. Примем на вооружение.
__________
16.There is no cause so right that one cannot find a fool following it.
? DEA>Принимается Из недостатков — вызов функции (помним, что слово "inline" компилятор ни к чему особенному не обязывает). Как отсутствие этого недостатка — дублирование кода. Но из-за "мелкости" этой проблемы (дубляж не более чем 10-15 байт) ею пренебрегаем. Но... даже из-за 15 байт жаба душит, но это — субьективное...
А вот это еще вопрос. Интересно было бы сравнить оба варианта на производительность. Хотя бы в VS C++ и GNU C++.
DEA>Как более серьезный недостаток — ухудшение понимания. В моем варианте — проблемная точка — программист должен "грокнуть" факт что перед началом цикла текущий бит всегда "1" и комментарий это облегчает.
Кстати, я бы вообще вынес это в отдельную функцию, вроде find_starting_point, чтобы while-ом не загромождать логику.
DEA>В твоем случае — он должен "грокнуть" функцию "shift_mask" которая находится где угодно, но не в месте вызова. Т.е. программист должен пробраузить к этой функции, сопоставить ее аргументы (и не забыть хытрую ссылку-на-указатель) с аргументами вызова, вернуться назад. И так — два раза. И еще, имя shift_mask такое "describing", что просто ататат.
А в чем проблема? Задача в shift_mask -- это сдвинуть бит. Обзови еще shift_mask_bit. И заметь, выход из do..while стал гораздо понятнее: когда сдвигать больше нечего.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
? DEA>>Принимается Из недостатков — вызов функции (помним, что слово "inline" компилятор ни к чему особенному не обязывает). Как отсутствие этого недостатка — дублирование кода. Но из-за "мелкости" этой проблемы (дубляж не более чем 10-15 байт) ею пренебрегаем. Но... даже из-за 15 байт жаба душит, но это — субьективное...
E>А вот это еще вопрос. Интересно было бы сравнить оба варианта на производительность. Хотя бы в VS C++ и GNU C++.
Думаю, твой был на чуть-чуть хуже. Но это чуть-чуть во всех смыслах — ниже уровня погрешности. Разницы-то пара инструкций + код несколько вырос. Именно поэтому я написал "принимается". По крайней мере, на алгоритмах типа RSA или Diffie-Hellman key exchange эта разница вообще не будет видна.
E>Кстати, я бы вообще вынес это в отдельную функцию, вроде find_starting_point, чтобы while-ом не загромождать логику.
...точно ту же функцию выполняет и "while". Но, так как он не используется повторно, то он лишен чести вынесения в отдельную функцию. А великую честь смысловой нагрузки может выполнить и комментарий (который я разместил несколько нестандартном месте, и написал некорректно) Надо было написать "skip to the highest '1' bit".
E>А в чем проблема? Задача в shift_mask -- это сдвинуть бит. Обзови еще shift_mask_bit.
Как тебе сказать... Я привык анализировать код "линейно". То есть: сверху и вниз. Как текст.
"Прыжки" вроде вызова функций рвут мне контекст. B еще, возникает вопрос: "а не вызывается ли эта функция где-то еще". Опровержение этого факта (пренебрежение этим шагом пару раз мне дорого стоила) займет пару минут + "переключение" в другой контекст (поиск файле, а если это .h-файл, то и во всем source tree).
E>И заметь, выход из do..while стал гораздо понятнее: когда сдвигать больше нечего.
Да. Не прибавить ни отнять.
Но... Прежде ты должен понять-принять-определить (те "грокнуть") независимую сущность. Имя этой сущности — функция shift_mask() с данным (не забываем об оверлоаде) набором аргументов.
ЗЫ. "Грокнуть" это из "Чужеземец в чужой стране" Хайнлайна. Must read
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 0xDEADBEEF, Вы писали:
E>>А вот это еще вопрос. Интересно было бы сравнить оба варианта на производительность. Хотя бы в VS C++ и GNU C++. DEA>Думаю, твой был на чуть-чуть хуже. Но это чуть-чуть во всех смыслах — ниже уровня погрешности. Разницы-то пара инструкций + код несколько вырос. Именно поэтому я написал "принимается". По крайней мере, на алгоритмах типа RSA или Diffie-Hellman key exchange эта разница вообще не будет видна.
Не уверен. При нынешних оптимизирующих компиляторах я бы не стал что-либо утвержать без замеров.
E>>Кстати, я бы вообще вынес это в отдельную функцию, вроде find_starting_point, чтобы while-ом не загромождать логику. DEA>...точно ту же функцию выполняет и "while". Но, так как он не используется повторно, то он лишен чести вынесения в отдельную функцию. А великую честь смысловой нагрузки может выполнить и комментарий (который я разместил несколько нестандартном месте, и написал некорректно) Надо было написать "skip to the highest '1' bit".
А теперь представь, если бы ты так функцию обозвал: skip_to_highest_1bit(...) -- ни комментариев, ни места лишнего, ни оверхеда в run-time.
E>>А в чем проблема? Задача в shift_mask -- это сдвинуть бит. Обзови еще shift_mask_bit. DEA>Как тебе сказать... Я привык анализировать код "линейно". То есть: сверху и вниз. Как текст. DEA>"Прыжки" вроде вызова функций рвут мне контекст. B еще, возникает вопрос: "а не вызывается ли эта функция где-то еще". Опровержение этого факта (пренебрежение этим шагом пару раз мне дорого стоила) займет пару минут + "переключение" в другой контекст (поиск файле, а если это .h-файл, то и во всем source tree).
Это спорный вопрос. Меня лично функции не напрягают. Особенно количество их вызовов. А вот направление goto -- очень даже.
DEA>ЗЫ. "Грокнуть" это из "Чужеземец в чужой стране" Хайнлайна. Must read
Не, фантастика же давно не Must read. К сожалению
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Не уверен. При нынешних оптимизирующих компиляторах я бы не стал что-либо утвержать без замеров.
Обьясни плз свой оптимизм по поводу любого из вариантов. Заметь, я говорю что и твой и мой варианты по большому счету — эквивалентны. Впрочем, в понедельник я предоставлю результаты (source tree на работе находится).
А мой пессимизм основывается на... моем опыте. Посмотрим что сильнее. Кстати, полных исходников не дам — они — коммерческая тайна.
E>А теперь представь, если бы ты так функцию обозвал: skip_to_highest_1bit(...) -- ни комментариев, ни места лишнего, ни оверхеда в run-time.
Я не понимаю, почему я должен выносить этот кусок в отдельную функцию.
Он (а)он прост и очевиден (для тех кто знает как работать с битами, конечно) (б)используется только в одном месте (б)не требует введения дополнительных переменных. (с)логически является частью этого и только этого алгоритма.
Так, что, поподробнее: какие преимущества?
E>Это спорный вопрос. Меня лично функции не напрягают. Особенно количество их вызовов. А вот направление goto -- очень даже.
Еще раз: функция это ОТДЕЛЬНАЯ, НЕЗАВИСИМАЯ сущность. Она "рвет контекст", и вызывает сомнения в своем предназначении. А еще, поселившись в исходнике, она начинает ЖИТЬ САМА ПО СЕБЕ.
Это означает, что в развесистом исходнике, какой-то совершенно левый индус, которого ты и в лицо не видел, решит задействовать ТВОЮ функцию для СВОИХ целей. Естественно, он, как "грамотный программист" обьявит ее в своем гадюшнике. А потом ТЫ (через полгода), маленько подправив СВОЮ функцию, с удивлением обнаруживаешь что ты(именно ТЫ!!!) ЗАВАЛИЛ БИЛД! Или на тебя свалилась куча БАГОВ.
Итог: полпачки спаленных сигарет, пятиминутка ненависти к индусам и ДЕНЬ РАБОТЫ.
Хочу сказать, слава богу, это произошло не со мной. Но процесс наблюдал "вживую" и воспоминания о нем — самые тягостные.
E>Не, фантастика же давно не Must read. К сожалению
Не буду разубеждать, но имхо, многое теряешь. Например, альтернативный взгляд на многие вещи. И все же, эта вещь Must read, хотя ты и сопротивляешься
Впрочем, фантастика нынешняя и фантастика вообще — вещи мало пересекающиеся.
__________
16.There is no cause so right that one cannot find a fool following it.
: функциональные языки какие крутые (круче них, понятное дело, только яйца)! Вот почему они мейнстримом не стали понять до сих пор не могу?
Мейнстримом еще не стали. Почему? куча причин. Например, их туда никто не продвигал. Это всегда были два разных мира — IBM, пишущая операционные системы на ассемблере, и какие-нибуть самодостаточные МИТовские хакеры, которые на деньги Пентагона делали искусственный интеллект. ООП вот тоже появилось в 60-х годах, а мейнстримом стало в 90-х. Да и вообще, индустрия молодая, у нее еще все впереди.
Влияние функциональных языков, на мой взгляд, и сейчас весьма заметно. C++ STL, например. Или вот вам понравилось передавать функции как параметры в Руби — это оно самое и есть. Функциональный стиль программирования так или иначе
поддерживает большая часть вполне мейнстримных языков: Java Script, Python, Ruby, Perl, Lua, C#. Другое дело, что и на них большинство людей будут продолжать писать, как на своем предыдущем Впрочем, вы сами все это знаете.
Я хотел сказать, что, безотносительно практического применения, посмотреть простенький функциональный язык типа Scheme в сочетании с какой-нибудь очень хорошей вводной книгой типа SICP может быть очень полезно и для программирования на Руби, С++, boost::mpl и.т.д, т.к с концепциями и абстракциями лучше знакомиться по оригиналам, а не по имплементациям, сделанным для расширения Feature-list
E>А чего здесь вообще должно делаться? Матрица на матрицу перемножаться?
Ага.
E>Ну и сколько Scheme-программисту нужно будет изучать C++ и boost::mpl для того, чтобы сделать то же самое через C++ные expression templates?
Про expression-templates я тут не говорил. а так, чтобы compile-time перемножать матрицы...
Scheme-пограммисты, наверное, тоже бывают разные. Но тому, которого учили правильно, в идеале (достижимость идеала зависит от того, насколько качественно абстракции реализованы в MPL) — быстро.
Для начала он поищет в MPL нужные вещи: map (mpl::transform), acummulate(mpl::accumulate), list (mpl::list), lambda(mpl::lambda), let — нафиг не нужен, это синтаксический сахар, accumulate-n ему возможно придется дописать
(define (accumulate-n op init seqs)
(if (null? (car seqs))
null
(cons (accumulate op init (map car seqs))
(accumulate-n op init (map cdr seqs)))))
Понять, что метафункции возвращают типы, и прочее, вроде недолго. Потом ужасный синтаксис, и все.
Среднестатистический программист императивного склада попытается понять, как все это работает, заглянет в исходники MPL (6 мегабайт красивого бустовского кода) — и застрелится
Здравствуйте, minorlogic, Вы писали:
M>Я тогда не понял , что это ваш код ...
Сер, если вы все понимаете со второго раза.... У меня же for безусловный
M>лень искать , гдет в этой ветке про return писал.
А мне, в свою очередь, тоже лень искать что вы где-то-там понаписали. В особенности, учитывая взвешенность и вудумчивость ваших понаписаний в этой ветке..
M>это заметно, но надо опять вверх лезть и смотреть инициализацию переменных цикла
Если у вас в памяти помещаются меньше чем 2(две) строчки кода, то, как вы впомните про лидирующий if в начале блока???? Или будете скроллиться как челнок от закрывающей скобки к открывающей и обратно? Или "любой блок кода длинее чем 2 строчки" тоже масдай и должен искореняться?
Если так, то не проблема — я хоть всю программу в одну строчку помещу — все поместится — благо в C/С++ точка с запятой есть — не питон, чай.
M>Чуть выше уже привели пример кода рещшающий вопрос , и выглядит на порядок красивее.
Этот пример привели не вы. Так что, и разговаривать об этом примере — не с вами.
__________
16.There is no cause so right that one cannot find a fool following it.
