Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Кто именно опасается? Ссылки уже давались. Это не полный перечень, а просто список заметных компаний, кто захотел поддержать инициативу. Например, из заметных публично, в Civilization IV используется по крайней мере Boost.Python, и их в списке нет.
Во первых, не хотел бы я смотреть список всех команд которые используют С++. Трафик не резиновый.
Во-вторых, я вполне понимаю когда люди говорят что они используют STL. Потому как они могут использовать различные части библиотеки. Boost настолько разнороден, что я немного не понимаю что значит использовать Boost. Наверняка будут использоваться только некоторые компоненты. Поэтому использование lambda на порядки меньше чем заявлений об использовании boost.(и в принципе это хорошо прослеживается по твоему списку).
В третьих, мне приходится встречаться с различными командами. Из встреченного, я не слышал чтобы использовали boost. Почему-то пишут в основном либо свои лесипеды, либо у них таких задач и не ставится. Или используют другие библиотеки, особенно это касается Spirit.
Здравствуйте, Павел Кузнецов, Вы писали:
>> Поэтому использование lambda на порядки меньше чем заявлений об использовании boost. ПК>Ты говорил о боязни использования boost вообще.
1 и 3 заметка именно об этом. Вторая — контекст предыдущего разговора.
Здравствуйте, eao197, Вы писали:
E>Никогда не поверю, что C++ можно выучить очень быстро и начать на нем грамотно программировать. Особенно с сегодняшним уклоном в шаблоны, метапрограммирование и expression templates...
На самом деле меня очень удивило замечание про "особенно шаблоны, метапрограммирование и expression templates" . С точки зрения человека, который учился функциональному программированию, шаблоны, метапрограммирование и expression templates — это как раз то, в чем он давно разобрался. Смутить его может только синтаксис. Метапрограмирование в С++ — это, например, в Scheme, просто програмирование. Сколько времени это занимает?
Возьмем к примеру пресловутый курс MIT 6.001 (первый курс). Понятие higher-order function — это шестая лекция первый семестр. Алгоритмы, применяемые к сиквенсам, — восьмая.
Ему несложно понять, что делает mpl::fold, более того, он может написать fold на Sсheme с закрытыми глазами:
(define (fold-right op initial seq)
(if (null? seq)
initial
(op (car seq)
(fold-right op initial (cdr seq)))))
Не нужно быть семи пядей во лбу, чтобы, посмотрев на:
template< typename Types, typename Unit, typename Root = mpl::none >
struct gen_linear_hierarchy
{
typedef typename mpl::fold<Types,Unit,Root>::type type; // here
};
//usage example: template< class Base, class T >
struct EventHander : public Base
{
virtual void OnEvent(T& obj, int eventID) = 0;
};
typedef gen_linear_hierarchy<
mpl::list<Window,Button,ScrollBar>
, EventHander<_1,_2>
>::type v;
понять, что gen_linear_hierarhy — это higher-order функция, которая принимает
аргументы через темплэйтные параметры. Т.е. примерный эквивалент на Scheme:
(define (gen_linear_hierarchy Types Unit Root)
(fold-right Unit Root Types))
(define (EventHandler Base T)
(list Base T))
;; usage example
(gen_linear_hierarchy (list 'Window 'Button 'ScrollBar) EventHandler '())
;; i.e (Window Button ScrollBar) -> (Window (Button (ScrollBar ())))
Т.е. мы просто преобразуем список в дерево. Абстракции тут просты и понятны. Синтаксис С++ темплэйтов ужасен.
Если начинать знакомиться с абстракциями типа filter, map, fold etc. по Александреску и Абрахамсу-Гуртовому (или даже по STL), то, для начинающего, синтаксис затмит все. Не говоря уже о том, что посмотреть на результат темплейтного метапрограмирования глазами мы можем, лишь скомпилировав файл с ключом -D, а потом еще и отформатировав вывод. Зная абстракции, пользоваться инструментами — просто.
Ну, например, вот немного линейной алгебры из домашнего задания первокурсника, который к тому времени уже целых два месяца учится программировать. Если это переписать на boost::mpl и запостить с форум по С++ — все закричат, что это извращение и среднему труженнику С++ этого ни в жисть не понять
(define (dot-product v w)
(accumulate + 0 (map * v w)))
(define (matrix-*-vector m v)
(map (lambda (x) (dot-product x v)) m))
(define (transpose m)
(accumulate-n cons null m))
(define (matrix-*-matrix m n)
(let ((cols (transpose n)))
(map (lambda (x) (matrix-*-vector cols x)) m)))
Здравствуйте, z00n, Вы писали:
Z>Т.е. мы просто преобразуем список в дерево. Абстракции тут просты и понятны. Синтаксис С++ темплэйтов ужасен. Z>Если начинать знакомиться с абстракциями типа filter, map, fold etc. по Александреску и Абрахамсу-Гуртовому (или даже по STL), то, для начинающего, синтаксис затмит все. Не говоря уже о том, что посмотреть на результат темплейтного метапрограмирования глазами мы можем, лишь скомпилировав файл с ключом -D, а потом еще и отформатировав вывод. Зная абстракции, пользоваться инструментами — просто.
Маленькое замечание. Может сложиться впечатление, что Абрахамс и Гуртовой — жрецы-злодеи, скрывающие от общественности тайну своей магии , но на самом деле они ссылаются на классиков (Paul Hudak) практически с первой страницы: http://boost.org/libs/mpl/doc/tutorial/higher-order.html
Я, собственно, так и заразился ФП, после туториала MPL.
А синтаксис, понятное дело, читаем слабо, т.к. не предназначен для метапрограммирования.
Здравствуйте, Глеб Алексеев, Вы писали:
ГА>Маленькое замечание. Может сложиться впечатление, что Абрахамс и Гуртовой — жрецы-злодеи, скрывающие от общественности тайну своей магии , но на самом деле они ссылаются на классиков (Paul Hudak) практически с первой страницы: ГА>http://boost.org/libs/mpl/doc/tutorial/higher-order.html
Я ничего такого не имел в виду.
ГА>Я, собственно, так и заразился ФП, после туториала MPL.
А я пошел читать SICP после 6-ой главы их книги (Algorithms)
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Игoрь, Вы писали:
И>>Здравствуйте, minorlogic, Вы писали:
M>>>Так вот в том то и дело что метку можно назвать хорошо а МОЖНО ПЛОХО , а return не допускает вольной интерпретации, логика его работы прозрачна. И>>Ну и что из этого следует? Я же выше сказал, что и функцию МОЖНО ПЛОХО назвать, но главное что можно и хорошо. И>>По-моему тема с goto высосона из пальца. Просто не стоит ими злоупотреблять вот и все. А прогу запутать легко и без явных меток, что многие успешно делают.
M>Собственно тут логически течет такое рассуждение. Если переходы "goto" настолько же удобны как и return к примеру , тогда зачем загромождать язык такими конструкциями как
M>for M>if M>case M>while M>и т.д.
M>А зачем ? ведь все можно построить на goto.
И что ты мне пытаешься доказать? Я разве где-то говорил о том, что я против структурного программирования? Я говорил только о том, что возможны ситуации, когда применение явного goto оправдано. Вообще тема настолько заезжена, что у меня нет особого желания спорить. Если ты считаешь, что метки — это абсолютное зло, то я не смогу тебя переубедить. У Кнута есть статья на эту тему Structured Programming with go to Statements.
Здравствуйте, dshe, Вы писали:
D>Здравствуйте, Игoрь, Вы писали:
И>>Здравствуйте, minorlogic, Вы писали:
M>>>Так вот в том то и дело что метку можно назвать хорошо а МОЖНО ПЛОХО , а return не допускает вольной интерпретации, логика его работы прозрачна. И>>Ну и что из этого следует? Я же выше сказал, что и функцию МОЖНО ПЛОХО назвать, но главное что можно и хорошо.
D>Метки для goto гораздо сложнее назвать хорошо. Наиболее часто используемые имена выглядят так: end_if, end_loop, exit, start_loop, else_branch. А с учетом того, что метки в определенной области видимости должны быть уникальны, приходится извращаться с добавлением суффиксов.
Большое кол-во меток наводит на мысль, что что-то в коде не так... больше двух меток мне точно не приходилось никогда использовать
D> Это также создает проблемы при переносе какого-то участка кода в другое место: часто приходится переименовывать метки, из-за чего могут вноситься ошибки.
Никто не говорит, что метки нужно использовать повсеместно. Если возникают такие проблемы, то видимо кто-то очень хорошо злоупотребил.
D>во-втором goto exit1; может действительно подразумевался выход из двух вложенных циклов, а может кто-то просто забыл (при переносе кода) exit1 заменить на exit2.
Там максиму нужна была одна метка, но я бы этот пример писал без меток
Кстати, по поводу именования меток... на одной из предыдущих работ у нас один товарищ под впечатлением от гоблиновского перевода "Властелина колец" выдал:
if (...)
if (...)
if (...)
goto mochi_kozlov;
...
...
mochi_kozlov:
// cleanup
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> Если вы считаете, что человек, знающий Common Lisp, Smalltalk и ML >> найдет для себя что-то новое и неизвестное в C++, то мне придется вас >> разочаровать. Не найдет.
C>Плохо ищет значит.
Нет, кто-то плохо показывает.
>> Самая новая и оригинальная идея в С++ имеет не менее чем >> двадцатилетнюю историю в других языках.
C>1) State-of-art система ручного управления памятью. Назовите мне C>язык, где управлять распределением/уничтожением памяти можно так же C>гибко и удобно как в С++.
Но хочется понять долго ли мемори менеджмент в С++ доходил до state-of-the-art, чтобы достигнуть достигать такого — язык, к которому даже GC нормальный не прицепишь. А то мне кажется, идея такого мемори менеджмента мягко говоря не нова.
C>2) Взаимодействие с кодом на С. Где у нас еще есть extern "C"?
Хм.
С/Objective-C/D/Cyclone ?
А вообще конечно это одна из самых важных и уникальных идей и языка С++, да..
Скажите, а
foreign export ccall в Хаскеле написать уже нет?
или там external в O'Caml
C>3) Реально используется в промышленности.
Очень новая языковая идея.
>> E>Я и сам "13 Years of C++ and still learning" >> Я вас правильно понимаю, что вы не знаете ни одного из вышеназванных >> языков?
C>Я писал на OCaml'е и немного на Haskell'е, например. Неплохо, но далеко C>не самая лучшая вещь с начала времен.
А расскажите какая лучшая?
Кстати еще интересно чем вам так мемори менеджмент в окамле и хаскеле не угодил. Правда.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, шапокляк, Вы писали:
Ш>>Я тут конешно новенькая и меня легко затоптать. Но сложите 2 и 2. Лауреаты премии Тьюринга люди не святые. Но коли с ними переходят на личности то уж никак не от большова ума. И што тут спорить? Ну а научный уровень Линуса Торвальдса можно даже не обсуждать. Хотя я не удивлюсь если его протолкнут в лауреаты Тьюринга. Такова жизнь. GZ>Честно говоря, я бы дал премию Страуступу. Можно долго мучится вопросом насчет недостатков и достоинств языка и научной ценности, но то что его детище кардинально повлиял на все сообщество на десятилетия — отрицать нельзя. Это влияние нельзя переоценить.
GZ>С уважением, Gleb.
Дадут дадут не сумлевайтесь. Вот нашла о нем на одном програмерском форуме:
Он-таки сейчас профессор в университете Texas A&M University плюс состоит в лаборатории Information and Systems Software Research Lab, что работает внутри AT&T Labs. Да еще в этом году получил приз за научные достижения -- William Procter Prize for Scientific Achievement.
А сейчас до сих пор в своих языках занимается (в C>основном) идеологией без нововведений. За это Вирта и не любят тут
Как я успела заметить Вирта тут не любят за другое — он и его слова вносят ненужный диссонанс (во какое словечко вспомнила) во всеобщее благоденствие на рынке С-шных языков.
>> Если вы считаете, что человек, знающий Common Lisp, Smalltalk и ML найдет для себя что-то новое и неизвестное в C++, то мне придется вас разочаровать. Не найдет.
ПК>Вероятно, Вам будет удобнее увидеть это новое, глядя не на спецификацию самого языка, а на формальное описание некоторой части его семантики. Вот попытка составления такого формализма; кстати, там явно прописаны отличия от Хаскеля.
О, спасибо.
Странный документ. Хаскель там для сравнения системы типов приведен. Причем в каждом случае описываются отличия системы типов С++ от Хаскеля. Они там и предупреждают в начале, что на этом и будут строить формализм.
Видимо, это был самый простой способ. Но для реального сравнения этих двух языков, этот подход малосодержателен, нужно сказать.
Потому что даже как только система типов, Хаскель там присутствует лишь небольшой частью (фактически только typeclasses).
Вообще же, несмотря на то, что в реальной жизни можно даже найти параллели между С++ и Haskell, реальная их семантика различается настолько, что на полном серьезе ее сравнивать, это очень смело
Я кстати конкретно с Haskell C++ и не сравнивал.
Вообще это популярные в последнее время экзерсисы — какой-нибудь формализм понеожиданнее придумать. Вот исчисление для явовских классов: http://homepages.inf.ed.ac.uk/wadler/papers/featherweight/featherweight.ps
позволяет решать систему типов.
Очень смешное кстати.
ПК>Есть и ряд отличий, существенных с практической точки зрения. Часть из них упоминал eao197, но, к сожалению, Вашего мнения по этому поводу каждого из отличий увидеть не удалось; поэтому я пока, пожалуй, воздержусь от их перечисления.
А что-то кстати не соображу быстро о чем речь, где это?
reductor,
> C>1) State-of-art система ручного управления памятью. Назовите мне > C>язык, где управлять распределением/уничтожением памяти можно так же > C>гибко и удобно как в С++.
> Уфф. Меня аж чуть просветление не хватило. То есть это не баг, а _фича_ Си++ такое управление памятью?
Пожалуй, правильнее говорить об управлении временем жизни объектов, с чем C++, действительно, справляется лучше ряда других языков благодаря детерминированному разрушению объектов. GC этой задачи не решает.
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
AVC wrote: > > Само собой. > По сравнению с самым влиятельным языком современности (ML, разумеется) > мало что имеет значение...
Вы недооцениваете влияние ML, например, на Вашу повседневную жизнь (если
Вы, конечно, программер)
> Ну, я догадывался, что Милнер — автор одного из функциональных языков, о > которых Вы так восторженно говорите. > Только не знал — какого именно. > И на кого же он так повлиял (кроме других ученых, разумеется)? > А то его безмерное могущество не везде так сильно ощущается.
Ну вот, например, темплейты в C++ — пародия на ML (или, скорее, на
Haskell, т.к. они ленивые).
eao197 wrote: > > C>А с операционными системами у > C>Торвальдса явно лучше результат. > > Интересно, где бы был Торвальдс со своим ядром, если бы он делал > собственную ОС, а не очередной клон Unix-а?
Кому нужна очередная новая операционная система, если она не клон
UNIX'а. Или, на худой конец, VMS'а?
Cyberax wrote: > > Надо сказать, что ядро к окружению отношение не очень большое имеет (а > Unix — это прежде всего окружение). То есть на Linux'е можно запустить и > встроеное устройство вообще без файловой системы. Кроме того, критикам > Линуса стоит напомнить, что есть куча *BSD-систем, которые так и не > набрали популярность (в отличие от Линукса).
Вообще без файловой системы, это вряд ли. Без файловой системы на
"твердом носителе", это возможно.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>reductor,
>> C>1) State-of-art система ручного управления памятью. Назовите мне >> C>язык, где управлять распределением/уничтожением памяти можно так же >> C>гибко и удобно как в С++.
>> Уфф. Меня аж чуть просветление не хватило. То есть это не баг, а _фича_ Си++ такое управление памятью?
ПК>Пожалуй, правильнее говорить об управлении временем жизни объектов, с чем C++, действительно, справляется лучше ряда других языков благодаря детерминированному разрушению объектов. GC этой задачи не решает.
Я все же не понимаю кое-чего. Для каких задач нужно такое управление?
Но даже если так, почему С++ здесь справляется лучше тех языков, у которых нет проблем с алиасингом?
Окамла, у которого очень прогрессивный копирующий GC при котором куча всегда утрамбована и который еще и полностью управляемый?
Или чем С++ здесь лучше Cyclone c его регионами и прочим?
Privalov wrote: > > Добавлю, что, возможно, именно Паскаль помог уйти от разработки монстров > типа PL/1. Иначе, был бы сейчас какой-нибудь PL/3, объединяющий все > самое худшее из всех течений в программировании.
А разве C++ в сочетании с Win32 API к этому не стремится?...
GlebZ wrote: > Честно говоря, я бы дал премию Страуступу. Можно долго мучится вопросом > насчет недостатков и достоинств языка и научной ценности, но то что его > детище кардинально повлиял на все сообщество на десятилетия — отрицать > нельзя. Это влияние нельзя переоценить.
Тогда уж еще и Биллу Гейтсу — влияние его империи еще сильнее.
Здравствуйте, Pzz, Вы писали:
Pzz>Вы недооцениваете влияние ML, например, на Вашу повседневную жизнь (если Pzz>Вы, конечно, программер)
Разве что на будущую?
Pzz>Ну вот, например, темплейты в C++ — пародия на ML (или, скорее, на Pzz>Haskell, т.к. они ленивые).
ИМХО, этой пародией детей пугать можно...
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Я говорил только о том, что возможны ситуации, когда применение явного goto оправдано. Вообще тема настолько заезжена, что у меня нет особого желания спорить. Если ты считаешь, что метки — это абсолютное зло, то я не смогу тебя переубедить. У Кнута есть статья на эту тему Structured Programming with go to Statements.
