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

_>О да, написать "A a;" это конечно же намного сложнее, чем написать "A a=new A;". )

Дело ж не в записи, а в том, что в одном случае я обязан заранее знать где и сколько будет жить обект, а во втором я не забиваю себе голову и получаю тот же оезутьтат, если время жизни соответствует размещению на стеке.

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

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

Я уже отвечал на этот вопрос. Аналогия не верна.

Переписывать имеет смысл, только только то, что даст приемущество отгегерации кода во время компиляции и т.п.

Но это, по факту, не такое частое явление.

Ситуция с Ли в корне отличается. В Ди вынуждены переписывать библиотеки из–за сильного парадигмного и технического (отсутствие модульности в С, например) отличия.

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

EP>То есть то, что себе фантазируют эвагелисты GC — "О, вот тут ставлю ещё один new, GC — хороший, escape analysis — хороший. А вот на C++ была бы обязательно возня со smart-pointers, бррр." — не более чем фантазия или впитанные рекламные мантры

Конечно в С++ все иначе. Там тупо размещают объект на стеке передают указатель на него функции, а та сует его в поле.

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

EP>У не stop the world свой набор компромиссов, например размазывание тонким слоем по всему коду какой-нибудь конкурентной пакости.

Только перед кодом меняющим ссылки. Рефкаунтинг размазывает не меньше.

Здравствуйте, Mystic, Вы писали:
M>Поэтому у программиста C есть вьібор, где и как помещать.
Ну и у программиста С# тоже есть выбор, где и как размещать. См. напр. stackalloc.

Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Во-первых, совершенно не в тему — мы говорим про минимизацию ++/--ref_count, а не конвертацию аллокаций в куче в аллокации на стэке.
С точки зрения математики, вы решаете смежную задачу. EA определяет, передаётся ли ссылка за пределы контекста, а move analysis определяет, используется ли ссылка после передачи.

EP>Во-вторых, если уже говорить про escape analysis, то основной benefit который он даёт — в C++ это поведение по умолчанию
Основной бенефит EA — это type safety, которой в С++ нет и не предвидится.

EP>Там где он может гарантировать — он сам ставит move. А там где нет — его ставит пользователь.
EP>Более того, использовать объект после того как из него что-то move'нули вполне возможно.
А, ну круто. Это опять грабли на ровном месте: к моменту, когда управление попадёт в то место, которое обращается к передвинутому объекту, тот может быть уже мёртв.

EP>Во-первых, ты явно путаешь C++ и C.
Во-первых, нет. Покажите мне самую-самую С++ библиотеку для программирования под Windows, и я вас ткну в то место, где сидят ровно такие приведения.

EP>Во-вторых, речь шла про какие-то специфические задачи, для которых без GC ну ни как. Я говорю о том, что для таких задач можно использовать точный GC в виде отдельной кучи (и привёл пример такого GC), а не про точный GC который будет работать для всех сторонних библиотек автоматом.
Это всё будет работать на уровне соглашений. Никакого контроля за этим нет — ни за тем, чтобы в этой вашей куче не использовались union-ы или другие замаскированные указатели, ни за отсутствием ссылок на объекты в этой куче из не-GC кучи и наоборот.

EP>Каким образом? Весь вызывающий код зависел от достижения постусловий данным алгоритмом, так как он честно выполнил все предусловия. Но этого не случилось из-за бага — получаем неопределённое состояние.
Мы получаем вполне определённое состояние: вылет исключения. Есть стратегии детектирования таких состояний: catch-block.
Не всякий код выходит у нас exception-safe, но мы по крайней мере можем его таковым написать.
В С++ же обращение к разрушенному объекту невозможно надёжно задетектировать. От слова вообще.

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

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

_>>>О да, написать "A a;" это конечно же намного сложнее, чем написать "A a=new A;". )
S>>Вы мне лучше расскажите, что будет, если я потом напишу
S>>

S>>return &a;
S>>

EP>http://coliru.stacked-crooked.com/a/ce7861835399bf6d
EP>

EP>error: address of stack memory associated with local variable 'a' returned

EP>

S>>Вот только в дотнете для них же имеем ровно ту же реализацию.
S>>А как только вы выйдете за их пределы и начнёте работать хотя бы со строками, вот тут и начнётся веселуха — либо беспричинные копирования со штрафом O(N), либо шансы нарваться на обращение к уничтоженному объекту, либо рефкаунты. А escape analysis позволяет программисту не думать о том, какие строки у него временные, а какие — надолго.

EP>

EP>#include <string>
EP>using namespace std;

EP>string test()
EP>{
EP>    string x = "abc";
EP>    return x;
EP>}
EP>

Не тут, ни "штрафа O(N)", ни refcount
Давайте чуть усложним пример:

#include <string>
using namespace std;
string f(bool cond = false) {
  string first("first");
  string second("second");
  return cond ? first : second;
}

Ваш компилятор всё ещё сумеет RVO? Поздравляю, вы получаете штраф O(N) за вызов конструктора копирования. Если вы используете одну из типичных реализаций std::string, то при увеличении длины аргументов вы выйдете за порог SSO и получите refcount.

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


EP>Вообще говоря, тут мысль достаточно простая: там где в GC языках ставят "new", в 95%-99% случаях на C++ не будет никакого ref-counting и подобного, и это default style, причём это не только для памяти, а для всех ресурсов (с которыми в C# уже начинаются проблемы, которые не решаются полностью using-костылями).
Как и большинство простых мыслей, эта имеет весьма отдалённое отношение к реальности.

Здравствуйте, jazzer, Вы писали:
J>Вообще-то там явно руками был написан std::move(a). Куда уж definitee — ты его сам руками написал.
Я, если честно, не вполне понимаю, какой вопрос вы тут хотели задать.
На всякий случай отвечу на вопрос "а чего синклер ожидал от компилятора в таком очевидном случае, почему, и зачем":
1. Я ожидал, что компилятор выдаст ошибку типа "possible using of a location without initialization".
2. Потому, что у компилятора достаточно данных для того, чтобы выдать такую ошибку
3. Для того, чтобы я не проимел ссылку в чуть более интересных сценариях:

auto a = some::factory.CreateNew(42);
if (isPrime(rand(1000000))
  auto b = dealWithA(move(a));
cout << a.status(); // dead or alive?

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

EP>>Более того, использовать объект после того как из него что-то move'нули вполне возможно.
S>А, ну круто. Это опять грабли на ровном месте: к моменту, когда управление попадёт в то место, которое обращается к передвинутому объекту, тот может быть уже мёртв.
В смысле мёртв? Если мы муваем объект, то у нас остаётся "пустой" объект. Использовать его вполне корректно. С некоторыми ограничениями, но можно. Именно поэтому "possible using of a location without initialization" тут не катит. Ну да, выстрелить в ногу можно.

Здравствуйте, DarkEld3r, Вы писали:
DE>В смысле мёртв? Если мы муваем объект, то у нас остаётся "пустой" объект.
А что такое "пустой объект"? Я не помню такого термина в спецификации С++, по которой работал я (в своей пред-предыдущей жизни).

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

S>А что такое "пустой объект"? Я не помню такого термина в спецификации С++, по которой работал я (в своей пред-предыдущей жизни).
Если на пальцах, то как-то так:

string s("test"); // s = "test".
foo(move(s)); // Тут у нас "пустой обьект".

s = "new value"; // Присваиваем новое значение, всё корректно.
foo(move(s)); // Можем смувить ещё раз.

Естественно, в спецификации будут несколько другие термины. Ну и после перемещения безопасно можно выполнять только некоторые действия (они перечислены, естественно). Скажем, размер, скорее всего, не будет обнуляться — для эффективности. То есть вот так нельзя:

foo(move(s)); 
if(s.size() > 1)
  s[0] = 'a';

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

EP>>То есть то, что себе фантазируют эвагелисты GC — "О, вот тут ставлю ещё один new, GC — хороший, escape analysis — хороший. А вот на C++ была бы обязательно возня со smart-pointers, бррр." — не более чем фантазия или впитанные рекламные мантры
VD>Конечно в С++ все иначе. Там тупо размещают объект на стене передают указатель на него функции, а та сует его в поле.

	Или там лямбда захватывает
	using System; using System.IO; public class Test { public delegate void fireworks(); public static fireworks make_closure(FileStream fs) { return () => fs.Read(new byte[10], 0, 10); } public static fireworks fire() { using (var fs = File.Open("file", FileMode.Open)) { return make_closure(fs); } } public static void Main() { fire()(); } }

А вообще, у тебя аргументация какая-то казуистическая
Я говорю что в 95%-99% достаточно scope-based, ты типа как контраргумент приводишь случай из оставшегося 1%.
Да, в некоторых случаях недостаточно, и об этом выше я ни раз сам говорил. Что, тем не менее, никак не опровергает этот тезис

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

EP>>У не stop the world свой набор компромиссов, например размазывание тонким слоем по всему коду какой-нибудь конкурентной пакости.
VD>Только перед кодом меняющим ссылки. Реыкаунтинг размазывает не меньше.

Для refcounting (который нужен не всегда) происходит атомарный wait-free inc при копировании ссылки, и атомарный wait-free dec при выходе ссылки из scope.

В том же C4, на который вы тут не раз ссылались, манипуляции происходят при каждой загрузке указателя (и не только), плюс конкурентная пакость в отдельных потоках. Причём в нём всё равно есть stop-the-world, по крайней мере в реализации описанной в статье

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

EP>>Во-первых, совершенно не в тему — мы говорим про минимизацию ++/--ref_count, а не конвертацию аллокаций в куче в аллокации на стэке.
S>С точки зрения математики, вы решаете смежную задачу. EA определяет, передаётся ли ссылка за пределы контекста, а move analysis определяет, используется ли ссылка после передачи.

Вот видишь, сам понимаешь, что хоть какие-то схожие черты есть, но задача-то другая, и решения у неё другие.

EP>>Во-вторых, если уже говорить про escape analysis, то основной benefit который он даёт — в C++ это поведение по умолчанию
S>Основной бенефит EA — это type safety, которой в С++ нет и не предвидится.

Непонятно что именно даёт здесь EA для type safety, которая и так была

EP>>Там где он может гарантировать — он сам ставит move. А там где нет — его ставит пользователь.
EP>>Более того, использовать объект после того как из него что-то move'нули вполне возможно.
S>А, ну круто. Это опять грабли на ровном месте: к моменту, когда управление попадёт в то место, которое обращается к передвинутому объекту, тот может быть уже мёртв.

Не мёртв, а пуст
Это считай своего рода swap с пустым объектом.

EP>>Во-первых, ты явно путаешь C++ и C.
S>Во-первых, нет. Покажите мне самую-самую С++ библиотеку для программирования под Windows,

Что такое "программирование под Windows"
Ок, например std::thread — в одной из реализаций внутри, там в том числе и "программирование под Windows"

S>и я вас ткну в то место, где сидят ровно такие приведения.

Внутри реализации или интерфейса?

EP>>Во-вторых, речь шла про какие-то специфические задачи, для которых без GC ну ни как. Я говорю о том, что для таких задач можно использовать точный GC в виде отдельной кучи (и привёл пример такого GC), а не про точный GC который будет работать для всех сторонних библиотек автоматом.
S>Это всё будет работать на уровне соглашений. Никакого контроля за этим нет — ни за тем, чтобы в этой вашей куче не использовались union-ы или другие замаскированные указатели, ни за отсутствием ссылок на объекты в этой куче из не-GC кучи и наоборот.

Без внешних утилит/верификаторов — да, только соглашения. Об ограничениях я говорил с самого начала, к чему капитанство — непонято.
Повторяю в N'ый раз — эта техника подходит для затейливых задач, типа сложных графов, в которых без GC ну ни как.

EP>>Каким образом? Весь вызывающий код зависел от достижения постусловий данным алгоритмом, так как он честно выполнил все предусловия. Но этого не случилось из-за бага — получаем неопределённое состояние.
S>Мы получаем вполне определённое состояние: вылет исключения. Есть стратегии детектирования таких состояний: catch-block.
S>Не всякий код выходит у нас exception-safe, но мы по крайней мере можем его таковым написать.

Это вообще всё ортогонально. Невыполнение post-condition, при удовлетворённых pre-condition — это баг.
Да, некоторые нарушения можно поймать, и даже отрапортовать исключением или ещё как-нибудь, но это никак не снимает того факта, что post-condition не достигнут, хотя должен был быть.
В программе баг, и никаким defensive programming ты его не обойдёшь. Всё что возможно, это только немного облегчить последствия, да и то не во всех случаях.

S>В С++ же обращение к разрушенному объекту невозможно надёжно задетектировать. От слова вообще.

Отчего же "от слова вообще"? Вот самый примитивный способ — клади каждый объект в отдельную виртуальную страницу. Или, например, используй инструментацию кода

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

EP>>Вообще говоря, тут мысль достаточно простая: там где в GC языках ставят "new", в 95%-99% случаях на C++ не будет никакого ref-counting и подобного, и это default style, причём это не только для памяти, а для всех ресурсов (с которыми в C# уже начинаются проблемы, которые не решаются полностью using-костылями).
S>Как и большинство простых мыслей, эта имеет весьма отдалённое отношение к реальности.

Тогда расскажи нам, использующим C++ регулярно (а также и языки с GC), как же на самом деле у нас обстоят дела в C++.

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

S>Отличная грабля. И это в то время, когда передовики производства совершенствуют средства обнаружения lack of definite assignment, у нас С++ неспособен отрепортить definite lack of assignment?

А с чего компилятор должен ругаться то? Никакой ошибки (в смысле падения и т.п.) при данном коде не произойдёт. Да, во вторую функцию не пойдут данные, но мы же самих переместили их в другое место в коде чуть выше. Т.е. твоя претензия тут аналогична такому:

vector<int> x={1, 2, 3};
x.clear();
f(x);//ой, а почему компилятор не предупредил меня, что я выше clear вызывал???

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

STD>Кроме того, есть синтаксический аналог async/await https://github.com/rsdn/nemerle/tree/master/snippets/Nemerle.Async
STD>И как писали выше, есть https://github.com/rsdn/nemerle/wiki/Computation-Expression-macro на которых реализуется 1 в 1 вычислитель над тасками, как в F# (https://github.com/fsprojects/fsharpx/blob/master/src/FSharpx.Core/ComputationExpressions/Monad.fs#L994).
STD>С точки зрения эффективности генерируемого кода этот вариант проигрывает async/await, но по удобству впереди. Потому что если необходимо работать с отменой задачи или опциями продолжений, то весь async/await сахарок идет лесом, да еще эти параметры тащить руками через все вычисление.
STD>

STD> type TaskBuilder(?continuationOptions, ?scheduler, ?cancellationToken) =
STD>

STD>А на ComputationExpressions автоматически без лишних телодвижений.

Ага, понятно. Т.е. всё же компилятор Nemerle не может компилировать современный C# код (существенное отличие от ситуации C->C++). Но при этом этот код можно переписать так, чтобы всё заработало.

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

_>А с чего компилятор должен ругаться то? Никакой ошибки (в смысле падения и т.п.) при данном коде не произойдёт. Да, во вторую функцию не пойдут данные, но мы же самих переместили их в другое место в коде чуть выше.

Я не мега-спец в C++, хочу узнать — что значит "не пойдут данные"? Если данные — это указатель, что туда "пойдет", NULL? А если int, то 0?

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

_>Ага, понятно. Т.е. всё же компилятор Nemerle не может компилировать современный C# код (существенное отличие от ситуации C->C++).
Nemerle — другой язык, в котором доступный идиомы из C# и даже больше. https://sites.google.com/site/gibekm/programming/nemerle/asyncawait

_> Но при этом этот код можно переписать так, чтобы всё заработало.
Это называется "переписать на Nemerle".