Здравствуйте, so5team, Вы писали:

S>Здравствуйте, AlexRK, Вы писали:
guide[/url]). А запрет на использование исключений означает, что программист не может написать вот такой простой код:
S>

class demo {
S>  const string a_;
S>  const string b_;
S>public:
S>  demo(const char * a, const char * b) : a_(a), b_(b) {}
S>  ...
S>};

Эт почему? Можно первой строчкой конструктора проверить, что обе переменные инициализировались.

Здравствуйте, so5team, Вы писали:

S>Что, понятное дело, самым негативным образом сказывается на объеме, качестве и надежности C++ного кода. А теперь вопрос: запрещены ли panic-и в новом Rust-овом коде в Firefox-е?

Как можно трогать священную коровуRust

https://github.com/servo/servo/search?l=Rust&q=%22panic%21%22&type=&utf8=%E2%9C%93

Здравствуйте, T4r4sB, Вы писали:

TB>Эт почему? Можно первой строчкой конструктора проверить, что обе переменные инициализировались.

И что делать, при обнаружении ошибки?

Здравствуйте, AlexRK, Вы писали:

ARK>Я ничего не писал ни про какой пайтон, ни про аллокацию.

Да это не вы. Но вы ответили на мой ответ этому человеку и привели ни к селу, ни к городу пример с растом и мозиллой.

ARK>Конкурентное программирование — одна из областей, где раст получает значительные преимущества над Ц++, за счет уникальных ссылок по умолчанию, семантики перемещения по умолчанию, и помеченных явным образом разделяемых ссылок. И всё это проверяется компилятором.

Над си, в с++ всё это есть, частью в языке, частью в стандартной библиотеке. Может быть программистам нужно учиться грамотно использовать С++.

ARK>Я просто привёл пример, что далеко не всё ладно в датском королевстве.

Тогда у меня вопрос, почему гугл смог в С++, а мозилла не осилили? Может дело не в средствах языка.

И ещё один вопрос, какое отношение к метапрограммированию на С++ имеет раст и управление памятью?

Здравствуйте, rg45, Вы писали:

R>Здравствуйте, T4r4sB, Вы писали:

TB>>Эт почему? Можно первой строчкой конструктора проверить, что обе переменные инициализировались.

R>И что делать, при обнаружении ошибки?

Записывать фолс в поле инитед самого объекта и пропускать дальнейшую инициализацию.

Здравствуйте, T4r4sB, Вы писали:

TB>Записывать фолс в поле инитед самого объекта и пропускать дальнейшую инициализацию.

Ну то есть, с этого момента, становится возможным существование невалидных объеков и вся остальная программа обязана будет проверять валидность таких объектов, так? А если кто-нибудь программистов забудет сделать такую проверку, то вся остальная группа, в скором времени будет искать эту ошибку всему коду. Ну проходили ведь это все уже.

Здравствуйте, YuriV, Вы писали:

ARK>>Конкурентное программирование — одна из областей, где раст получает значительные преимущества над Ц++, за счет уникальных ссылок по умолчанию, семантики перемещения по умолчанию, и помеченных явным образом разделяемых ссылок. И всё это проверяется компилятором.
YV>Над си, в с++ всё это есть, частью в языке, частью в стандартной библиотеке. Может быть программистам нужно учиться грамотно использовать С++.

В С++ это есть, но нет никаких гарантий от компилятора. Это принципиальный момент. Важно не только то, что есть, но и то, чего нет.

YV>Тогда у меня вопрос, почему гугл смог в С++, а мозилла не осилили? Может дело не в средствах языка.

Ну, раз один смог, а другой нет (хотя и другой совсем не дурак), то, наверное, инструмент не самый простой и/или не самый удобный и/или не самый лучший. Или есть иные варианты?

YV>И ещё один вопрос, какое отношение к метапрограммированию на С++ имеет раст и управление памятью?

Никакого, но вы же сами поддержали разговор про управление памятью.

Здравствуйте, T4r4sB, Вы писали:

TB>Эт почему? Можно первой строчкой конструктора проверить, что обе переменные инициализировались.

Это будет означать, что:

1. В каждом объекте нам придется хранить либо bool is_initialized_, либо error_code initialization_code_.

2. Перед началом использования любого объекта нужно будет дергать либо is_initialized(), либо initialization_code, либо какой-то другой метод.

3. Возможно, для большей надежности придется в каждом публичном методе делать внутреннюю проверку того, что идет обращение к корректно инициализированному объекту.

Все это, естественно, обойдется не бесплатно (как по памяти, так и по времени работы). И, плюс к тому, все равно оставляет пространство для ошибок.

Гораздо лучше было бы использовать подход с конструирующими методами, возвращающими какой-нибудь either<object, error_code>:

class demo {
  ...
public:
  static either<demo, error_code> make(const char * a, const char * b) {
    either<some_string_class, error_code> a_obj = some_string_class::make(a);
    if(a_obj) {
      either<some_string_class, error_code> b_obj = some_string_class::make(b);
      if(b_obj) {
        demo d_obj(*a_obj, *b_obj);
        return either<demo, error_code>(d_obj);
      }
      else
        return either<demo, error_code>(b_obj.error());
    }
    else
      return either<demo, error_code>(a_obj.error());
  }
  ...
};

Но:

a) код Firefox-а изначально должен был быть написан в таком ключе. А это не так. Кроме того, емнип, во времена C++98 в Mozilla шаблоны были если не под запретом, то под очень жесткими ограничениями.

b) использовать такой подход в C++ по-настоящему удобно стало только с пришествием C++11/14. Но в Mozilla в это время предпочли делать ставку на Rust.

Здравствуйте, AlexRK, Вы писали:

ARK>Конкурентное программирование — одна из областей, где раст получает значительные преимущества над Ц++, за счет уникальных ссылок по умолчанию, семантики перемещения по умолчанию, и помеченных явным образом разделяемых ссылок. И всё это проверяется компилятором.

Это красиво выглядит на словах и на игрушечных примерах, вроде создания объекта, внутренности которого защищены mutex-ом. А вот "значительность" преимуществ на каких-то более сложных сценариях конкурентности... Вот это где-нибудь наглядно продемонстрировано?

Здравствуйте, so5team, Вы писали:

ARK>>Конкурентное программирование — одна из областей, где раст получает значительные преимущества над Ц++, за счет уникальных ссылок по умолчанию, семантики перемещения по умолчанию, и помеченных явным образом разделяемых ссылок. И всё это проверяется компилятором.

S>Это красиво выглядит на словах и на игрушечных примерах, вроде создания объекта, внутренности которого защищены mutex-ом. А вот "значительность" преимуществ на каких-то более сложных сценариях конкурентности... Вот это где-нибудь наглядно продемонстрировано?

Ну, на деле мне известно пока только про css-движок квантума: https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum.html
Вкупе с утверждением мозиллы, что большую роль в успехе сыграл именно раст (насколько это правда, конечно, неизвестно).

Здравствуйте, AlexRK, Вы писали:

ARK>В С++ это есть, но нет никаких гарантий от компилятора. Это принципиальный момент. Важно не только то, что есть, но и то, чего нет.

Ну посмотрим во что выльется transactional memory в плюсах.

ARK>Ну, раз один смог, а другой нет (хотя и другой совсем не дурак), то, наверное, инструмент не самый простой и/или не самый удобный и/или не самый лучший. Или есть иные варианты?

Компетентность и профессионализм, неа? ИМХО, мозилла пытается выехать на модной тенденции, но язык сыроват для промышленного использования.

ARK>Никакого, но вы же сами поддержали разговор про управление памятью.

Ну тогда завязываем, а то мы скоро перейдём к С vs С++, С++ vs Java, dynamic vs static typing, etc, уже были в топике от одного товарища (не от Вас) поползновения.

Здравствуйте, AlexRK, Вы писали:

ARK>в успехе сыграл именно раст (насколько это правда, конечно, неизвестно.

Да по большому счету хрен с ним, что там мозилла говорит.
Давай вернемся к теме. Шаблоны-то в расте есть? Задачку rg45 решить можно? А то анекдот про Шустрого Гонзалеза вспоминается

Здравствуйте, dead0k, Вы писали:

D>Шаблоны-то в расте есть?

Есть, Turing-complete.

D>Задачку rg45 решить можно?

Думаю, что можно, но я не готов это щас написать.

Здравствуйте, AlexRK, Вы писали:

D>>Задачку rg45 решить можно?

ARK>Думаю, что можно, но я не готов это щас написать.

У меня только просьба к тебе: если, все-таки найдешь время, вернись, пожалуйста, к оригинальной задаче: http://rsdn.org/forum/cpp/7063448.1

Автор: rg45
Дата: 24.02.18

. Тебе же проще будет — здесь не требуются операции с матрицами и посчитать-то нужно всего одно число — скалярное произведение двух векторов. Изюминка — автоматическое получение правильного типа результата. Если что нужно уточнить — спрашивай.

Здравствуйте, Pzz, Вы писали:

_>>Это безусловно верно. Только вот какое это всё имеет отношение к изначальному тезису о частой аллокации мелких объектов в C++?
Pzz>Потому, что это одна из типичных проблем производительности C++'ных програм.

С учётом того, что ты так и не смог (подозреваю что и никто не смог бы) назвать язык в котором не будет этой самой частой аллокации при решение той же задачи, то видимо правильная формулировка твоего тезиса должна выглядеть так: "одной из проблем с производительностью программ (на любых языках) является частая аллокация мелких объектов".

Более того, можно отдельно отметить, что в C++ дела с этим обстоят намного лучше, чем в других языках. Ты можешь это тривиально проверить, просто сравнив сколько будет выделений памяти для такого простейшего C++ кода:

class A{
    string data;
};
class B{
    A a;
};
B b;

И сколько их будет в аналоге этого кода скажем на Java/C#.

Pzz>>>Что до питона, я полагаю, что он вовсе не будет эти строки освобождать, если только с памятью не совсем плохо.
_>>Т.е. теперь речь уже оказывает не о стратегии выделения памяти, а о стратегии её освобождения? )))
Pzz>Это все вместе называется стратегией управления памятью.

Да, но описываемая тобой проблема с производительностью является как раз следствием неподходящего задаче освобождения памяти, а не выделения. И как раз именно эта проблема (в тех случаях, когда оно действительно становится бутылочным горлышком, а не просто из принципа) отлично решается с помощью выделения памяти на пуле.

Pzz>>>Ну именно это ведь сложно, а не слово delete написать
_>>Но без этого умения в подобные языки лучше вообще не соваться...
Pzz>А с этим умением проще писать такие вещи на чистом Си — там, по крайней мере, на 100% знаешь, что на самом деле происходит.

В руках профессионала и C и C++ выдадут одинаковый по эффективности результат. Но при этом объём исходников на C будет существенно выше, а их проверяемость компилятором существенно ниже.

_>>Эээ что? ) А третий параметр шаблона (кстати ещё один штрих к дискуссии об излишней универсальности) здесь http://en.cppreference.com/w/cpp/string/basic_string по твоему для чего существует? )))
Pzz>А если "сделай сам", то к чему мне и этот дивный пул, и std::string?

Эээ что? Какое ещё "сделай сам"? Мы берём (готовый) аллокатор на пуле и передаём его в качестве шаблонного параметра в стандартную (естественно опять же готовую) строку из STL. В итоге мгновенно получаем обычный std::string, но выделяющий память на пуле. Это же основа работы STL. Ты что, реально про это не в курсе? )))

Здравствуйте, alex_public, Вы писали:


_>Более того, можно отдельно отметить, что в C++ дела с этим обстоят намного лучше, чем в других языках. Ты можешь это тривиально проверить, просто сравнив сколько будет выделений памяти для такого простейшего C++ кода:
_>

_>class A{
_>    string data;
_>};
_>class B{
_>    A a;
_>};
_>B b;
_>

_>И сколько их будет в аналоге этого кода скажем на Java/C#.
Ровно столько же как и для нетовских структур. Но вот есль тебе нужно разместить не на стеке, оно будет таким же как и для других языков

Здравствуйте, YuriV, Вы писали:

YV>ЗЫ: всё это мозилла сделала в попытке догнать по скорости хром, который написан на плюсах и давным давно "распаралелен" как вы выражаетесь. Так может в мозилле не умеют готовить С++.

Вообще то в последние годы FF обгоняет по быстродействию Хром. Правда к Rust это никакого отношения не имеет... )

Здравствуйте, YuriV, Вы писали:

YV>Раст это замена си, а не с++. Идея раста понятна и вменяема. Отслеживание лайфтайма и борроуинг действительно позволяют статически проверить работу с памятью. Пока что этот язык находиться на волне хайпа, типа "стильно, модно, молодёжно", а дальше видно будет. Но в любом случае это не замена С++ даже близко.

Вообще то как раз замена и C и C++. Потому как все основные преимущества C++ там имеются и даже ещё более усиленные.

Пожалуй основной его недостаток (помимо молодости и следующей из этого неразвитой инфраструктуры) в том, что на нём тупо трудно писать код. Причём трудно не из-за требований работы мозга (как бывает у некоторых с C++), а из-за необходимости написания большого количества синтаксического мусора. Понятно, что это всё пишется ради большей безопасности, но вот в текущей реализации оно просто не комфортно.

Здравствуйте, dead0k, Вы писали:

D>Да по большому счету хрен с ним, что там мозилла говорит.
D>Давай вернемся к теме. Шаблоны-то в расте есть? Задачку rg45 решить можно? А то анекдот про Шустрого Гонзалеза вспоминается

В Rust'е есть полноценные синтаксические макросы, так что метапрограммирование там гораздо более сильное, чем в C++. Т.е. все задачи из области МП, решаемые на C++ запишутся и на Rust'е, причём чаще всего более лаконично.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, YuriV, Вы писали:

YV>>Раст это замена си, а не с++. Идея раста понятна и вменяема. Отслеживание лайфтайма и борроуинг действительно позволяют статически проверить работу с памятью. Пока что этот язык находиться на волне хайпа, типа "стильно, модно, молодёжно", а дальше видно будет. Но в любом случае это не замена С++ даже близко.

_>Вообще то как раз замена и C и C++. Потому как все основные преимущества C++ там имеются и даже ещё более усиленные.

_>Пожалуй основной его недостаток (помимо молодости и следующей из этого неразвитой инфраструктуры) в том, что на нём тупо трудно писать код. Причём трудно не из-за требований работы мозга (как бывает у некоторых с C++), а из-за необходимости написания большого количества синтаксического мусора. Понятно, что это всё пишется ради большей безопасности, но вот в текущей реализации оно просто не комфортно.

Не согласен, на данный момент это набор костылей: дроп вместо деструкторов (RAII), макросы это встроенный в компилятор препроцессор, лучше чем в С/С++ не спорю, но это средство генерации кода, никаким вычислением типов в компайл-тайм там и не пахнет. Создать список типов аля

typelist<> tl{}; 

struct type1 {}; 
tl.insert<type1>(); 
struct type2 {}; 
tl.insert<type2>(); 
... 
struct typeN {}; 
tl.insert<typeN>(); 

<tl now has type tl<type1, type2, ..., typeN> use it>

в компайл-тайм также не возможно как и в С++ (только препроцессором c __COUNTER__ или компайл-тайм генератором псевдослучайных чисел). А синтаксис — да, ужасен. Так что ему до С нужно дотянуться по эффективности использования сначала, а о С++ только мечтать пока. А там глядишь и концепции, и рефлекшн, и модули, и транзакционная память в плюсы подтянутся Всё это моё ИМХО.