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

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

WH>С++ я знаю не хуже тебя.
WH>И знаю все методы и приемы которые используются при разработке на это недоязычке.
WH>Так что не надо мне показывать как пишут скопгарды.


Ты просто сказал, что тут надо что-то долго и нужно думать, что бы это реализовать. Я показал, что всё достаточно просто.



R>>Если ты имешь в виду interlocked в функции освобождения памяти, то если одно копирование, то и interlocked один
WH>Там будут вызваны несколько конструкторов копирования и несколько деструкторов.
WH>Если строки на счетчиках ссылок то нужно в каждом конструкторе и деструкторе дергать interlocked. Это неизбежно в случае многопточной программы.


Во-первых, избежно.
Во-вторых, сейчас уже никто не делает строки с подсчётом ссылок.
Копий не будет не потомучто там разделяемое тело, а потомучто компилятор соптимизирует.




R>>Программист на языке с наличием семантических барьеров думает "Я обязан делать так, как это сделано в языке. От этого никуда не деться. Освобождение памяти подразумевает interlocked".
WH>Программист на языке с этими самыми барьерами ( ) вобще не думает о освобождении памяти.
WH>Понимаешь вобще не думает.

Хорошо, я понял, что он вобще не думает.

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



R>>Программист на языке без наличия семантических барьеров думает "Пока меня не волнует, я буду делать так, как это сделано в языке. Если для меня это будет важно, то я сделаю это так как мне надо. Освобождение памяти при необходимости можно сделать без interlocked".
R>>
WH>Это потом не настанет никогда.


У кого как. У меня лично уже настало.


WH>>>Можно конечно тупо понаписать тупых ScopeGuard'ов но ими пользоватся не удобно.
R>>А от них сильно много и не требуется...
WH>Использовать Сишный интерфейс тот еще геморой.
WH>Так что требуется.


Ну так его и не надо использовать — его надо просто обернуть.


R>>Попробую сформулировать так: С++ позволяет большую часть времени не задумываться об управлении памятью.
WH>В тривиальных случаях.

Большая часть программ это и есть тривиальные случаи.


R>>Если в начале проекта потратить пару дней на создание некого общего инструментария, либо возможно он уже есть у программиста/компании, то об управлении памятью можно не задумываться 99.9% времени. Но тем не менее, и это имхо сильная сторона, об управлении памяти хотя бы можно задуматься при большой необходимости.
WH>Наивный чукотский юноша. Я несколько лет назад тоже таким был.


Знаешь, история мысли развивается по спирали...


R>>И ещё раз повторюсь: обеспечивается гарантия отсутствия утечек не меньшая чем в других современных языках, обеспечивается полная безопасность при возникновении исключений.
WH>Конечно же меньшая.
WH>С этим спорить бессмысленно.
WH>Это факт.


Ну просто, что бы не быть голословным, покажи где эта гарантия меньше на этом примере:

string f(string s)
{
  string s2 = f2();
  return s + s2 + "!";
}

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

R>А так же требуют дополнительных строк кода и дополнительного отступа.

Точно. Поэтому я никогда не пишу комментарии.

R>А так же являются не более, чем необязательным синтаксическим сахаром. В то время, как стековый объект может формировать правильное использование класса.

Ага. И догадаться, что там за кадром происходит transaction scope можно только изучив исходники.

R> А это имхо посильнее, чем отсутствие явного региона.

Ну, тогда АОП посильнее твоей фигни, там вообще внутри кода ничего писать не надо.

AVK>>Аналогично
AVK>>

AVK>>using (var tx1 = v1.TxPushBack(1))
AVK>>using (var tx2 = v2.TxPushBack(2))
AVK>>{
AVK>>    v3.PushBack(3);
AVK>>    tx1.Commit();
AVK>>    tx2.Commit();
AVK>>}
AVK>>

R>Если внтури веток будет ещё какой-то код, то будет напоминать С-код с 18 уровнями отступов...

Транзакции с 18 уровнями вложенности в единственном методе? Ну да, хрустальные приборы не для всех.

R> Т.е. не масштабируется.

Ужас просто.

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

R>Про "тормозило" вообще не понятно. На современных компиляторах ран-тайм цена такой обёртки — 0 тактов процессора, 0 байт оперативной памяти, 0 байт размера выполняемого файла.

А на синхронизацию инкремента/декремента счетчиков внутри оберток тоже 0 тактов процессора тратится?

Здравствуйте, Константин Л., Вы писали:

C>>>>А ты дальше подумай — что делать, если эта структура будет полем класса, уничтожение которого недетерминировано?
КЛ>>>И что? Если ее создали на стеке — ведет себя как стековый объект. Если нет — ну нет так нет. В C++\CLI именно так и работает.
C>>Осталось сделать следующий шаг, и понять, что стековые объекты не нужны — достаточно паттерна Disposable и сахара в виде using().
КЛ>Шаг к чему? К дао? Достаточно понять, что using менее сладок нежели стековые объекты.
Ты подумай, однако. "Стековые" объекты нельзя просто так класть в ref-классы, так как они уничтожаются в недетерминированое время. Да, и семантики передачи по значению с вызовом копирующих конструкторов в C#/Java тоже как таковой нет. Следовательно, нам нужно будет или добавлять всю сементику копирующих конструкторов с операторами присваивания, или ограничивать стековые объекты только одним фреймом. Ну а если ограничить их только одним фреймом — и получим полный аналог using().

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

R>Смотрю описание интерфейса ScopedMemory — "When the last reference to the object is removed, by exiting the thread or exiting the enter() method, finalizers are run for all objects in the memory area, and the area is emptied"
R>Или я что-то не так понял?
Не совсем, оно без GC, AFAIR, все равно не работает.

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

C>Здравствуйте, Константин Л., Вы писали:

C>>>>>А ты дальше подумай — что делать, если эта структура будет полем класса, уничтожение которого недетерминировано?
КЛ>>>>И что? Если ее создали на стеке — ведет себя как стековый объект. Если нет — ну нет так нет. В C++\CLI именно так и работает.
C>>>Осталось сделать следующий шаг, и понять, что стековые объекты не нужны — достаточно паттерна Disposable и сахара в виде using().
КЛ>>Шаг к чему? К дао? Достаточно понять, что using менее сладок нежели стековые объекты.
C>Ты подумай, однако. "Стековые" объекты нельзя просто так класть в ref-классы, так как они уничтожаются в недетерминированое время.

Так подумать над этой проблемой, или над тем, что слаще?

C>Да, и семантики передачи по значению с вызовом копирующих конструкторов в C#/Java тоже как таковой нет. Следовательно, нам нужно будет или добавлять всю сементику копирующих конструкторов с операторами присваивания, или ограничивать стековые объекты только одним фреймом. Ну а если ограничить их только одним фреймом — и получим полный аналог using().

А вот волшебники взяли и заимплементили такую фичу в c++\cli

Здравствуйте, Константин Л., Вы писали:

C>>Ты подумай, однако. "Стековые" объекты нельзя просто так класть в ref-классы, так как они уничтожаются в недетерминированое время.
КЛ>Так подумать над этой проблемой, или над тем, что слаще?
То есть?

C>>Да, и семантики передачи по значению с вызовом копирующих конструкторов в C#/Java тоже как таковой нет. Следовательно, нам нужно будет или добавлять всю сементику копирующих конструкторов с операторами присваивания, или ограничивать стековые объекты только одним фреймом. Ну а если ограничить их только одним фреймом — и получим полный аналог using().
КЛ>А вот волшебники взяли и заимплементили такую фичу в c++\cli
Это вполне понятно, так как C++/CLI уже включает в себя все механизмы обычного С++ для управления памятью. А ты попробуй придумать как добиться того же, не повторяя половину С++.

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

VD>Теперь, ВНИМАНИЕ вопрос... О чем речь то?

Наверно о том что пример некорректный
В программе занимающейся пакетными расчетами управление ресурсами кроме памяти (GC) и доступа к файлам (который несложно автоматизировать) и не нужно.

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

VD>Здравствуйте, PC Car, Вы писали:

PC>>Почему не ввести вместо using на такой случай специальный тип — стековый класс? Это ведь не потребует усложнения синтаксиса. Просто у структуры появится деструктор с детерминированным временем вызова.

VD>В C++/CLI так и сделано. Жить от это особо лучше не стало. По крайней это не компенсировало отсуствия в C++/CLI других полезных свойств Шарпа.

Ну в D тоже есть, но там сделали чуть умнее чем в C++/CLI, есть ключевое слово scope, если класс обявлен как scope, то он может жить только на стеке, и объявить его например членом класса не выйдет, кроме того переменную любого класса можно заставить жить на стеке объявив с модификатором scope:

import std.stdio;

// обычный класс
class SimpleClass
{
    this(int n)
    {
        this.n = n;
        writefln("SimpleClass constructor #", n);
    }
    
    ~this()
    {
        writefln("SimpleClass destructor #", n);
    }
    
    int n;
}

// этот класс может объявлятся только на стеке
scope class ScopeClass
{
    this()
    {
        writefln("ScopeClass constructor");
    }
    
    ~this()
    {
        writefln("ScopeClass destructor ");
    }   
}

class Test1
{
    // нормально
    SimpleClass tstSimple;
    
    // ниже не скомпилируется
    //ScopeClass tstScope; 
    
    this()
    {
        tstSimple = new SimpleClass(1);
    }
}


void main()
{
    // чисто стековая переменная
    scope sc = new ScopeClass();

    // обычная переменная управляемая GC
    auto sm = new SimpleClass(1);
            
    // переменная обычного класса с временем жизни ограниченным областью
    scope scsm = new SimpleClass(2);    
}

выводит:

ScopeClass constructor
SimpleClass constructor #1
SimpleClass constructor #2
SimpleClass destructor #2
ScopeClass destructor 
SimpleClass destructor #1

VD>На самом деле после некоторого опыта использования управляемых языков понимашь, что страхи плюсовиков (коим я являлся до перехода на управляемые среды) сильно надуманы. 99% контроля ресурсов — это контроль памяти. А когда память не нужно пасти, то остальное можно хоть руками контролировать. В общем using-а за глаза хватает.

Ну а те кто уже не пишут на плюсах со своей стороны любят преувеличить сложность управления памятью в них.

VD>Ну, а стековый объект все равно не всегда поможет. Ведь если время жизни объекта не совпадает с временем проведенным в процедуре, то и контролировать его так не выйдет.

Это да, для этого хороши потоки (итераторы — генераторы) и продолжения.

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

R>>Ничем щёлкать не надо
WH>При освобождении памяти в многопоточной программе надо.

При выделении — освобождении памяти с хорошоим аллокатором как раз практически не надо, вот при доступе да приходится.

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

FR>

FR>ScopeClass constructor
FR>SimpleClass constructor #1
FR>SimpleClass constructor #2
FR>SimpleClass destructor #2
FR>ScopeClass destructor 
FR>SimpleClass destructor #1
FR>

А чем тогда это лучше using()? ИМХО, абсолютно лишняя сущность.

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

C>А чем тогда это лучше using()? ИМХО, абсолютно лишняя сущность.

Тем что жестче контроль и разделение. Случайно объявить не там где нужно такой класс не возможно.

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

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

R>>Про "тормозило" вообще не понятно. На современных компиляторах ран-тайм цена такой обёртки — 0 тактов процессора, 0 байт оперативной памяти, 0 байт размера выполняемого файла.

AVK>А на синхронизацию инкремента/декремента счетчиков внутри оберток тоже 0 тактов процессора тратится?


Какое это имеет отношение к обёртке над С библиотекой? Это уже новый функционал. Если это необходимый функционал, то он уже есть внутри С библиотеки, только не через RAII, а через acquire()/release().

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


VD>Вот тебе реальные факты. В проекте компилятора Немерле есть 5 файлов (из 124 файлов) в которых используется using:
VD>http://nemerle.org/svn/nemerle/trunk/macros/Data.n — 4
VD>http://nemerle.org/svn/nemerle/trunk/macros/Util.n — 3
VD>http://nemerle.org/svn/nemerle/trunk/ncc/codedom/NemerleCodeCompiler.n — 2
VD>http://nemerle.org/svn/nemerle/trunk/ncc/CompilationOptions.n — 1
VD>http://nemerle.org/svn/nemerle/trunk/ncc/hierarchy/TypesManager.n — 1
VD>общее число применений равно 11. Это на 2.2 мегабайта исходников.

VD>Теперь, ВНИМАНИЕ вопрос... О чем речь то?


Да, это ж компилятор. Ты б ещё какую-нибудь утилиту вспомогательную взял.
Если там и эти using убрать никто ничего и не заметит.

FR wrote:
> C>А чем тогда это лучше using()? ИМХО, абсолютно лишняя сущность.
> Тем что жестче контроль и разделение. Случайно объявить не там где нужно
> такой класс не возможно.
ИМХО, совсем не оправдывает введение еще одной сущности.

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

C>FR wrote:
>> C>А чем тогда это лучше using()? ИМХО, абсолютно лишняя сущность.
>> Тем что жестче контроль и разделение. Случайно объявить не там где нужно
>> такой класс не возможно.
C>ИМХО, совсем не оправдывает введение еще одной сущности.

А что для Вальтера лишняя сущность!

А using не лишняя сущность?
К тому же scope используемый вот так:

    {
    scope scsm = new SimpleClass(2);
    // .....
    }

эквивалентен using

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

C>Здравствуйте, Константин Л., Вы писали:

C>>>Ты подумай, однако. "Стековые" объекты нельзя просто так класть в ref-классы, так как они уничтожаются в недетерминированое время.
КЛ>>Так подумать над этой проблемой, или над тем, что слаще?
C>То есть?

Сначала ты с пафосом предлагал "дойти" до мысли, что это просто не нужно. Потом начал упирать на то, что это нереализуемо.

C>>>Да, и семантики передачи по значению с вызовом копирующих конструкторов в C#/Java тоже как таковой нет. Следовательно, нам нужно будет или добавлять всю сементику копирующих конструкторов с операторами присваивания, или ограничивать стековые объекты только одним фреймом. Ну а если ограничить их только одним фреймом — и получим полный аналог using().
КЛ>>А вот волшебники взяли и заимплементили такую фичу в c++\cli
C>Это вполне понятно, так как C++/CLI уже включает в себя все механизмы обычного С++ для управления памятью. А ты попробуй придумать как добиться того же, не повторяя половину С++.

для этого не нужно ничего повторять.

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

IT>Здравствуйте, PC Car, Вы писали:

PC>>Почему не ввести вместо using на такой случай специальный тип — стековый класс?

IT>Зачем что-то ещё? Используй тот же using.

А что будет, если из кода внутри юзинга вылетит исключение? Которое по идее ловится на два уровня выше по колстеку?

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

PC>А что будет, если из кода внутри юзинга вылетит исключение?

Изучай что такое using.

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

C>>ИМХО, совсем не оправдывает введение еще одной сущности.
FR>А что для Вальтера лишняя сущность!
Ну да, после трех сортов константности от таких людей чего угодно можно ждать.

FR>

FR>    {
FR>    scope scsm = new SimpleClass(2);
FR>    // .....
FR>    }    
FR>

FR>эквивалентен using
В _таком_ виде scope просто является другой записью using'а — я не против. Но зачем делать scope-классы — это уже мне не очень понятно.

Там же целая гора проблем сразу возникает: как работает наследование, что произойдет при наследовании от обычного класса, и т.д.