Re[65]: Nemerle через 5 лет - выстрелит или скончается?
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 23.10.14 07:59
Оценка: +2
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>В C++ можно выделить подмножество (и даже сделать верификатор, для проверки соответствия), в котором будет и type safety, и "stack life cycle", и не будет EA
Да. Для этого придётся всего лишь отказаться от указателей.

EP>Для простоты считай default constructed.

А если дефолтного конструктора нету?

EP>С чего это вдруг "программирование под Windows" это обязательно GUI?

Это я вам объяснил моё определение задачи, библиотеку для которой я ищу.
Но если вы так хотите выкрутиться, отказавшись от GUI, то я вам и в невизуальной части найду волшебные структуры данных, в которых невозможно статически определить наличие либо отсутствие указателей.
EP>Да взять хоть тот же QT.

EP>Не пойму что ты пытаешься сказать — внутри реализаций .NET библиотек, использующих те или иные функции OS — будут те же самые lParam

это будут не те же самые lParam. Внутри реализаций .Net библиотек данные живут в управляемом виде, а перевод в/из lParam происходит только в момент маршалинга. Благодаря этому мы уверены, что в момент сборки мусора у нас не может быть неизвестного нам указателя на managed объект.
В С++ это теоретически возможно, но на практике бы означало отказ от тех самых преимуществ "тонкой прослойки", т.е. С++-ные библиотеки стараются использовать raw data напрямую, без постоянной конвертации туда-сюда.

Это и есть основной show stopper для внедрения точного GC в C++ — это возможно, пока вы работаете в рамках hello world. Как только мы пытаемся задействовать стандартные библиотеки — сразу начинается упс, связанный с реинтерпретацией данных, и точный GC становится невозможен.

EP>Речь шла про задачи, в которых в силу их структуры возникают жёсткие циклы, с которыми ref_counting/weak_ptr не справится.

Речь также шла про задачи, в которых стоимость ref_counting слишком велика. По сравнению с GC и immutable objects.

EP>Разговора о том, чтобы использовать GC для всего приложения — не было.

Разговор о том, что у вас нет никакой гарантии, что "GC использован только для части приложения", из-за потенциальной возможности прикопать указатель где угодно.

EP>По-хорошему, нужно и минимизировать баги, и их последствия. В разных приложениях естественно нужен разный баланс.

Совершенно верно. Юмор в том, что С++ не позволяет ни того, ни другого.

EP>В целом же, я предпочитаю акцент на минимизации багов, чем на defensive programming. В общем случае, defensive programming применим только к некоторым классам проблем, и уж тем более никак не сможет заставить программу с багом выполнить свою задачу. От создания корректного кода никуда не деться.

Речь не о defensive programming, а об UB vs FailFast. Ещё раз подчеркну: в нормальной среде о том, что произошла ошибка доступа к разрушенному объекту
1. вы узнаете (а не получите случайную наведённую ошибку где-то в совершенно постороннем коде)
2. узнаете не из рукопашных проверок постусловий в стиле defensive programming, а из вылета соответствующего исключения.

В С++, по факту, вы вообще не узнаете о подобной ошибке. У вас с вероятностью 99% стрельнет какой-то совершенно другой код — типа окажется, что в поле m_length записано -42. Потому, что поле читается из мусора, а не из реального объекта.

EP>Это всего лишь синтетический пример, показывающий что твоя оценка "от слова вообще" слишком категоричная.

Этот синтетический пример означает выход за пределы стандарта С++. Я не спорю — можно разработать другой язык, с другими правилами, и с другими стандартными библиотеками.
Но по факту мы работаем с реальным C++, а не с его воображаемым аналогом, только без шлюх и блэкджека.
EP>Естественно речь была про x64.
И даже на x64 вряд ли можно себе позволить неконтролируемый рост адресного пространства процесса.

EP>Например: у объекта, и всех указателей на него, сделать shared state в виде флага is_alive.

И как мы это сделаем для указателей, которые вычисляются при помощи арифметики?
И как мы обновим флаг во всех указателях в момент выполнения delete? Предполагается, что в объекте будет сидеть список backreferences на все указатели на него?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[58]: Nemerle через 5 лет - выстрелит или скончается?
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 23.10.14 08:14
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>С чего это вдруг O(N)?

EP>Вот например swap двух строк, это какая сложность по-твоему?
В зависимости от того, попали ли мы в SSO — либо о(N), либо o(1) + затраты на перещёлкивание ref_count.
Или у нас есть какая-то магия компилятора, которая отличает swap от s3=s1; s1=s2; s2=s3 для произвольных типов?


EP>Проще всего вот так:

EP>
EP>string f(bool cond = false)
EP>{
EP>    string first("first");
EP>    string second("second");
EP>    if(cond)
EP>        return first;
EP>    else
EP>        return second;
EP>}
EP>

И благодаря чему здесь компилятор ухитрится соптимизировать move? Вот у меня банальный код вызова:
void test()
{
  string s("test"); // байты для 't','e','s','t','\0' хранятся в stack frame этой функции благодаря SSO
  s = f(true);
  cout << s; // здесь в SSO-области s уже лежат байты 'f','i','r','s','t','\0'. Каким образом они тут оказались?
}
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[58]: Nemerle через 5 лет - выстрелит или скончается?
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 23.10.14 08:26
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>То есть мы копируем все необходимые внутренности(в данном случае это один указатель), и "зануляем" внутренности донора таким образом, что бы для него смог корректно отработать его деструктор.

Это всё здорово, но вы не привели copy-constructor.
При такой реализации в нём вам придётся делать std::memmove() на полные данные, т.к. скопировать указатель уже нельзя — деструктор одного из клонов вернёт буфер в хип, и первое же обращение ко второму клону получит UB.
Чтобы оптимизировать копирования, вам придётся перейти на COW-оптимизацию, а в ней уже нарваться на штраф за interlocked_increment рефкаунтера.

S>>Можно посмотреть код move-конструктора для std::string?


EP>https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00998_source.html#l00512


Отлично.
Можете сразу сделать Ctrl-F по "_M_refcount" чтобы найти места, где вас ждёт обещанный мной штраф за refcount.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[59]: Nemerle через 5 лет - выстрелит или скончается?
От: alex_public  
Дата: 23.10.14 08:42
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>В зависимости от того, попали ли мы в SSO — либо о(N), либо o(1) + затраты на перещёлкивание ref_count.

S>Или у нас есть какая-то магия компилятора, которая отличает swap от s3=s1; s1=s2; s2=s3 для произвольных типов?

В текущей версии string нет SSO, но есть подсчёт ссылок. )

В будущей версии string (можно пользоваться уже сейчас под таким именем https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a01594_source.html) есть SSO, но нет подсчёта ссылок. )
Re[59]: Nemerle через 5 лет - выстрелит или скончается?
От: DarkEld3r  
Дата: 23.10.14 08:42
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>При такой реализации в нём вам придётся делать std::memmove() на полные данные, т.к. скопировать указатель уже нельзя — деструктор одного из клонов вернёт буфер в хип, и первое же обращение ко второму клону получит UB.

Ну да, копирование — дорогая операция. И что?

S>Чтобы оптимизировать копирования, вам придётся перейти на COW-оптимизацию, а в ней уже нарваться на штраф за interlocked_increment рефкаунтера.

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

S>Можете сразу сделать Ctrl-F по "_M_refcount" чтобы найти места, где вас ждёт обещанный мной штраф за refcount.

Особенность реализации. Который может (и не должно) и не быть.
Re[58]: Nemerle через 5 лет - выстрелит или скончается?
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 23.10.14 08:49
Оценка:
Здравствуйте, alex_public, Вы писали:

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


S>>Сдаётся мне, что таки будут копирования. Можно посмотреть код move-конструктора для std::string?

_>
_>      /**
_>       *  @brief  Move construct string.
_>       *  @param  __str  Source string.
_>       *
_>       *  The newly-created string contains the exact contents of @a __str.
_>       *  @a __str is a valid, but unspecified string.
_>       **/
_>      basic_string(basic_string&& __str)
_>      : _M_dataplus(__str._M_dataplus)
_>      {
_>        __str._M_data(_S_construct(size_type(), _CharT(), get_allocator()));
_>      }
_>

Отлично. То есть вы ссылаетесь на реализацию GCC, в которой нет SSO. зато есть refcount.
Понятно, что в вырожденных сценариях типа "передачи владения" есть шанс обойтись без копирований и рефкаунтов.
Речь о том, что в классическом, банальном
string s("hello");
f1(s); // мы получаем copy constructor со штрафом за рефкаунт
f2(s);
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[54]: Nemerle через 5 лет - выстрелит или скончается?
От: ionoy Эстония www.ammyui.com
Дата: 23.10.14 09:05
Оценка:
Здравствуйте, alex_public, Вы писали:

_>А во-вторых в чём проблема знать где и сколько будет жить объект? )


Большинство современного GUI софта написано в асинхронном стиле. Объекты там создаются, скачут между контекстами, а потом, когда все подписчики отработают, подлежат уничтожению. Вручную искать момент завершения работы с объектом значит очень сильно переусложнить код. Никакого скоупа там нет.
www.livexaml.com
www.ammyui.com
www.nemerleweb.com
Re[47]: Nemerle через 5 лет - выстрелит или скончается?
От: ionoy Эстония www.ammyui.com
Дата: 23.10.14 09:18
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Кстати, если говорить о производительности и безопасности вместе и о .net в системном программирование... Есть вот такая http://habrahabr.ru/post/208608/ любопытная информация. Не знаю дадут ли этому когда-нибудь ход. Но если дадут, то я обязательно попробую. )


_>Но в любом случае там есть ряд довольно интересных фраз, особенно про переход на C++ в будущем. )))


Как можно всеръёз воспринимать статью, которая в первых строчках показывает javascript как образец safety and productivity?

Не, я понимаю, яваскрипт реально удобная штука. Мне вот пару дней назад надо было из массива точек отобразить рисунок. На всё про всё ушло минуты, наверное две. В текстовом редакторе подставил перед каждой точкой lineTo, потом это дело скопировал в jsfiddle и отобразил на canvas. Удобно? Очень.

Но как только от маленькой задачи мы начинаем двигаться к большой, так сразу начинаются проблемы с поддержкой, скоростью разработки, качеством IDE и тд. В крупных проектах javascript и небезопасен, и непродуктивен. Большинство современных языков справляются с его задачами значительно лучше. Его преимущество только в абсолютной распространённости и кроссплатформенности благодаря браузерам.
www.livexaml.com
www.ammyui.com
www.nemerleweb.com
Re[66]: Nemerle через 5 лет - выстрелит или скончается?
От: Evgeny.Panasyuk Россия  
Дата: 23.10.14 09:29
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

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

S>>>EA — это способ получить stack life cycle для объектов без потери type safety.
S>>>С++ гордится тем, что у него есть stack life cycle, но при этом в нём нет type safety.
EP>>В C++ можно выделить подмножество (и даже сделать верификатор, для проверки соответствия), в котором будет и type safety, и "stack life cycle", и не будет EA
S>Да. Для этого придётся всего лишь отказаться от указателей.

Во-первых, только в пользовательских типах (std::vector можно считать частью платформы, также как и в .NET есть unsafe код).
Во-вторых, совершенно без разницы. Я показываю, что EA тут не даёт никакой type safety. Эта type safety в управляемых языках есть и без EA, а в C++ возможна без EA.

EP>>Для простоты считай default constructed.

S>А если дефолтного конструктора нету?

Я же сказал, для простоты. А в общем случае достаточно перевести в destructable состояние (то есть такое, для которого может корректно отработать деструктор).

S>Но если вы так хотите выкрутиться, отказавшись от GUI, то я вам и в невизуальной части найду волшебные структуры данных, в которых невозможно статически определить наличие либо отсутствие указателей.


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

EP>>Не пойму что ты пытаешься сказать — внутри реализаций .NET библиотек, использующих те или иные функции OS — будут те же самые lParam

S>это будут не те же самые lParam. Внутри реализаций .Net библиотек данные живут в управляемом виде, а перевод в/из lParam происходит только в момент маршалинга. Благодаря этому мы уверены, что в момент сборки мусора у нас не может быть неизвестного нам указателя на managed объект.

И, конечно же, никаких fixed и unsafe там быть не может, да?

S>В С++ это теоретически возможно, но на практике бы означало отказ от тех самых преимуществ "тонкой прослойки", т.е. С++-ные библиотеки стараются использовать raw data напрямую, без постоянной конвертации туда-сюда.

S>Это и есть основной show stopper для внедрения точного GC в C++ — это возможно, пока вы работаете в рамках hello world. Как только мы пытаемся задействовать стандартные библиотеки — сразу начинается упс, связанный с реинтерпретацией данных, и точный GC становится невозможен.

Очевидные вещи говоришь, которые к тому же уже обсуждались выше. Зачем?

EP>>Разговора о том, чтобы использовать GC для всего приложения — не было.

S>Разговор о том, что у вас нет никакой гарантии, что "GC использован только для части приложения", из-за потенциальной возможности прикопать указатель где угодно.

Теоретически.
А практически, для таких сценариев и при необходимости гарантий (например при невозможности достижения их одними guidelines) — можно запретить брать raw указатели на такие GC объекты — частично языком + простейшим внешним верификатором.

EP>>По-хорошему, нужно и минимизировать баги, и их последствия. В разных приложениях естественно нужен разный баланс.

S>Совершенно верно. Юмор в том, что С++ не позволяет ни того, ни другого.

А кто тогда позволяет? ObjectDisposed и OutOfBounds?

EP>>В целом же, я предпочитаю акцент на минимизации багов, чем на defensive programming. В общем случае, defensive programming применим только к некоторым классам проблем, и уж тем более никак не сможет заставить программу с багом выполнить свою задачу. От создания корректного кода никуда не деться.

S>Речь не о defensive programming, а об UB vs FailFast. Ещё раз подчеркну: в нормальной среде о том, что произошла ошибка доступа к разрушенному объекту
S>1. вы узнаете (а не получите случайную наведённую ошибку где-то в совершенно постороннем коде)
S>2. узнаете не из рукопашных проверок постусловий в стиле defensive programming, а из вылета соответствующего исключения.

Необязательно рукопашных, для памяти есть автоматизированные sanitizer'ы, valgrind'ы и т.п., которые легко включать при тестировании.
Если же тестирование слабое, или вообще отсутствует, то корректную программу среднего размера ты ни на одном языке не напишешь

EP>>Это всего лишь синтетический пример, показывающий что твоя оценка "от слова вообще" слишком категоричная.

S>Этот синтетический пример означает выход за пределы стандарта С++. Я не спорю — можно разработать другой язык, с другими правилами, и с другими стандартными библиотеками.
S>Но по факту мы работаем с реальным C++, а не с его воображаемым аналогом, только без шлюх и блэкджека.

Так это реальный C++, удовлетворяющий стандарту, а не аналог
Реализации никто не запрещает детектировать dangling pointer и т.п. Наоборот, UB в стандарте как раз позволяет это делать.

EP>>Например: у объекта, и всех указателей на него, сделать shared state в виде флага is_alive.

S>И как мы это сделаем для указателей, которые вычисляются при помощи арифметики?

Смотря о чём речь.
Если об арифметике внутри массива — то тут всё просто, указатель на элемент массива, держит весь массив. Если же произошёл выход за пределы — делаем terminate/exception или что там потребуется.
Если же, например, о сохранении указателя на диск, а потом повторном считывании — то в таких редких предельных случаях можно сделать утечку shared state — who cares.

S>И как мы обновим флаг во всех указателях в момент выполнения delete? Предполагается, что в объекте будет сидеть список backreferences на все указатели на него?


shared state — это ref counted объект, грубо говоря std::shared_ptr<bool>. На него ссылаются и сам объект и все указатели.
При разрушения объекта, он всего лишь записывает в этот флаг false.
Re[60]: Nemerle через 5 лет - выстрелит или скончается?
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 23.10.14 09:29
Оценка:
Здравствуйте, DarkEld3r, Вы писали:
DE>Ну да, копирование — дорогая операция. И что?
То, что его нужно избегать.
Например, java и C# не копируют строки.

DE>А зачем нам так оптимизировать копирование?

Затем, что у нас очень много передач строк друг другу.
DE>Во первых, это не такая и однозначная оптимизация.
Однозначнее некуда. То, что в С++ она приводит к плохим последствиям — проблема С++.

DE>Во вторых, это (уже) запрещено стандартом. Да, GCC в этом нюансе стандарт (пока?) нарушает. Вроде, есть отдельный "правильный" тип строк.

DE>Особенность реализации. Который может (и не должно) и не быть.
Тогда будут О(N) копирования.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[59]: Nemerle через 5 лет - выстрелит или скончается?
От: alex_public  
Дата: 23.10.14 10:15
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Отлично. То есть вы ссылаетесь на реализацию GCC, в которой нет SSO. зато есть refcount.


Это старая реализация, не особо совместимая с новым стандартом. Но её пока оставили вроде как потому, что ломающие ABI изменения они делают только какими-то там этапами. Кстати, кажется следующий как раз в ближайшее время будет (4.10 версия). Нормальная версия давным давно добавлена, но под другим именем пока что. Ну это то, что мельком слышал. Специально не разбирался в "политических" деталях. )))

S>Понятно, что в вырожденных сценариях типа "передачи владения" есть шанс обойтись без копирований и рефкаунтов.


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

S>Речь о том, что в классическом, банальном

S>
S>string s("hello");
S>f1(s); // мы получаем copy constructor со штрафом за рефкаунт
S>f2(s);
S>


Этот код может приводить к абсолютно разным последствиям, в зависимости от прототипа функций f. Варианты с ходу:
f(string s);
f(string& s);
f(string&& s);
f(const string& s);
Re[55]: Nemerle через 5 лет - выстрелит или скончается?
От: alex_public  
Дата: 23.10.14 10:18
Оценка: :)
Здравствуйте, ionoy, Вы писали:

I>Большинство современного GUI софта написано в асинхронном стиле. Объекты там создаются, скачут между контекстами, а потом, когда все подписчики отработают, подлежат уничтожению. Вручную искать момент завершения работы с объектом значит очень сильно переусложнить код. Никакого скоупа там нет.


Вот только не надо опять же навязывать свою Java-подобную архитектуру с кучей лишнего прокладочного кода. У меня написание GUI перед глазами и я не вижу там ничего скачущего.
Re[56]: Nemerle через 5 лет - выстрелит или скончается?
От: ionoy Эстония www.ammyui.com
Дата: 23.10.14 10:24
Оценка:
Здравствуйте, alex_public, Вы писали:

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


I>>Большинство современного GUI софта написано в асинхронном стиле. Объекты там создаются, скачут между контекстами, а потом, когда все подписчики отработают, подлежат уничтожению. Вручную искать момент завершения работы с объектом значит очень сильно переусложнить код. Никакого скоупа там нет.


_>Вот только не надо опять же навязывать свою Java-подобную архитектуру с кучей лишнего прокладочного кода. У меня написание GUI перед глазами и я не вижу там ничего скачущего.


Поговорим об этом через лет пять
www.livexaml.com
www.ammyui.com
www.nemerleweb.com
Re[48]: Nemerle через 5 лет - выстрелит или скончается?
От: alex_public  
Дата: 23.10.14 10:25
Оценка:
Здравствуйте, ionoy, Вы писали:

I>Как можно всеръёз воспринимать статью, которая в первых строчках показывает javascript как образец safety and productivity?


Ну я всё же прочитал до конца и мне понравилось. А MSфилам могу посоветовать также посмотреть на личность автора — может это поспособствует прочтению статьи. )))

I>Не, я понимаю, яваскрипт реально удобная штука. Мне вот пару дней назад надо было из массива точек отобразить рисунок. На всё про всё ушло минуты, наверное две. В текстовом редакторе подставил перед каждой точкой lineTo, потом это дело скопировал в jsfiddle и отобразил на canvas. Удобно? Очень.


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

Кстати, а я бы для подобных задач использовал Питон. )

I>Но как только от маленькой задачи мы начинаем двигаться к большой, так сразу начинаются проблемы с поддержкой, скоростью разработки, качеством IDE и тд. В крупных проектах javascript и небезопасен, и непродуктивен. Большинство современных языков справляются с его задачами значительно лучше. Его преимущество только в абсолютной распространённости и кроссплатформенности благодаря браузерам.


Да, согласен, на крупных проектах скриптовые языки не удобны. Это и моё мнение. Но насколько я знаю, его разделяют далеко не все. )
Re[61]: Nemerle через 5 лет - выстрелит или скончается?
От: DarkEld3r  
Дата: 23.10.14 10:28
Оценка: +1 -1
Здравствуйте, Sinclair, Вы писали:

S>То, что его нужно избегать.

S>Например, java и C# не копируют строки.
В С++, как ни странно, копирования тоже избегают. В том числе, дешевым перемещением.

S>Однозначнее некуда. То, что в С++ она приводит к плохим последствиям — проблема С++.

Нет никаких проблем.

S>Тогда будут О(N) копирования.

И что? Пусть себе будут. Но мы будем или передавать по ссылке или перемещать, а копировать только тогда, когда без этого никак.
Re[61]: Nemerle через 5 лет - выстрелит или скончается?
От: jazzer Россия Skype: enerjazzer
Дата: 23.10.14 10:33
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

DE>>А зачем нам так оптимизировать копирование?

S>Затем, что у нас очень много передач строк друг другу.
"передач" — это move, а не копирование. Само слово подсказывает даже
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[61]: Nemerle через 5 лет - выстрелит или скончается?
От: alex_public  
Дата: 23.10.14 10:33
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Тогда будут О(N) копирования.


Я правильно понимаю, что это так страшно закодировано банальное char_traits::copy(stack1, stack2, 16);?)
Re[54]: Nemerle через 5 лет - выстрелит или скончается?
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.10.14 14:07
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Во-первых не получаешь. Правильная формулировка такая: есть шанс, что получишь при определённых условиях работы на определённых java машинах.


На счет условий согласен. Это основная проблема. В Яве есть ряд вещей препятствующих эскейп-анализу.
На счет "на определённых java машинах" — не согласен. Все что ты тут про С++ говоришь тоже только для GCC применимо. Орокловая ява-машина — это стандарт дефакто. Так что это не проблема особо.

_>А во-вторых в чём проблема знать где и сколько будет жить объект? )


Проблемы сразу две.
1. Мозг лучше загружать деталями алгоритма, а не деталями управления памятью.
2. В С++ ошибки в этой области приводят к очень не простой отладке, а зачастую такие баги живут в продуктах по много лет.

Все это снижает скорость разработки.

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


Решена одна мелкая частная проблема. Проблема же управления памятью по прежнему лежит на программисте. В купе с другими небезопасными решениями (вроде отсутствия инициализации памяти отводимой под переменные) это усложняет заработку и сопровождение. Баги с памятью часто вылезают при рефакторинге. Когда пишешь ты еще помнишь про время жизни, стратегию и т.п., а при изменении (особенно при массовом) можно спокойно пропустить нюансик. Тем более, что на сях мало кто пишет обходясь только одними типобезопасными методами. Легкодоступность опасных конструкций делает картину совсем печальной. В итоге время разработки сравнимого кона да Шарпе и плюсах сильно отличается и не в пользу С++.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[55]: Nemerle через 5 лет - выстрелит или скончается?
От: alex_public  
Дата: 23.10.14 22:05
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>На счет условий согласен. Это основная проблема. В Яве есть ряд вещей препятствующих эскейп-анализу.

VD>На счет "на определённых java машинах" — не согласен. Все что ты тут про С++ говоришь тоже только для GCC применимо. Орокловая ява-машина — это стандарт дефакто. Так что это не проблема особо.

Тут поинт был не на "определённых", а на "java машинах". ) Намекая на .net и другие платформы со сборщиком мусора. )

VD>Проблемы сразу две.

VD>1. Мозг лучше загружать деталями алгоритма, а не деталями управления памятью.
VD>2. В С++ ошибки в этой области приводят к очень не простой отладке, а зачастую такие баги живут в продуктах по много лет.

VD>Все это снижает скорость разработки.


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

VD>Решена одна мелкая частная проблема. Проблема же управления памятью по прежнему лежит на программисте. В купе с другими небезопасными решениями (вроде отсутствия инициализации памяти отводимой под переменные) это усложняет заработку и сопровождение. Баги с памятью часто вылезают при рефакторинге. Когда пишешь ты еще помнишь про время жизни, стратегию и т.п., а при изменении (особенно при массовом) можно спокойно пропустить нюансик. Тем более, что на сях мало кто пишет обходясь только одними типобезопасными методами. Легкодоступность опасных конструкций делает картину совсем печальной. В итоге время разработки сравнимого кона да Шарпе и плюсах сильно отличается и не в пользу С++.


Ну проблемка то хотя мелкая и частная, но её решение очень существенно меняет весь язык и существенно увеличивает производительность (это при том, что и при старом стандарте никто особо не мог конкурировать по этому параметру). Причём увеличивается производительность даже совсем старого кода, достаточно его просто перекомпилировать по новому (правда при этом скорее всего всплывут разные другие несовместимости (типа nullptr), но это даже полезно).

Ну а в остальном я в общем то согласен. Только вывод бы немного переделал: для достижения одинаковой скорости разработки на C# и C++, требуется чтобы программист C++ был заметно более высокого уровня. И этот вывод конечно же не в пользу C++.
Re[67]: Nemerle через 5 лет - выстрелит или скончается?
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 24.10.14 05:11
Оценка: :)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Во-вторых, совершенно без разницы. Я показываю, что EA тут не даёт никакой type safety. Эта type safety в управляемых языках есть и без EA, а в C++ возможна без EA.
Я понимаю, что вы показываете. Я вам пытаюсь объяснить, что подход управляемых языков — "давайте начнём с корректной программы (т.е. с type safety), а затем сделаем её быстрой (например, снизим нагрузку на GC путём EA)". А в С++ подход "давайте начнём с быстрой программы (т.е. дадим пользователю самому управлять временем жизни объектов), а потом безуспешно будем пытаться сделать её корректной".


EP>Ты говоришь про общий случай. Для общего случая в C++ возможен только conservative GC, что уже обсуждалось выше по топику.

Ну, вот и договорились.

EP>И, конечно же, никаких fixed и unsafe там быть не может, да?

Может, но это не влияет на моё утверждение.

EP>Теоретически.

EP>А практически, для таких сценариев и при необходимости гарантий (например при невозможности достижения их одними guidelines) — можно запретить брать raw указатели на такие GC объекты — частично языком + простейшим внешним верификатором.
У нас с вами противоположные понятия о "теоретически vs практически". Я считаю, что ваша идея про необходимость гарантий — это чистая теория, не подтверждённая на практике. А практика — это наличие а) компиляторов, которые неспособны запрещать брать указатели на особые объекты, в том числе и непреднамеренно, б) библиотек, которые несовместимы с такими ограниченными объектами, и с) наработанной прикладной кодовой базы на основе компиляторов и библиотек, которую никто не возьмётся переписывать в светлое будущее ради того, чтобы получить хоть какие-то гарантии в одном крошечном кусочке нашего проекта с 15-летней историей.
EP>А кто тогда позволяет? ObjectDisposed и OutOfBounds?
Конечно.
EP>Так это реальный C++, удовлетворяющий стандарту, а не аналог
Покажите мне этот "реальный C++". Увы — он существует только в вашем воображении.
EP>Реализации никто не запрещает детектировать dangling pointer и т.п. Наоборот, UB в стандарте как раз позволяет это делать.


EP>shared state — это ref counted объект, грубо говоря std::shared_ptr<bool>. На него ссылаются и сам объект и все указатели.

EP>При разрушения объекта, он всего лишь записывает в этот флаг false.
Да, так будет работать. Интересно, отчего эта техника не применяется в управляемых средах? Двойная ссылка считается слишком медленной?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Отредактировано 24.10.2014 8:00 Sinclair . Предыдущая версия .
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.