Comments 84
UFO just landed and posted this here
жесть, ну не нужен «специальный оператор обмена» :=:. И так разобраться во всём, что добавили трудно, учитывая, что сколько не работай с С++03 — «каждый день что-то новое узнаёшь».
Да, бессмыслица. В C# были разговоры чтобы сделать :=: binding operator, но там это возможно и имеет смысл. А как сокрашение для swap — сомнительно.
Почему не нужен? swap неудобен, потому что обобщённая версия находится в namespace std. Из-за этого приходится писать:
С оператором :=: можно будет просто:
using std::swap;
swap(a, b); // a & b - два шаблонных типа
С оператором :=: можно будет просто:
a :=: b;
а если я хочу, чтобы
Согласитесь, что не нужно делать изменения в языке, чтобы избежать одной только, понятной всем, маленькой строчки кода
swap действительно был выбран из std? Вы ответите — тогда просто пишем std::swap(a, b). А теперь в коде появляется и swap и :=:. И swap более заметен, чем :=:(это как с советом «определяйте функция преобразования operator T() только в крайних случаях»).Согласитесь, что не нужно делать изменения в языке, чтобы избежать одной только, понятной всем, маленькой строчки кода
using std::swap;. Это излишне. В С++ и так слишком много штук, которые можно сделать в слишком много способов, не нужно добавлять избыточности.UFO just landed and posted this here
Пока они там тупили, куча народу убежала на шарп и уже никогда не вернется.
Да, C++ имеет фатальный недостаток, и именно поэтому MS родили C#
Шарп это не кроссплатформенное (очередная закрытая платформа от MS без фатального недостатка), к тому же тормозное решение, с непредсказуемо работающим сборщиком мусора, и не дающее прямой доступ доступ к железу. Единственно для чего полноценно пригоден шарп это написания гуй приложений под винду, и в общем то всё, т.е. никаких высоких нагрузок, никаких встраиваемых решений. Если бы MS сделала C++ библиотеку для работы со своей системой, сопоставимую по уровню удобства использования со стандартными либами C#, то шарп использовался бы гораздо-гораздо реже.
p.s: да и вообще не понятно зачем писать в этом топике о шарпе, напишите статью сравнение, раскройте нам глаза, покажите насколько убогий С++, и почему C# лучше
p.s: да и вообще не понятно зачем писать в этом топике о шарпе, напишите статью сравнение, раскройте нам глаза, покажите насколько убогий С++, и почему C# лучше
> с непредсказуемо работающим сборщиком мусора
А что, есть предсказуемые?
А что, есть предсказуемые?
Нет, но это не важно. Ведь в C++ есть только ручное управление памятью, а именно эти два языка и сравниваем.
И при этом забываем, что необходимо использовать аллокаторы, умные указатели, которые еще потребляют памяти, влияют на производительность, чтобы хоть как-то «правильно» управлять памятью.
Например, парсер CSS, написанный на C#, выдает следующие результаты (с полным построением объектной модели):
1) 30 Mb/s для файлов более 7 Mb.
2) 61 Mb/s для файлов размером до 128 Kb.
Разница между объемами происходит из-за размеров поколений объектов (а любой парсер выдает огромное кол-во токенов).
Те же данные для парсера от Mozilla:
1) 30 Mb/s (стабильно).
Для реальных сценариев, когда файлов много, а их размер до 128 кб, вариант C# работает намного быстрее.
Например, парсер CSS, написанный на C#, выдает следующие результаты (с полным построением объектной модели):
1) 30 Mb/s для файлов более 7 Mb.
2) 61 Mb/s для файлов размером до 128 Kb.
Разница между объемами происходит из-за размеров поколений объектов (а любой парсер выдает огромное кол-во токенов).
Те же данные для парсера от Mozilla:
1) 30 Mb/s (стабильно).
Для реальных сценариев, когда файлов много, а их размер до 128 кб, вариант C# работает намного быстрее.
скажу вам по секрету, помимо shared_ptr есть еще и unique_ptr ;)
> парсер CSS, написанный на C#
да что вы удивляетесь-то? есть примеры, когда программы написанные на Си, выполняются медленнее чем аналог, написанный на bash.
> парсер CSS, написанный на C#
да что вы удивляетесь-то? есть примеры, когда программы написанные на Си, выполняются медленнее чем аналог, написанный на bash.
да я не удивляюсь, т.к. пишу на обоих языках и занимаюсь разработкой данного парсера.
просто в большинстве случаев, как только доходит дело до реального проекта, начинаешь понимать, что огромным плюсом сборки мусора является обработка графа объектов.
Все же move semantics не является панацеей, более того unique_ptr не всегда приемлем.
просто в большинстве случаев, как только доходит дело до реального проекта, начинаешь понимать, что огромным плюсом сборки мусора является обработка графа объектов.
Все же move semantics не является панацеей, более того unique_ptr не всегда приемлем.
Почему-то у меня от реальных проектов впечатление строго противоположное. Хотя, возможно, это происходит потому, что мы с вами как бы на несколько разных уровнях работаем.
То есть, да, то что парсер XML «с полным построением объектной модели» работает на C# вдвое быстрее — это круто, но когда в «реальном сценарии» версия на C# (или Java) использует свой суперскоростной парсер, а версия на C++ использует ну, скажем, Cap'n Proto через shared memory и работает этак в 10 (а то и в 100) раз быстрее, то неожиданно оказывается что те 10% случаев где XML парсер всё же сохраняется погоды уже не делают.
То есть, да, то что парсер XML «с полным построением объектной модели» работает на C# вдвое быстрее — это круто, но когда в «реальном сценарии» версия на C# (или Java) использует свой суперскоростной парсер, а версия на C++ использует ну, скажем, Cap'n Proto через shared memory и работает этак в 10 (а то и в 100) раз быстрее, то неожиданно оказывается что те 10% случаев где XML парсер всё же сохраняется погоды уже не делают.
> более того unique_ptr не всегда приемлем.
там, где неприемлем unique_ptr, есть shared_ptr. все, третьего не дано. либо, реализатор чего-то не понимает, и, таким образом, выдумывает невыдумываемое.
ну, или, я таки чего-то дейтствительно не понимаю — тогда — объясните, пожалуйста.
там, где неприемлем unique_ptr, есть shared_ptr. все, третьего не дано. либо, реализатор чего-то не понимает, и, таким образом, выдумывает невыдумываемое.
ну, или, я таки чего-то дейтствительно не понимаю — тогда — объясните, пожалуйста.
вы все правильно понимаете, здесь вопрос на два комментария выше заключался в том, что существует overhead для некоторых операций (вызов конструктора/деструктора и копирование), кроме разыменования указателя.
просто по сравнению со C#, постоянная работа с указателями несколько отквлекает от самого процесса разработки.
ну вот например, shared_ptr — самый настоящий ref-counted object. кроме того произодит аллокацию 3 объектов: счетчика, самого объекта и deleter'a. еще и необходимо использовать make_shared функцию, чтобы избежать выделения двух блоков памяти.
если же рассматривать именно std::shared_ptr и версию из boost, то производительность у первого будет больше из-за rvalue references.
статья на хабре раскрывает более наглядно вопрос.
просто по сравнению со C#, постоянная работа с указателями несколько отквлекает от самого процесса разработки.
ну вот например, shared_ptr — самый настоящий ref-counted object. кроме того произодит аллокацию 3 объектов: счетчика, самого объекта и deleter'a. еще и необходимо использовать make_shared функцию, чтобы избежать выделения двух блоков памяти.
если же рассматривать именно std::shared_ptr и версию из boost, то производительность у первого будет больше из-за rvalue references.
статья на хабре раскрывает более наглядно вопрос.
> постоянная работа с указателями несколько отквлекает от самого процесса разработки.
я не могу согласиться, что в с++ постоянно приходится работать с указателями/смарт-указателями. большинство кода, все же, выполняется в стеке. указатели/смарт-указатели — это довольно таки редкий случай.(говорю о себе)
я не могу согласиться, что в с++ постоянно приходится работать с указателями/смарт-указателями. большинство кода, все же, выполняется в стеке. указатели/смарт-указатели — это довольно таки редкий случай.(говорю о себе)
Тут дело не только в удобстве разработки. Дело в том, что delete отрабатывает часто медленнее, чем new. Миллион последовательных вызовов delete сделает кучу ненужно работы, пытаясь каждый вызов упорядочить кучу, подключить осводождённый блок в смежный свободный.
А сборщик мусора может сразу объединить все смежные свободные блоки в один (тем более, что он может работать в другом потоке).
А сборщик мусора может сразу объединить все смежные свободные блоки в один (тем более, что он может работать в другом потоке).
> delete отрабатывает часто медленнее, чем new.
не знаю, не проверял. к тому же, это зависит как от ОС, так и от используемого аллокатора. в добавок к этому, программа может использовать свой менеджер памяти поверх того что в системе.
к тому же, разговор шел о смарт-указателях.
не знаю, не проверял. к тому же, это зависит как от ОС, так и от используемого аллокатора. в добавок к этому, программа может использовать свой менеджер памяти поверх того что в системе.
к тому же, разговор шел о смарт-указателях.
Нет. Разговор шёл о том, почему парсер на C# может обогнать C++ по скорости
Что вы имеете в виду под аллокацией deleter'а?
У shared_ptr есть указатель на счетчик и указатель на объект, конструктор, деструктор, конструктор копирования и оператор присваивания, в которых и работает вся его логика. Какая необходимость в аллоцировании некоего deleter'а?
У shared_ptr есть указатель на счетчик и указатель на объект, конструктор, деструктор, конструктор копирования и оператор присваивания, в которых и работает вся его логика. Какая необходимость в аллоцировании некоего deleter'а?
Smart Pointer Programming Techniques.
Preventing delete px.get()
Using a shared_ptr to hold another shared ownership smart pointer
но ведь можно не задавать этот вложенный функтор-делетер бустовскому shared_ptr'у.
К тому же туда третьим параметром передается НЕ ОБЪЕКТ, а АДРЕС ОПЕРАТОРА (), т.е. УКАЗАТЕЛЬ НА ФУНКЦИЮ вложенного класса deleter.
class deleter
{
public:
void operator()(X * p) { delete p; }
};
вот этот void operator()( бла-бла ) {бла-бла} — это описание метода по сути
поэтому здесь
shared_ptr px(new X, deleter());
третий параметр deleter() — это передача указателя на оператор-метод.
Здесь может возникнуть вопрос — почему не передается указатель на объект в котором находится operator(), т.е. deleter*, и перед этим даже не инстанцирован?
Я пока ответа не знаю, думаю, потому, что operator() как бы статический метод, потому что он не имеет права обращаться к полям класса deleter наверное. Надо покурить мануалы.
К тому же туда третьим параметром передается НЕ ОБЪЕКТ, а АДРЕС ОПЕРАТОРА (), т.е. УКАЗАТЕЛЬ НА ФУНКЦИЮ вложенного класса deleter.
class deleter
{
public:
void operator()(X * p) { delete p; }
};
вот этот void operator()( бла-бла ) {бла-бла} — это описание метода по сути
поэтому здесь
shared_ptr px(new X, deleter());
третий параметр deleter() — это передача указателя на оператор-метод.
Здесь может возникнуть вопрос — почему не передается указатель на объект в котором находится operator(), т.е. deleter*, и перед этим даже не инстанцирован?
Я пока ответа не знаю, думаю, потому, что operator() как бы статический метод, потому что он не имеет права обращаться к полям класса deleter наверное. Надо покурить мануалы.
Лучше бы MS написали сборщик мусора для C++ и вошли бы в комитет по стандартизации C++ и включили бы этот сборщик в стандарт C++ Тогда бы плюсовый парсер выдавал бы >61Mb/s
Да, инкрементальные и realtime сборщики. Многим можно устанавливать продолжительность максимальной паузы или запускать сборку когда удобно, что делает процесс предсказуемым
В этом смысле да, но я говорил несколько про другое. Если рассмотреть вопрос более подробно, то при ручном управлении ресурсами в принципе не может возникнуть ситуации когда после какой либо работы софт может потреблять память, которая ему уже не нужна, однако со сборщиком, такие ситуации происходят часто и являются нормой. Исключением тут является, верно указанный Вами, сборщик реального времени, аналогом которого являются умные указатели в C++, и который, в общем то сборщиком является лишь формально. Помимо этого сборщики создают проблемы тогда, когда оборудование загружено полностью, и свободных ресурсов на сборку нет, что в итоге приведёт к задержкам, которые могут не приемлемы в принципе. В качестве примера можно взять геймдев, где стараются добиться максимального контроля над всеми возможными ресурсами для избежания «лагов».
Единственно для чего полноценно пригоден шарп это написания гуй приложений под винду
Веб забыли.
Благодарю, да забыл, но веб только под Windows. Ибо любой, кто работал с Mono скажет, что использовать его на *nix скорее извращение, чем реальный продакшн, да и придирки со стороны MS по поводу патентов были.
В современном мире веб под виндой — это не оксюморон; ось вообще вторична. Какие придирки?
Это просто уточнение, ибо NET всё время заявляется маркетологами MS как кроссплатформенное решение, а на деле это не соответствует реальности. Вообще лично я вижу только одну проблему для web на Windows — это более дорогие решения (из-за лицензии на сам Windows).
Ошибаюсь, не было, но теоретически возможны.
p.s: у меня у самого веб на Windows, правда без .NET, там только PHP, и там только готовые решения. Но он такой просто потому что так получилось, ибо уже было оборудование с Windows на борту.
Какие придирки?
Ошибаюсь, не было, но теоретически возможны.
p.s: у меня у самого веб на Windows, правда без .NET, там только PHP, и там только готовые решения. Но он такой просто потому что так получилось, ибо уже было оборудование с Windows на борту.
Не говорите того, чего не знаете, Mono на мобильных платформах уже очень крутое, мы на работе даже на нем пишем под ios, android.
На C# можно писать и приложения для высоких нагрузок. Необходимо иметь хорошую культуру кода и придерживаться определенных правил (к примеру отказ от исключений может быть необходим). Но и как любой инструмент имеет свои преимущества и недостатки. В некоторых компонентах не обойтись без нативной реализации на C++. Но в последнее время, как мне кажется, плата за написание на C# становится более приемлемой в все большей части компонент и необходимости в C++ меньше.
Основное достоинство C# по сравнению с C++ — скорость разработки. На C++ банально медленнее писать код. И компиляция намного медленнее. Старая система C++ с include-ами создает массу проблем статического анализа кода, с которой у C# проблем вообще нет. Это позволяет использовать автоматические утилиты, которые упрощают написание кода. К тому же в C# есть возможность перевести GC в режим реального времени (возможность гарантировать выполнение кода последовательно без перерыва на сборку мусора).
Проприетарность C# также позволяет внедрять новинки намного чаще. Это немаловажно. И к счастью это понял комитет С++. С++14 — тому подтверждение. Что не может не радовать.
Ещё раз подчеркну, у каждого инструмента свое применение. У C++ свое, у C# свое. Но не надо поливать грязью инструмент которым вы не умеете решать определенную задачу, если вы умеете это делать другим. И про скорость, надеюсь вы не будете спорить что разработка на C# (или Python к примеру) не будет на порядок быстрее чем разработка на C++.
Основное достоинство C# по сравнению с C++ — скорость разработки. На C++ банально медленнее писать код. И компиляция намного медленнее. Старая система C++ с include-ами создает массу проблем статического анализа кода, с которой у C# проблем вообще нет. Это позволяет использовать автоматические утилиты, которые упрощают написание кода. К тому же в C# есть возможность перевести GC в режим реального времени (возможность гарантировать выполнение кода последовательно без перерыва на сборку мусора).
Проприетарность C# также позволяет внедрять новинки намного чаще. Это немаловажно. И к счастью это понял комитет С++. С++14 — тому подтверждение. Что не может не радовать.
Ещё раз подчеркну, у каждого инструмента свое применение. У C++ свое, у C# свое. Но не надо поливать грязью инструмент которым вы не умеете решать определенную задачу, если вы умеете это делать другим. И про скорость, надеюсь вы не будете спорить что разработка на C# (или Python к примеру) не будет на порядок быстрее чем разработка на C++.
И не забываем, что в C# есть PInvoke, который позволяет отлично интегрироваться с unmanaged библиотеками, что в сочетании дает довольно мощный инструмент! На C# можно даже службы писать, удобство программирования которых много больше того прироста скорости, который дал бы C.
И чертовски согласен с этой фразой:
>> Ещё раз подчеркну, у каждого инструмента свое применение
И чертовски согласен с этой фразой:
>> Ещё раз подчеркну, у каждого инструмента свое применение
Благодарю за развёрнутый ответ.
Безусловно разработка на С++ реально менее быстрая и удобная чем на C#, или на каком либо другом языке, не обременённым грузом обратной совместимости. С Python, к примеру, ещё более занятно получается, собственно я даже часто прототипы именно на нём делаю, а потом переписываю на C++.
Да можно, и на Java можно, да и не только на них, но далеко не для всех областей — для сурового геймдева (расписал подробнее в другом комментарии), и встраиваемых решений фактически везде можно использовать C/С++, а вот Java и C# получится не везде.
По хорошему это вообще относится к любому языку, и любой области, а не только к высоким нагрузкам.
Для высоких нагрузок это к С++ вполне применимо.
Так я и не поливаю C# грязью, более того, я и на нём тоже пишу, мой комментарий это строго ответ на комментарий mynameco:
поскольку никто никуда не бегал, и как Вы очень верно верно написали
Помимо этого, и более развёрнуто на тему того, что MS должна была сделать, но не сделала для C++, возложив при этом эти задачи на C# расписал тут, т.е. фактически мой комментарийтонко толсто :( намекает на то, что можно было сделать несколько по другому, т.е. вполне можно было всю базовую часть компонентов сразу сделать библиотеками на C/C++, т.е. в нативном коде, и эти библиотеки лишь были бы обёрнуты API прослойкой в C#. Таким образом удалось бы сократить разницу в версиях самого C#, и значительно упростить его реализацию для разных систем. Помимо этого наличие именно нативных библиотек решает многие современные проблемы Windows (по ссылке я как раз расписал одну из самых заметных проблем, которую мы сейчас имеем — это абсолютно разношёрстный GUI в приложениях).
Безусловно разработка на С++ реально менее быстрая и удобная чем на C#, или на каком либо другом языке, не обременённым грузом обратной совместимости. С Python, к примеру, ещё более занятно получается, собственно я даже часто прототипы именно на нём делаю, а потом переписываю на C++.
На C# можно писать и приложения для высоких нагрузок.
Да можно, и на Java можно, да и не только на них, но далеко не для всех областей — для сурового геймдева (расписал подробнее в другом комментарии), и встраиваемых решений фактически везде можно использовать C/С++, а вот Java и C# получится не везде.
Необходимо иметь хорошую культуру кода и придерживаться определенных правил
По хорошему это вообще относится к любому языку, и любой области, а не только к высоким нагрузкам.
к примеру отказ от исключений может быть необходим
Для высоких нагрузок это к С++ вполне применимо.
Но не надо поливать грязью инструмент которым вы не умеете решать определенную задачу, если вы умеете это делать другим
Так я и не поливаю C# грязью, более того, я и на нём тоже пишу, мой комментарий это строго ответ на комментарий mynameco:
Пока они там тупили, куча народу убежала на шарп и уже никогда не вернется.
поскольку никто никуда не бегал, и как Вы очень верно верно написали
Ещё раз подчеркну, у каждого инструмента свое применение.
Помимо этого, и более развёрнуто на тему того, что MS должна была сделать, но не сделала для C++, возложив при этом эти задачи на C# расписал тут, т.е. фактически мой комментарий
>>C++ имеет фатальный недостаток, и именно поэтому MS родили C#
Вот это поворот: шарп теперь уже калька с C++.
Про жабу, тащемта, уже забыли?
Вот это поворот: шарп теперь уже калька с C++.
Про жабу, тащемта, уже забыли?
Нет, не забыли, жаба, по всей видимости, имеет такой же фатальный недостаток, как и плюсы, ибо MS могли вполне использовать, и при этом как угодно допиливать, жабу вместо разработки своего закрытого решения.
Пытались, en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine
Но SUN запретил им реализовывать свою JavaVM, а зависеть от чужой MS не мог себе позволить.
Но SUN запретил им реализовывать свою JavaVM, а зависеть от чужой MS не мог себе позволить.
p.s: и шарп не калька с C++, просто если посмотреть на те «удобные» библиотеки для C++ от MS, в качестве яркого примера можно взять ATL (WTL) для программирования GUI, то становится видно, что MS на поддержку C++ просто забила, и вместо этого, не помимо этого, а именно вместо предпочла реализовать шарп, но уже с блекджеком и профурсетками.
Возможно, вы не понимаете назначение и суть WTL. Это всего лишь тонкая обёртка над WinAPI. И она прекрасно справляется со своей задачей: даёт объектную модель контролов, управляет доставкой сообщений. То, что WTL не выдерживает конкуренции с другими gui-фреймворками, это вина устаревшего WinAPI, а не обёртки.
Почему MS не стала делать новый GUI-фреймворк на Native code, а сделала WPF в Managed — другой вопрос.
Почему MS не стала делать новый GUI-фреймворк на Native code, а сделала WPF в Managed — другой вопрос.
Почему MS не стала делать новый GUI-фреймворк на Native code, а сделала WPF в Managed — другой вопрос.
Вот собственно в этом и проблема. Суть и назначение WTL я понимаю, но обратите внимание, что у MS для нативной реализации нет удобного редактора для GUI, и полноценной библиотеки, для конечного использования (без необходимости дописывания элементарных вещей), тоже нет. Собственно, имхо конечно, но в т.ч. из-за того, что MS пренебрегла поддержкой нативного GUI мы сейчас имеем под Windows адский зоопарк и полное отсутствие единообразия в интерфейсе приложений, ибо абсолютно у всех крупных компаний используется свои велосипеды, а у остальных что то другое (кютэ, вэикс-виджеты, или что угодно ещё).
Вот собственно в этом и проблема.
В чём? В том, что WPF — managed? Он доступен из managed c++, где наряду с обычными объектами можно создавать .net-овские.
обратите внимание, что у MS для нативной реализации нет удобного редактора для GUI
Есть обычный редактор ресурсов, его возможности соответствуют возможностям WinAPI 25-летней давности. А что ещё надо? Создать обработчик нажатия кнопки по двойному клику на неё? Это было в MFC. Слишком мелкий сервис, по сравнению с остальными ограничениями API пустяк. Несложно обработчик написать руками. Кстати, в WPF при MVVM опять всё пишется руками :)
из-за того, что MS пренебрегла поддержкой нативного GUI мы сейчас имеем под Windows адский зоопарк и полное отсутствие единообразия в интерфейсе приложений, ибо абсолютно у всех крупных компаний используется свои велосипеды, а у остальных что то другое (кютэ, вэикс-виджеты, или что угодно ещё)
У MS особая роль. Она не может делать фреймворк, заточенный под один язык (как сделал Borland) или кросс-платформенный, но активно построенный на языковых фичах (куда двигаются Qt, wxWidgets и т.п.). Я считаю, у неё особо и выбора не было делать лучше, чем есть сейчас. Перекос в сторону одного языка (c++, например) может завалить всю платформу. Не появился бы Delphi, Visual FoxPro и т.п., т.к. не выдержал бы конкуренцию с языком, интегрированным в ОС посредством IDE от производителя ОС.
В чём? В том, что WPF — managed? Он доступен из managed c++, где наряду с обычными объектами можно создавать .net-овские.
Безусловно можно, вот только когда у, вроде как нативного, приложения появляется зависимость от очень толстого (сотни мегабайт) NetFramework, который не является обязательной частью системы и имеет множество возможных версий, то у разработчиков возникают проблемы на ровном месте.
Перекос в сторону одного языка (c++, например) может завалить всю платформу.
Так в том то и дело, что не будет никакого перекоса, ведь С/C++ библиотеки это фактически нативный код на котором, наверняка, написан и C#, да и многие другие компоненты. Т.е. если сказать по другому вместо того, что бы делать C# монолитным, MS вполне могла сделать его двухслойным — первый слой либы на C/C++, являющиеся в итоге и
Не появился бы Delphi, Visual FoxPro и т.п., т.к. не выдержал бы конкуренцию с языком, интегрированным в ОС посредством IDE от производителя ОС.
Появились бы :)
p.s:
Это было в MFC.
В том то и дело, что было, да сплыло.
вместо того, что бы делать C# монолитным, MS вполне могла сделать его двухслойным
Нет, большая часть WPF уже опирается на CLR.
Запустить этот гуи без CLR не получится.
А зависимость от «очень толстого (сотни мегабайт) NetFramework» актуальна разве что при написании приложений под WinXP и компьютеры 8-10 летней давности.
Благодарю за разъяснения.
p.s: я видимо не точно выразился, проблема просто в том, что на Windows нет менеджера пакетов, и соответственно тут нет нормального механизма установки софта, т.е. что бы просто указать зависимость в пакете, а дальше «оно само». В итоге приходится либо с собой носить дистриб фреймворка, либо самому же подгружать его, если его вдруг не оказалось. Проблема актуальна не только под XP ибо пользователи как только не «оптимизируют» свои системы :) Можно конечно просто в инсталляторе написать, что нужен NET, и всё, но вот только эти сообщения никто не читает толком, и в итоге проблема ляжет на техподдержку.
p.s: я видимо не точно выразился, проблема просто в том, что на Windows нет менеджера пакетов, и соответственно тут нет нормального механизма установки софта, т.е. что бы просто указать зависимость в пакете, а дальше «оно само». В итоге приходится либо с собой носить дистриб фреймворка, либо самому же подгружать его, если его вдруг не оказалось. Проблема актуальна не только под XP ибо пользователи как только не «оптимизируют» свои системы :) Можно конечно просто в инсталляторе написать, что нужен NET, и всё, но вот только эти сообщения никто не читает толком, и в итоге проблема ляжет на техподдержку.
Мне вот интересно, как комитет выбирает — добавить новое ключевое слово или добавить новую разрывающую мозг конструкцию из спецсимволов?
Например, почему constexpr — это слово, auto — это слово, а лямбда — не lambda, а []?
И если для && для move-sematics это еще ладно, амперсенд ассоциируется только с ссылками, но квадратные скобки-то как с функцями связаны?
Соответственно, имхо, swap написать тупо быстрее, чем :=: (учитывая, что нужно до шифта тянуться, символов всего на один меньше, а ясности меньше).
Еще интересно, почему в качестве разделителя выбрали одинарную кавычку, а не нижнее подчеркивание (которое макросы не сломало бы, вроде).
Например, почему constexpr — это слово, auto — это слово, а лямбда — не lambda, а []?
И если для && для move-sematics это еще ладно, амперсенд ассоциируется только с ссылками, но квадратные скобки-то как с функцями связаны?
Соответственно, имхо, swap написать тупо быстрее, чем :=: (учитывая, что нужно до шифта тянуться, символов всего на один меньше, а ясности меньше).
Еще интересно, почему в качестве разделителя выбрали одинарную кавычку, а не нижнее подчеркивание (которое макросы не сломало бы, вроде).
видимо в случае, когда ожидается тип переменной или модификаторы типа распарсить несколько дополнительных слов несложно
если же речь о lambda, то непонятно как ее тогда отличать от обычной функции или объекта с таким именем
если же речь о lambda, то непонятно как ее тогда отличать от обычной функции или объекта с таким именем
Очевидно, запретить использование ключевого слова lambda в любом другом качестве. Насколько я понимаю, нельзя ведь создать переменную double int или функцию void auto(void).
> запретить использование ключевого слова lambda
ага, и обязать всех рефакать свой код, которого, в сумме, больше чем людей на планете в несколько раз.
хорошо, что не Вы принимали это решение.
ага, и обязать всех рефакать свой код, которого, в сумме, больше чем людей на планете в несколько раз.
хорошо, что не Вы принимали это решение.
Почему же введенные в С++11 новые ключевые слова вас не смущают? Они ведь тоже наверняка использовались как названия.
Понятное дело, что нужен какой-то компромисс, я всего лишь хотел подчеркнуть, что ключевое слово обычно понятнее, чем хитрое сочетание спецсимволов.
Понятное дело, что нужен какой-то компромисс, я всего лишь хотел подчеркнуть, что ключевое слово обычно понятнее, чем хитрое сочетание спецсимволов.
Видимо логика строилась на том, что ключевого слова function для функций нет, стало быть и для лямбд его не надо. А скобки просто для передачи контекста в лямбду.
А кто читал вот это? dlang.ru/Why-D-is-Better
На сколько можно верить тому, что на D код пишется быстрее?
На сколько можно верить тому, что на D код пишется быстрее?
D хорош в теории. Пока, к сожалению, не на практике. И, чего лукавить, вряд ли когда-нибудь будет.
Можно(нужно) собрать на кикстартере необходимую сумму и наконец пробустить Ди как минимум в плане рекламы. Хороший толчкок — вот что поможет няшке Ди выбраться из замкнутого круга: язык не развивается, потому что низкая популярность, потому что язык не развивается, потому что...
Аргументируйте
Что именно? Что плох на практике? А где библиотеки? Или вы всё будете с нуля реализовывать? А где пользователи, огромное сообщество на SO, кучи гайдов? Или с каждой проблемой вы будете сами разбираться? Всё может быть сколько угодно красиво в теории, но использовать подобое «в продакшине» — нет, извините.
Языку больше 10 лет, а факт того, что один из его главных идеологов закоммитил 5 тысяч строк, использующих D, в код фэйсбука, преподносится как нечто невероятное. По-моему, очевидно, что не взлетел и уже вряд ли взлетит.
EDIT: и нет, не поймите меня неправильно. Я двумя руками был бы за то, чтобы D «выстрелил». У плюсов горы недостатков и большое количество из них D таки закрывает. Но вот пока как-то не очень вышло.
Языку больше 10 лет, а факт того, что один из его главных идеологов закоммитил 5 тысяч строк, использующих D, в код фэйсбука, преподносится как нечто невероятное. По-моему, очевидно, что не взлетел и уже вряд ли взлетит.
EDIT: и нет, не поймите меня неправильно. Я двумя руками был бы за то, чтобы D «выстрелил». У плюсов горы недостатков и большое количество из них D таки закрывает. Но вот пока как-то не очень вышло.
На практике он тоже весьма хорошо. Просто много времени было упущено на метания между D1 и D2.
Однозначно быстрее. Если взять для сравнения С++ и Python. На D код пишется так же быстро как и на питоне.
У меня складывается все более стойкое ощущение, что современные стандарты C++, это не «C++», а «C» с костылями… Хотя некоторые возможности действительно полезны.
внести в С++ специальный оператор обмена :=:
Давайте уж сразу оператор
:=, чтобы C++-ники совсем от стыда сгорели…
Библиотеки для работы с сетью, файловой системой и для написания конкурентного кода — это очень хорошо. Спасибо за обзор!
Filesystem в бусте на моей памяти вызывал гораздо больше проблем чем решал. Сама библиотека нужная, но бустовую реализацию делают какие-то странные люди. Может, если она таки войдет в стандарт, из нее уберут все то кривое что там есть, но на мой взгляд достаточно показательно что из 54-го буста с 2013-й вижлстудией проблемы возникли только у Filesystem.
Отдельного упоминания заслуживает тот факт, что на линуксе кодировка имен файлов Filesystem является вполне логичным UTF8, на виндовс-платформах — wchar. Что порождает целый класс неочевидных ошибок даже на стыке с каким-нибудь Qt.
Отдельного упоминания заслуживает тот факт, что на линуксе кодировка имен файлов Filesystem является вполне логичным UTF8, на виндовс-платформах — wchar. Что порождает целый класс неочевидных ошибок даже на стыке с каким-нибудь Qt.
Кхм кхм. wchar это юникод. Более того, это не кодировка, а тип данных, хранящий юникод-символ. Не путайте тёплое с мягким.
Для платформы Windows wchar_t это вполне себе «кодировка», а не просто хранилище двухбайтных символов. Потому что Windows трактует содержимое этих 32-битов однозначным (и не сильно портируемым) образом.
В стандарте по юникоду сказано буквально следующее:
«The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently, programs that need to be portable across any C or C++ compiler should not use wchar_t for storing Unicode text. The wchar_t type is intended for storing compiler-defined wide characters, which may be Unicode characters in some compilers.»
Я был бы очень рад, если бы boost::filesystem позволял абстрагироваться от платформы и использовать один тип данных как для *nix, так и для Windows платформ. Использовать кодировку UTF-8 (как Qt например), а конвертацию в платформозависимый вид поддерживать как опцию. Потому что на данный момент количество неудобств из-за несоответствия зашкаливает.
В стандарте по юникоду сказано буквально следующее:
«The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently, programs that need to be portable across any C or C++ compiler should not use wchar_t for storing Unicode text. The wchar_t type is intended for storing compiler-defined wide characters, which may be Unicode characters in some compilers.»
Я был бы очень рад, если бы boost::filesystem позволял абстрагироваться от платформы и использовать один тип данных как для *nix, так и для Windows платформ. Использовать кодировку UTF-8 (как Qt например), а конвертацию в платформозависимый вид поддерживать как опцию. Потому что на данный момент количество неудобств из-за несоответствия зашкаливает.
>> Потому что Windows трактует содержимое этих 32-битов
Но ведь wchar_t в компиляторе от MS всегда 16-ти битный.
И utf-8 не шибко удобно использоваться при плотной работе с WinAPI — это будет кошмар и ад постоянных переконвертаций. А модуль FS, я на так понимаю, будет постоянно дергать функции вроде FindFirstFile и т.д.
Но ведь wchar_t в компиляторе от MS всегда 16-ти битный.
И utf-8 не шибко удобно использоваться при плотной работе с WinAPI — это будет кошмар и ад постоянных переконвертаций. А модуль FS, я на так понимаю, будет постоянно дергать функции вроде FindFirstFile и т.д.
Sign up to leave a comment.
Обзор новых возможностей С++14: Часть 2