Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 88
Выглядит симпатично. Особенно понравилась идея с возможностью ручного удаления обьектов при присутствующем гц.
Языки разные же создаются. D - это для любителей C. Карма у него такая, поэтому и точки с запятыми у него такие. Для любителей других языков есть другие языки. Идеального и правильного для всех языка не существует. Мир же разнообразный. Вот.
Можно поставить вопрос иначе: почему люди, которым больше нравится писать in, не ставить ';', не пользоваться всякими закорючечками в формулах и писать WriteFormattedLine, полагаясь на IntelliSense менее активны в создании и продвижении новых языков?
Где-то в ответе на этот вопрос скрата истина. Впрочем, Ruby же существует и набирает обороты.
Можно поставить вопрос иначе: почему люди, которым больше нравится писать in, не ставить ';', не пользоваться всякими закорючечками в формулах и писать WriteFormattedLine, полагаясь на IntelliSense менее активны в создании и продвижении новых языков?
Где-то в ответе на этот вопрос скрата истина. Впрочем, Ruby же существует и набирает обороты.
По вашему языки изобретают только "для понта"? Типа, мы обошли Java, мы круты, а если обойти не светит, то и изобретать не будем?
Языки изобретаются, для более удобного решения проблем возникающих в каждой конкретной области.
Не буду говорить за всех, но лично я научился совершенно спокойно относится к любому синтаксису. И к C и к Pascal и к Python.
Языки изобретаются, для более удобного решения проблем возникающих в каждой конкретной области.
Не буду говорить за всех, но лично я научился совершенно спокойно относится к любому синтаксису. И к C и к Pascal и к Python.
Опять хабра глючит...
[а не из-за того ли люди, которым не нравится "писать in...", изобретают и продвигают новые языки]
Нет. Они их изобретают из-за того, что им надоедает вручную выделять/уничтожать память, насиловать себе мозг с указателями и не иметь нормальных динамических строк.
[а не из-за того ли люди, которым не нравится "писать in...", изобретают и продвигают новые языки]
Нет. Они их изобретают из-за того, что им надоедает вручную выделять/уничтожать память, насиловать себе мозг с указателями и не иметь нормальных динамических строк.
Извините, если вам что-то показалось грубым.
Имхо, синтаксис и принятый стиль именования, разные вещи. Как вы сами указали многие языки с си-подобным синтаксисом используют более красивое именование и синтаксис им в этом не мешает.
Имхо, синтаксис и принятый стиль именования, разные вещи. Как вы сами указали многие языки с си-подобным синтаксисом используют более красивое именование и синтаксис им в этом не мешает.
Извините, если вам что-то показалось грубым.
Имхо, синтаксис и принятая система именования разные вещи. Вы сами указали несколько языков с си-подобным синтаксисом в которых используется более красивое именования и синтаксис им в этом не мешает.
Имхо, синтаксис и принятая система именования разные вещи. Вы сами указали несколько языков с си-подобным синтаксисом в которых используется более красивое именования и синтаксис им в этом не мешает.
Синтаксис - дело привычки.
Я довольно много лет программирую и на Си, Си++, Перл и других языках. И могу точно сказать, что синтаксис помнят пальцы, а не голова. Голова занята семантикой :-). Но конечно при первом знакомстве человекопонятный синтаксис это хорошо. Может поэтому раньше в универах любили давать Паскаль, а потом уже Си (да и сейчас любят вроде).
Что касается математики, то же самое. После нескольких лет мат.анализа, аналитической геометрии, мат. моделирования и т.п. Все эти казалось бы непонятные с первого взгляда закорючки становятся роднее русского языка.
Опять же все новое давно забытое старое. Посмотрите язык COBOL (59 год первая версия). При создании языка авторы задались целью максимально приблизить к английскому языку. За что в отгребли немало критики, но очень много программ (особенно для всяких экономических целей) написаны на КОБОЛ и до сих пор где-то используются.
Я довольно много лет программирую и на Си, Си++, Перл и других языках. И могу точно сказать, что синтаксис помнят пальцы, а не голова. Голова занята семантикой :-). Но конечно при первом знакомстве человекопонятный синтаксис это хорошо. Может поэтому раньше в универах любили давать Паскаль, а потом уже Си (да и сейчас любят вроде).
Что касается математики, то же самое. После нескольких лет мат.анализа, аналитической геометрии, мат. моделирования и т.п. Все эти казалось бы непонятные с первого взгляда закорючки становятся роднее русского языка.
Опять же все новое давно забытое старое. Посмотрите язык COBOL (59 год первая версия). При создании языка авторы задались целью максимально приблизить к английскому языку. За что в отгребли немало критики, но очень много программ (особенно для всяких экономических целей) написаны на КОБОЛ и до сих пор где-то используются.
Синтаксис - дело привычки.
После нескольких лет программирования на Си, Си++, Перл могу сказать, что синтаксис языка помнят пальцы, голова занята скорее семантикой.
Что касается математики, абсолютно аналогично. После нескольких лет изучения мат.анализа, алалитической геометрии или мат. моделирования все мат. обозначения становятся роднее русского языка.
Опять же хочу заметить, что все новое давно забытое старое.
Посмотрите на язык COBOL. Создатели хотели максимально приблизить его к англ. языку. За что в свое время отгребли не мало критики, но в тоже время кода на этом языке написано не меряно. И он до сих пор работает кое-где.
По моему гораздо неприятнее, что-то противоположное привычному.
Например в Fox Pro начало нового оператора это - перевод строки.
А ; наоборот символ продолжения.
После нескольких лет программирования на Си, Си++, Перл могу сказать, что синтаксис языка помнят пальцы, голова занята скорее семантикой.
Что касается математики, абсолютно аналогично. После нескольких лет изучения мат.анализа, алалитической геометрии или мат. моделирования все мат. обозначения становятся роднее русского языка.
Опять же хочу заметить, что все новое давно забытое старое.
Посмотрите на язык COBOL. Создатели хотели максимально приблизить его к англ. языку. За что в свое время отгребли не мало критики, но в тоже время кода на этом языке написано не меряно. И он до сих пор работает кое-где.
По моему гораздо неприятнее, что-то противоположное привычному.
Например в Fox Pro начало нового оператора это - перевод строки.
А ; наоборот символ продолжения.
Упс, 2 раза почти одно и тоже запостил, Хабр глючит. Зато прекрасный случай посмотреть, как меняется изложение одних и тех же мыслей.
Первый коментарий не запостился (как мне показалось, потому как вывелась ошибка). И потому я заново написал второй. :-D
Первый коментарий не запостился (как мне показалось, потому как вывелась ошибка). И потому я заново написал второй. :-D
Упс. 2 раза почти одно и тоже запостил. глючит Хабр. Первый коментарий я думал не запостился и написал втрой почти такой же.
Отличный синтаксис.
Уж как минимум поэтому и хороший. Кроме того, если по сути ваших аргументов размышлять, то я бы сказал, что C-шный синтаксис - это как раз удачный компромисс между компактностью для машины и наглядностью для человека.
Java - это крайность в сторону наглядности (причем только для ЧИТАЮЩЕГО - ибо для пишущего она оборачивается нелепым нагромождением наследований при простейших операциях и никакое IDE этого не решает)
Perl - крайность в сторону компактности и гибкости конструкций (прочитать _это_, как известно, вообще иногда нереально)
Если и есть синтаксис лучше, то это модификация сишного - как вы правильно заметили, для базовых конструкции можно придумать и более читабельные лексемы. Хороший пример тому - PHP.
имхо.
Понятно дело, он многим знаком, но кто сказал, что он хороший?
Уж как минимум поэтому и хороший. Кроме того, если по сути ваших аргументов размышлять, то я бы сказал, что C-шный синтаксис - это как раз удачный компромисс между компактностью для машины и наглядностью для человека.
Java - это крайность в сторону наглядности (причем только для ЧИТАЮЩЕГО - ибо для пишущего она оборачивается нелепым нагромождением наследований при простейших операциях и никакое IDE этого не решает)
Perl - крайность в сторону компактности и гибкости конструкций (прочитать _это_, как известно, вообще иногда нереально)
Если и есть синтаксис лучше, то это модификация сишного - как вы правильно заметили, для базовых конструкции можно придумать и более читабельные лексемы. Хороший пример тому - PHP.
имхо.
Гм, а разве C# не взял многое от того же C и C++? По поводу синтаксиса можно поспорить, лично мне все эти out кажутся лишними. Полные слова - тоже дело вкуса. Предложите математикам вместо формул писать полные выражения (вроде "сложить все элементы от 0 до n в выражении..."), мне кажется они не оценят.
"но при этом остаётся полностью компилируемым в машинный код и хорошо оптимизируемым языком."
Вот тут я бы поспорил. C/С++ в отличие например от Java - достаточно плохо оптимизируемый язык. Так что от вливания Java и GC он мог разве только выиграть по части оптимизации.
Вот тут я бы поспорил. C/С++ в отличие например от Java - достаточно плохо оптимизируемый язык. Так что от вливания Java и GC он мог разве только выиграть по части оптимизации.
Ну что же, давайте спорить. Какую траву вы курили, чтобы у вас начались галлюцинации ?
Да, конечно, если взять последнюю, хорошо вылизанную версию Java и посредственный компилятор C++ (скажем от Microsoft), да ещё и подобрать задачу (скажем простой тест), то Java выиграет. И с подобными тестами любят носиться (как с писаной торбой) фанаты Java. Однако суровая действительность показывает иное: на суперкомпьютерах (где производительность - самое важное требование, как несложно догадаться) часто используется C++ и Fortran, но почти никогда - Java.
Почему ? Во-первых, конечно, потому что существуют готовые библиотеки для разного вида рассчётов (скажем ATLAS - Automatically Tuned Linear Algebra Software). Но их можно было бы переписать, если бы не было во-вторых: ЛЮБОЙ процессор обладает ограниченными ресурсами - например крайне малым кешом первого уровня (скажем в Core 2 это 32KB и 128 строк TLB), чего может быть достаточно для тестов, но на реальных задачах это - серъёзное ограничение для Java и менее серъёзное - для C++!
Как так, при чём тут кеш и TLB ? Всё просто: если мы сравниваем программу на Java и программу на C++ скомпилированную с использованием профиля (Profile-Based Optimization) и межфайловой оптимизации (Whole Program Optimization), то всё, что Java может противопоставить C++ - это перекомпиляцию программы "на лету" под разные сценарии (скажем сначала java.lang.String.length используется для коротких строк, потом для длинных, потом снова для коротких и т.д.), что случается достаточно редко - а ресурсы JIT тратит всегда. Вспомним ещё и про то что в Java гораздо сложнее избежать использования объектов расположенных в куче - а это значит что в реальном мире мы вынуждены-таки использовать GC (в тестах часто всё бывает шоколадно ибо используется серверная Java, которая создаёт мегабайты строк в тесте и не удаляет их, так как она откладывает эту деятельность до того момента, когда объектов будет несколько мегабайт). И, опять-таки, GC транжирит ресурсы процессора (причём чем он совершеннее тем он меньше сочетается с несчастыми 32KB L1).
Если вы можете привести пример БОЛЬШОГО продукта, который при переходе на Java стал быстрее, чем был на C++ - приводите, обсудим. Я не говорю что так НЕ БЫВАЕТ. Я просто говорю, что бегун с двумя гирями на верёвке, но зато с облегчёнными кроссовками и ракетным ускорителем в попе (т.е. Java) может обогнать нормального бегуна на хорошо подобранной короткой дистанции или на хитрой, специально для него построенной трассе, но почти никогда - на реальных дорогах...
P.S. При попытке добавить ссылок Хабр убивает всё сообщение к бесу, так что Google вам в помощь. Когда же это кончится ?
Да, конечно, если взять последнюю, хорошо вылизанную версию Java и посредственный компилятор C++ (скажем от Microsoft), да ещё и подобрать задачу (скажем простой тест), то Java выиграет. И с подобными тестами любят носиться (как с писаной торбой) фанаты Java. Однако суровая действительность показывает иное: на суперкомпьютерах (где производительность - самое важное требование, как несложно догадаться) часто используется C++ и Fortran, но почти никогда - Java.
Почему ? Во-первых, конечно, потому что существуют готовые библиотеки для разного вида рассчётов (скажем ATLAS - Automatically Tuned Linear Algebra Software). Но их можно было бы переписать, если бы не было во-вторых: ЛЮБОЙ процессор обладает ограниченными ресурсами - например крайне малым кешом первого уровня (скажем в Core 2 это 32KB и 128 строк TLB), чего может быть достаточно для тестов, но на реальных задачах это - серъёзное ограничение для Java и менее серъёзное - для C++!
Как так, при чём тут кеш и TLB ? Всё просто: если мы сравниваем программу на Java и программу на C++ скомпилированную с использованием профиля (Profile-Based Optimization) и межфайловой оптимизации (Whole Program Optimization), то всё, что Java может противопоставить C++ - это перекомпиляцию программы "на лету" под разные сценарии (скажем сначала java.lang.String.length используется для коротких строк, потом для длинных, потом снова для коротких и т.д.), что случается достаточно редко - а ресурсы JIT тратит всегда. Вспомним ещё и про то что в Java гораздо сложнее избежать использования объектов расположенных в куче - а это значит что в реальном мире мы вынуждены-таки использовать GC (в тестах часто всё бывает шоколадно ибо используется серверная Java, которая создаёт мегабайты строк в тесте и не удаляет их, так как она откладывает эту деятельность до того момента, когда объектов будет несколько мегабайт). И, опять-таки, GC транжирит ресурсы процессора (причём чем он совершеннее тем он меньше сочетается с несчастыми 32KB L1).
Если вы можете привести пример БОЛЬШОГО продукта, который при переходе на Java стал быстрее, чем был на C++ - приводите, обсудим. Я не говорю что так НЕ БЫВАЕТ. Я просто говорю, что бегун с двумя гирями на верёвке, но зато с облегчёнными кроссовками и ракетным ускорителем в попе (т.е. Java) может обогнать нормального бегуна на хорошо подобранной короткой дистанции или на хитрой, специально для него построенной трассе, но почти никогда - на реальных дорогах...
P.S. При попытке добавить ссылок Хабр убивает всё сообщение к бесу, так что Google вам в помощь. Когда же это кончится ?
Я наверное не очень хорошо выразился. Если мы имеем к оптимизации типовой базовый блок функции на С и базовый блок фунцкии на Java, то в силу того, что структура classfile-а накладывает на контекст в котором происходит выполнение для Java больше ограничений, то Java базовый блок можно точнее оптимизировать.
Я вот думаю, что если написать на C програму семантически эквивалентную програме на Java, то тут еще далеко не ясно, кто победит (особеено учитывая временные затраты на написание такого кода на C). Конечно, если перенести проект с C/С++ на Java, он станет, как правило, работать значительно медлнее, но преобретет массу новых свойств.. вот например в нем стек не сорвать будет и ОС без контроля памяти он не убьет вместе с собой никогда.
Я вот думаю, что если написать на C програму семантически эквивалентную програме на Java, то тут еще далеко не ясно, кто победит (особеено учитывая временные затраты на написание такого кода на C). Конечно, если перенести проект с C/С++ на Java, он станет, как правило, работать значительно медлнее, но преобретет массу новых свойств.. вот например в нем стек не сорвать будет и ОС без контроля памяти он не убьет вместе с собой никогда.
http://shootout.alioth.debian.org/ - семантически эквивалентные программы на разных языках программирования.
А то, что писать на СИ сложнее - это миф, imho. По крайней мере, по объёму кода программы на СИ меньше, а если учесть, что синтаксически Java и СИ похожи, то...
http://shootout.alioth.debian.org/sandbo…
А то, что писать на СИ сложнее - это миф, imho. По крайней мере, по объёму кода программы на СИ меньше, а если учесть, что синтаксически Java и СИ похожи, то...
http://shootout.alioth.debian.org/sandbo…
Глянь CPU и Mem в CLB при сравнении JAVA и D (не говоря уже про C), станет понятно, почему JAVA так хорошо оптимизируется.
Да эта среда Windows через 2 года умрет уже, нафиг на ней популярность искать.
Расслабься, я всего-лишь пытался сказать dropp, что не все в этом мире зависит от Microsoft и языку не нужно благословение Баллмера, чтоб стать популярным и используемым. А если везде мерещатся холивары, надо валерьянку пить.
Windows - это плохо. Потому что она с самого начала была ориентирована на изоляцию от других операционок. POSIX, которым невозможно пользоваться, свои собственные, ни с чем не совместимые, "улучшения" на всех уровнях и т.д. и т.п.
Но что касается "смерти Windows", то это произойдёт через 5-7 лет после того, как Windows пересечёт границу 50%, до чего ещё очень и очень далеко, так что я не понимаю откуда все эти шапкозакидательские настроения берутся. Было бы ОЧЕНЬ ХОРОШО если бы Windows через пару лет загнулась - но этого не случится, даже и не надейтесь...
P.S. Впрочем MacOS - тот ещё зверь с этой точки зрения. Свой собственный, ни с чем не совместимый язык, своя графическая подсистема и т.д. и т.п. Главное "преимущество" - тесная связь между железом и операционкой, которое обозначает что монополией MacOS не станет никогда: Dell, HP и Lenovo не дадут :-)
Но что касается "смерти Windows", то это произойдёт через 5-7 лет после того, как Windows пересечёт границу 50%, до чего ещё очень и очень далеко, так что я не понимаю откуда все эти шапкозакидательские настроения берутся. Было бы ОЧЕНЬ ХОРОШО если бы Windows через пару лет загнулась - но этого не случится, даже и не надейтесь...
P.S. Впрочем MacOS - тот ещё зверь с этой точки зрения. Свой собственный, ни с чем не совместимый язык, своя графическая подсистема и т.д. и т.п. Главное "преимущество" - тесная связь между железом и операционкой, которое обозначает что монополией MacOS не станет никогда: Dell, HP и Lenovo не дадут :-)
тире лишнее :)
а можно поподробнее про свой собственный язык у макоси? или вы имеете в виду AppleScript? ну это не минус а плюс, точнее дополнение. на маке вам никто не мешает использовать тотже bash & cron и т.д. и т.п.
ЗЫ: кстати в макоси прекрасно работают _любые_ графические приложения под Х - в коробке есть Х сервер
ЗЫЫ: очень прошу не говорить о том где вы не осведомлены
ЗЫ: кстати в макоси прекрасно работают _любые_ графические приложения под Х - в коробке есть Х сервер
ЗЫЫ: очень прошу не говорить о том где вы не осведомлены
Скорее всего имеется ввиду ObjectiveC
Если вы даже не знаете про то, что у MacOS свой язык (ObjectiveC, а в последнее время ObjectiveC++) и своя графическая подсистема (Display PostScript), то вы с ней не работали как программист (мы в блоге Ревизия кода, не забыли?) и следовало бы последовать своему собственному совету: "не говорить о том где вы не осведомлены". X сервер из коробки - это хорошо, но он просто создаёт внутри одной операционки три царства (вместо двух): консольные программы, нативные программы и ещё X'овые программы. Мешанина изрядная и если вы начинаете использовать X'овые программы вы немедленно теряете основное достоинство MacOS (унификацию интерфейсов).
И что?
Ужас, развели войну :) Вообще D хоть и симпатичен но львинная доля его фич обещают в следующим стандарте C++, а на текущем моменте стандартная библиотека C++ (включая STL) гораздо шире + boost который вносит в библиотеку ещё туеву кучу интересного и полезного.
D мёртворождён.
А за новость спасибо.
D мёртворождён.
А за новость спасибо.
Согласен, сам хотел высказать эту же мысль
Вот здесь обзор нововведений --> ;
Вот здесь обзор нововведений --> ;
Вау. На C++ и так было 'весело' программировать, станет ещё 'веселее'. Особенно позабавило шаманство с rvalue ссылками. Они что, правда собираются придумать 'невидимые полотна' (в терминологии Спольского).
Не показывайте эту ссылку менеджерам, а то, ведь, неразумные, заставят и эти 'фичи' использовать.
Не показывайте эту ссылку менеджерам, а то, ведь, неразумные, заставят и эти 'фичи' использовать.
Что за "невидимые полотна"?
Ну. Это я про
Любая именованная rvalue-ссылка трактуется как lvalue. Любая неименованная rvalue-ссылка трактуется как rvalue.'
Как-то это запутано. То есть, как операторы перегружать понятно, но, точно так же, как и с обработкой исключений никакой определённости не будет в том, как именно работает код. Правила неявные. Там в примере описан перегруженный оператор + для строк, а как он будет применяться для создания первого rvalue? При выполнении первого сложения? Опять хитрая и сложно контроллируемая программистом схема преобразования типов и неявный поиск нужного +=? Эх... И снова 1k страничное руководство о том, как правильно этим пользоваться.
Любая именованная rvalue-ссылка трактуется как lvalue. Любая неименованная rvalue-ссылка трактуется как rvalue.'
Как-то это запутано. То есть, как операторы перегружать понятно, но, точно так же, как и с обработкой исключений никакой определённости не будет в том, как именно работает код. Правила неявные. Там в примере описан перегруженный оператор + для строк, а как он будет применяться для создания первого rvalue? При выполнении первого сложения? Опять хитрая и сложно контроллируемая программистом схема преобразования типов и неявный поиск нужного +=? Эх... И снова 1k страничное руководство о том, как правильно этим пользоваться.
а как он будет применяться для создания первого rvalue? При выполнении первого сложения?
Нет, первая rvalue ссылка создается вызовом конструктора. Получаем неименованый обьект, т.е. rvalue. Нет тут ничего сложного. А поиск перегруженного оператора - просто сначала ищем оперетор, который принимает rvalue в качестве аргумента, если не нашли - ищем дальше по обычным правилам.
Хм... А вообще мне C++ напоминает по своей структуре Windows. Куча, куча, куча, куча каких-то механизмов, из которых в нормальных проектах используется процентов 10. А остальное - это попытки показать всем 'кузькину мать'. Мол, а мы тоже так можем, хоть и коряво.
Все эти стандарты C++ - интеллектуальное соревнование для стандартизаторов. Вот как это выглядит, imho.
Все эти стандарты C++ - интеллектуальное соревнование для стандартизаторов. Вот как это выглядит, imho.
Приведи пример хоть одного "такого" механизма. И заодно скажи как долго и насколько серьезно ты программируешь на С++.
Какого? Который используется? Или который не используется? Не используется - множественное наследование, например. Ну, кто-то наверняка использует, но основное применение - это интерфейсы, что явно гораздо скромнее, чем первоначальный размах задуманного.
Или вот указатели на элементы классов. Тоже редкий гость в строчках программ. Шаблоны. Да, stl и boost их навязывают, но какой зубодробительный шаблон, вроде auto_ptr Вы самостоятельно написали за последние несколько лет?
А жить, вобщем-то можно и без stl. Чем, к счастью я и занимаюсь. У меня сейчас есть возможность НЕ программировать на СИ++. А до того, как она появилась, программировал года три, наверное. И возвращаться в этот синтаксический и семантический кошмар не тянет. Если мне понадобится lambda, я уж лучше Haskell попользую.
Или вот указатели на элементы классов. Тоже редкий гость в строчках программ. Шаблоны. Да, stl и boost их навязывают, но какой зубодробительный шаблон, вроде auto_ptr Вы самостоятельно написали за последние несколько лет?
А жить, вобщем-то можно и без stl. Чем, к счастью я и занимаюсь. У меня сейчас есть возможность НЕ программировать на СИ++. А до того, как она появилась, программировал года три, наверное. И возвращаться в этот синтаксический и семантический кошмар не тянет. Если мне понадобится lambda, я уж лучше Haskell попользую.
Не используется - множественное наследование, например. Ну, кто-то наверняка использует, но основное применение - это интерфейсы, что явно гораздо скромнее, чем первоначальный размах задуманного.Тут согласен. Они бы уже навреное и рады были убрать его, но совместимость....
Или вот указатели на элементы классов.
Вот тут не согласен. Самое полезное применеие - обобщенные функторы.
А жить, вобщем-то можно и без stl.Ну это уже вопрос религии. Благо, С++ не ограничивает нас в выборе, в отличие от той же Джавы
Эмс. Не получилось связать обобщённые функторы с указателями на элементы классов. Какая взаимосвязь? Поясните, если не сложно.
Клиентский код вызывает обобщенный функтор, а тот неявно переадресовывает его функции члену, через указатель. Или я неправильно вас понял?
Уточнение: функции-члену _любого_ класса.
std::mem_fun через это работает. Посмотрите как это используется. А используется это широко.
Вы это мне говорите? :)
А колме mem_fun это ещё где используется?
Да, mem_fun - это одна из разновидностей обобщенных функторов. Другая инкапсулирует и указательна обьект, и указатель на функцию - т.е. для вызова ей нужно только [пустой] список аргументов. Используется для реализации паттернов "command", "chain of responsibility", "broadcaster-subscriber" и многих других. Применение очень широкое.
Правильно. Я вспомнил этот пример, и счастливое время, проведённое за изучением ассемблерного кода, который из него получается. Но вопрос остаётся, который описан в моём посте ниже, который вы уже откоменнтировали. А зачем это всё? Почему простых указателей на функции не хватает для решения тех задач, для которых придуман этот семантически сложный способ? Неужели действительно проще каждый раз писать
mem_fun_t (&cls::f) af;
чем использовать нормальные замыкания? А в данном случае и этого не нужно, потому что тут нет привязки к динамическим объектам. Можно через функцию всё сделать. Но только зачем? Если уже и так есть готовая функция?
Нет, в рамках C++ всё понятно. Но если сравнивать с разрешением подобных ситуаций в других языках программирования, то... Ну, мягко говоря, существуют методы и получше.
mem_fun_t (&cls::f) af;
чем использовать нормальные замыкания? А в данном случае и этого не нужно, потому что тут нет привязки к динамическим объектам. Можно через функцию всё сделать. Но только зачем? Если уже и так есть готовая функция?
Нет, в рамках C++ всё понятно. Но если сравнивать с разрешением подобных ситуаций в других языках программирования, то... Ну, мягко говоря, существуют методы и получше.
А зачем изучать ассемблерный код???
Простых указателей на ф-ции не хватает по одной простой прчине, потому что функция не простая, член класса. И если вы изучали ассемблерный код, то наверное заметили, что указатель на функцию-член. И вызывается она немного по другому - компилятор должен запихнуть в стек указатель this, отсюда и "семантическая сложность", в которой я не виджу ничего сложного.
Вы все таки не поняли для чего существуют функторы. Вот вам пример
class A
{
public:
void f () {}
};
void f (A* a)
{
a->f ();
}
void main ()
{
std::vector v;
std::for_each (v.begin (), v.end (), f);
std::for_each (v.begin (), v.end (), mem_fun(&A::f));
}
Другого способа обобщить такой вызов нет. Приведите пожалуйста "метод получше" из другого языка
Простых указателей на ф-ции не хватает по одной простой прчине, потому что функция не простая, член класса. И если вы изучали ассемблерный код, то наверное заметили, что указатель на функцию-член. И вызывается она немного по другому - компилятор должен запихнуть в стек указатель this, отсюда и "семантическая сложность", в которой я не виджу ничего сложного.
в данном случае и этого не нужно, потому что тут нет привязки к динамическим объектам. Можно через функцию всё сделать
Вы все таки не поняли для чего существуют функторы. Вот вам пример
class A
{
public:
void f () {}
};
void f (A* a)
{
a->f ();
}
void main ()
{
std::vector v;
std::for_each (v.begin (), v.end (), f);
std::for_each (v.begin (), v.end (), mem_fun(&A::f));
}
Другого способа обобщить такой вызов нет. Приведите пожалуйста "метод получше" из другого языка
Хабр скушал мои скобочки :(
mem_fun_t<cls, int>(&cls::f)
Хм. Ничего принципиально, имхо, не изменилось. Как был малопонятный кракозябренный синтаксис, так и остался. Только теперь вместо char* пишут char[] (т.е. похоже понятие "строка" отсутствует)
:-)
:-)
у С++ синтаксис непонятен только тем, кто на нем никогда не пробовал писать. Для остальных он "роднее русского языка" (с) koscoder
ПС
Ни в С ни в С++ никогда не было понятия "строка". В С были символьные массивы, с нулем в конце. Просто их договорились называть строками. В С++ STL появился класс string. Но ни то ни другое не является едементом _языка_, это части стандартных библиотек.
ПС
Ни в С ни в С++ никогда не было понятия "строка". В С были символьные массивы, с нулем в конце. Просто их договорились называть строками. В С++ STL появился класс string. Но ни то ни другое не является едементом _языка_, это части стандартных библиотек.
int main(string[] args)
{
Похоже, все таки присутствует.
{
Похоже, все таки присутствует.
D operator overloads are significantly less powerful than the C++ counterparts.
Ну воооот(((
Все остальные навороты меня уже не так привлекают. Блин. Ну почему нельзя дополнить, исправить, но не обрезать, блин??
Я новость публиковал с той целью, чтобы показать всем, что мы не в конце эволюции языков программирования, что возможны всякие занимательные продолжения. Что даже позиции C++ кто-то потолкать пытается. И достаточно успешно для того, чтобы в GNU обратили на это свой взгляд.
Но высказывания о том, что, мол, да кому этот язык нужен возбудили любопытство, и получилось у меня найти вот это.
http://www.dsource.org/projects/
Из всего многообразия меня заинтересовали движки для компьютерных игр, которых на удивление много. Похоже D полюбили opensource игроделатели.
В репозиториях есть даже несколько живых проектов. tankwars, nonagon, freeuniverse. Там, конечно, дизайнерских откровений нет, но факт, что люди наплодили кучу 3D приложений на этом самом D уже о чём-то говорит.
Есть даже wombat - framework для web. Я не специалист, но, imho, занятная штука http://www.dsource.org/projects/wombat . Ну и FastCGI тоже поддерживается, и поддержка развивается.
Я бы сказал, что D скорее жив, чем мёртв.
И ещё тут говорили про STL и boost. Так они зачем нужны там, где многое из этой функциональности поддерживается прямо на уровне семантики языка?
Вобщем, моё личное мнение: D - это неплохая альтернатива C++ во многих случаях. Эволюция продолжается.
Но высказывания о том, что, мол, да кому этот язык нужен возбудили любопытство, и получилось у меня найти вот это.
http://www.dsource.org/projects/
Из всего многообразия меня заинтересовали движки для компьютерных игр, которых на удивление много. Похоже D полюбили opensource игроделатели.
В репозиториях есть даже несколько живых проектов. tankwars, nonagon, freeuniverse. Там, конечно, дизайнерских откровений нет, но факт, что люди наплодили кучу 3D приложений на этом самом D уже о чём-то говорит.
Есть даже wombat - framework для web. Я не специалист, но, imho, занятная штука http://www.dsource.org/projects/wombat . Ну и FastCGI тоже поддерживается, и поддержка развивается.
Я бы сказал, что D скорее жив, чем мёртв.
И ещё тут говорили про STL и boost. Так они зачем нужны там, где многое из этой функциональности поддерживается прямо на уровне семантики языка?
Вобщем, моё личное мнение: D - это неплохая альтернатива C++ во многих случаях. Эволюция продолжается.
И ещё тут говорили про STL и boost. Так они зачем нужны там, где многое из этой функциональности поддерживается прямо на уровне семантики языка?
Так в этом то все прелесть С++ - в его мультипарадигменности. Зачем перегружать язык кучей синтаксических/сематических елементов, если можно при надобности проюзать библиотеку,которая имплементит нужную тебе парадигму. А с добавлением новых фич типа r-value reference, variadic templates его мощь возрастет в разы. И в этом всем есть огромный плюс - совмемтимость со старым кодом на С/С++, чего не скажешь о D. На и увидел я нем ничего "такого", что могло бы свергнуть С++ с олимпа, особенно с оглядкой на С++09.
Мое ИМХО - D никогда не станет альтернативий С++, а так и останется игрушкой для студентов.
Посмотрим, что чем и когда станет. Вот. Про Ruby, наверняка, то же самое говорили, а теперь вон всем миром день рождение рельсов празднуют.
Ваше соображение
Зачем перегружать язык кучей синтаксических/сематических елементов, если можно при надобности проюзать библиотеку,которая имплементит нужную тебе парадигму. А с добавлением новых фич типа r-value reference, variadic templates его мощь возрастет в разы.
несколько противоречивое, не находите? Сначала вопрос: зачем перегружать? А потом радость по поводу нововведений в и без того уже синтаксически перегруженный СИ++. А СИ++ перегружен, вне всяких сомнений. Когда в языке есть оператор ->*, который я даже прочитать на нормальном языке не могу, а только объяснить, как он работает, то это явный перебор со сложностью, imho.
В D же есть просто несколько встроенных типов. Они не требуют знания принципиально новых синтаксических конструкций. Просто обычные типы, вот и всё.
Кстати, СИ++ не так популярен, как может показаться. По крайней мере, в opensource сообществе 80% проектов (давних и недавних) пишутся на СИ. А в Windows язык прижился только по той, imho, причине, что его поддерживают всякие Wizard'ы и навязывают библиотеки, вроде MFC и DirectX.
Кстати, вот на этот счёт статистика, с подробным описанием того, от куда берутся цифры. http://www.welton.it/articles/language_p…
Ваше соображение
Зачем перегружать язык кучей синтаксических/сематических елементов, если можно при надобности проюзать библиотеку,которая имплементит нужную тебе парадигму. А с добавлением новых фич типа r-value reference, variadic templates его мощь возрастет в разы.
несколько противоречивое, не находите? Сначала вопрос: зачем перегружать? А потом радость по поводу нововведений в и без того уже синтаксически перегруженный СИ++. А СИ++ перегружен, вне всяких сомнений. Когда в языке есть оператор ->*, который я даже прочитать на нормальном языке не могу, а только объяснить, как он работает, то это явный перебор со сложностью, imho.
В D же есть просто несколько встроенных типов. Они не требуют знания принципиально новых синтаксических конструкций. Просто обычные типы, вот и всё.
Кстати, СИ++ не так популярен, как может показаться. По крайней мере, в opensource сообществе 80% проектов (давних и недавних) пишутся на СИ. А в Windows язык прижился только по той, imho, причине, что его поддерживают всякие Wizard'ы и навязывают библиотеки, вроде MFC и DirectX.
Кстати, вот на этот счёт статистика, с подробным описанием того, от куда берутся цифры. http://www.welton.it/articles/language_p…
несколько противоречивое, не находите? Сначала вопрос: зачем перегружать? А потом радость по поводу нововведений
не нахожу, потому что это действительно необходимо. Без этих елементов невозможно (или возможно, но с ограничениями) решить большой класс задач, именно потому их добавили в стандарт.
А СИ++ перегружен, вне всяких сомнений. Когда в языке есть оператор ->*, который я даже прочитать на нормальном языке не могу, а только объяснить, как он работает, то это явный перебор со сложностью, imho.
Возможно где-то и перегружен, но только ради совметимости с С. По поводу ->*, а как вы предлагаете обозаначать доступ к члену класса по указателю? По моему, вполне логичное обозначение.
Решение чего? Зачем это вообще нужно? Если главный лозунг ООП - инкапсуляция и полиморфизм, то... указатель на элемент класса... Это что? Инструмент ради инструмента?
Без этих елементов невозможно (или возможно, но с ограничениями) решить большой класс задач, именно потому их добавили в стандарт.
Невозможно в рамках C++ - так правильнее описывать ситуацию. И потом, а не являются ли задачи надуманными? Ну вот нельзя там аргументы передать красиво, ну и что? Неужели, ради того, чтобы было красиво стоит ad hoc патчить синтаксис?
Вот они про move семантику пишут. Что надо различать, когда можно move, а когда нельзя. Но зачем это нужно? Разве нельзя реализовать строки так, чтобы копировать приходилось только указатели, при этом под полным контролема программиста, а не runtime, фиг знает, как написанном?
Не говоря уже о том, что move семантика эта самая в контексте многопоточных приложений выльется вообще в дикую головную боль. Программистам опять нужно будет залезать в глубины исходников библиотек, которые написаны тысячами программистов под бдительным руководством сотен менеджеров (а следовательно запутанны настолько, насколько вообще это возможно), чтобы понять, а можно объект использовать в нескольких потоках одновременно или нельзя. Блаженные те, кто с этим никогда не сталкивался, даже в случае copy семантики. Желаю им да не столкнуться с подобными никогда.
Без этих елементов невозможно (или возможно, но с ограничениями) решить большой класс задач, именно потому их добавили в стандарт.
Невозможно в рамках C++ - так правильнее описывать ситуацию. И потом, а не являются ли задачи надуманными? Ну вот нельзя там аргументы передать красиво, ну и что? Неужели, ради того, чтобы было красиво стоит ad hoc патчить синтаксис?
Вот они про move семантику пишут. Что надо различать, когда можно move, а когда нельзя. Но зачем это нужно? Разве нельзя реализовать строки так, чтобы копировать приходилось только указатели, при этом под полным контролема программиста, а не runtime, фиг знает, как написанном?
Не говоря уже о том, что move семантика эта самая в контексте многопоточных приложений выльется вообще в дикую головную боль. Программистам опять нужно будет залезать в глубины исходников библиотек, которые написаны тысячами программистов под бдительным руководством сотен менеджеров (а следовательно запутанны настолько, насколько вообще это возможно), чтобы понять, а можно объект использовать в нескольких потоках одновременно или нельзя. Блаженные те, кто с этим никогда не сталкивался, даже в случае copy семантики. Желаю им да не столкнуться с подобными никогда.
Указатель на член - это инструмент обобщенного (или мета-) программирования и ООП здесь ни причем. Еще раз С++ - мультипарадигменный язык.
Ну и чего вы привязались к этому примеру со строками? Он был приведен просто для нагладности. Основное применение move семантики - передача владения (указателем, обьектом ядра, чем угодно) от временного обьекта к постоянному. А создавать подобные временные обьекты в куче, и наворачивать потом алгоритмы очистки памяти... это уже из другой оперы. С++ предназначен для решения критических задач, и здесь очень важно иметь полный контроль наж временем жизни обьекта. В С++09 сборщик мусора конечно будет, но там будет возможность решать, отдавать обьект ему на растерзание или нет.
Ну и чего вы привязались к этому примеру со строками? Он был приведен просто для нагладности. Основное применение move семантики - передача владения (указателем, обьектом ядра, чем угодно) от временного обьекта к постоянному. А создавать подобные временные обьекты в куче, и наворачивать потом алгоритмы очистки памяти... это уже из другой оперы. С++ предназначен для решения критических задач, и здесь очень важно иметь полный контроль наж временем жизни обьекта. В С++09 сборщик мусора конечно будет, но там будет возможность решать, отдавать обьект ему на растерзание или нет.
Это в некоторый момент произошла путаница в переводе терминов. Метапрограммирование - это не обобщённое программирование - general programming, а generative programming - порождающее программирование. То есть такой подход, в котором пишется программа, для того, чтобы написать другую программу. В C++ для этого используются шаблоны. То есть, imho, структурированные макросы на стероидах. И как в эту картину естественно вписать указатель на элемент класса, всё же, я не понимаю. Искусственно, да. Вписывается... Но этот удачный союз для меня из области мистики. Логично я его объяснить никак не могу.
Шаблоны в С++ - это как раз обобщенное программирование. Порождающее - это когда код порождается НА ЭТАПЕ ВЫПОЛНЕНИЯ программы, шаблоны же инстанциируются на этапе компиляции. По поводу "структурированные макросы на стероидах" даже спорить не хочу, макросы там и близко не валялись. Читаем Александреску, если интересует.
Указатель на функцию (не только функцию член, любую) туда вписывается очень даже естественно - это просто вызываемая сущность.
Указатель на функцию (не только функцию член, любую) туда вписывается очень даже естественно - это просто вызываемая сущность.
С последним абзацем частично согласен. С многопоточностью проблемы всегда были и будут. Просто нужно пользоваться библиотеками, которые предусматривают работу в многопоточной среде, ну и свое приложение проектировать исходя из этого.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
язык D в реализации от GNU