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

class scoped_resource : nocopy
{
public:
    scoped_resource()
        : h_(alloc_resource())
    {
        if (!h_) throw 0;
    }

    ~scoped_resource()
    {
        free_resource(h_);
    }

    handle_t const handle() const
    {
        return h_;
    }

private:
    handle_t h_;
};

struct my_resource_traits
{
    typedef int handle_type;
    static int const invalid_handle = -1;
    static void free(int h)
    {
        free_resource(h);
    }
};

typedef shared_handle<my_resource_traits> my_resource_handle;

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

R>>Далее самое интересное — если мы в управляемой среде можем реализовать надёжное управление некоторыми ресурсами с помощью close/Dispose/using (можем же, правильно?), то в чём проблема при использовании тех же средств, но в других языках и для других ресурсов?

file f ("data");
//...

FR>Угу если еще учесть что есть scope(exit) и т. п.

class Base
{
   Base()
   {
      someExternalVariable=this;
   }
};

scope class Derived : public Base
{
   Derived() : Base() //???
   {
   }
}

R>>Далее самое интересное — если мы в управляемой среде можем реализовать надёжное управление некоторыми ресурсами с помощью close/Dispose/using (можем же, правильно?), то в чём проблема при использовании тех же средств, но в других языках и для других ресурсов?

using (db_conn conn = new db_conn(pool))
{
  //...
}

db_conn conn (pool);
//...

vector<int> v1, v2, v3;
push_back_tx tx1 (v1, 1);
push_back_tx tx2 (v2, 2);
v3.push_back(3);
tx1.commit();
tx2.commit();

shared_ptr<heavy_class> f()
{
  return shared_ptr<heavy_class>(new heavy_class());
}

shared_ptr<heavy_class> x = f();

using (var tran = partition.Store.TransactionManager.BeginTransaction())
{
    ...
    tran.Commit();
}

R>vector<int> v1, v2, v3;
R>push_back_tx tx1 (v1, 1);
R>push_back_tx tx2 (v2, 2);
R>v3.push_back(3);
R>tx1.commit();
R>tx2.commit();
R>

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

void f()
{
    lock l1 (m1);
    //...
    lock l2 (m2);
    //...
    file f;
    //...
}

void f()
{
    using (lock l1 = m1.lock())
    {
        //...
        using (lock l2 = m2.lock())
        {
            //...
            using (file f = open_file())
            {
                //...
            }
        }
    }
}

using System;
using System.Collections.Generic;
using System.Console;
using System.IO;
using System.IO.Path;
using Nemerle.Utility;

[Record]
public class FileIterator : IEnumerable[string]
{
  fileName : string;
  
  public GetEnumerator() : IEnumerator[string]
  {
    using (resource = File.OpenText(fileName))
    {
      
      def loop(line)
      {
        | null => ()
        | _    => yield line; loop(resource.ReadLine())
      }
      
      loop(resource.ReadLine())
    }
  }
}

module Program
{
  Main() : void
  {
    def asmPath = Reflection.Assembly.GetCallingAssembly().Location;
    def thisFileName = Combine(GetDirectoryName(asmPath), @"..\..\Main.n");
    foreach (line in FileIterator(thisFileName))
      WriteLine(line);
      
    WriteLine();
    WriteLine("--------------------------------------------------------------");
    WriteLine();
    
    FileIterator(thisFileName).Iter(WriteLine);
      
    _ = ReadLine();
  }
}

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

R>смарт поинтер не рассматривается?

class producer : public actor
  {
  private :
    consumer * m_consumer;

  public :
    void on_some_event()
      {
        // Что-то произошло, consumer-у нужно отослать данные.
        m_consumer->send( new data( ... ) );
      }
  };

class consumer : public actor
  {
  private :
    producer * m_producer;

  public :
    void on_data( const data * msg )
      {
        // Обработка данных...
        // Заставляем producer-а выдать следующую порцию данных.
        m_producer->send( new get_next_data( ... ) );
      }
  };

Стековая аллокация

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

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

Плохо то, что кэш-промах при аллокации объекта в массиве имеет особенно опасное взаимодействие с памятью. При аллокации памяти из массива содержимое данной памяти является мусором — любые биты, оставшиеся после того, как память использовалась в последний раз. Если вы размещаете блок памяти в массиве, который еще не находится в кэше, при выполнении возможны зависания, пока содержимое данной памяти будет переноситься в кэш. Затем вы немедленно перепишете эти значения, которые вы затратили на то, чтобы перенести в кэш с нулями или другими исходными данными, а это приводит к большим потерям работы памяти. (Некоторые процессоры, такие как Azul's Vega, включают аппаратную поддержку для ускорения аллокации массива).

Escape-анализ

Язык Java не предлагает никакого способа точно расположить объект в стеке, но этот факт не мешает JVM использовать стековую аллокацию, где это уместно. JVM может использовать технологию, именуемую escape-анализ, с помощью которой можно сказать, что определенные объекты удерживаются в одном потоке в течение всего жизненного цикла, а он связан со временем существования данного стекового фрейма. Такие объекты можно безопасно располагать в стеке вместо массива. Что даже лучше для маленьких объектов, JVM может полностью оптимизировать аллокацию и просто поднять поля объекта в списки.

(прим. ред. — далее приводятся примеры с псевдокодом оптимизации)

...

Escape-анализ в Mustang

Escape-анализ является оптимизацией, о которой уже давно говорилось, и наконец-то вот она — текущие сборки Mustang (Java SE 6) могут осуществлять escape-анализ и конвертировать аллокацию массива в стековую аллокацию (или без аллокации) там, где это уместно. Использование escape-анализа для устранения некоторых результатов аллокаций с более быстрым средним временем аллокации, уменьшенным потреблением ОЗУ и меньшим количеством кэш-промахов. Кроме этого, оптимизирование некоторых аллокаций уменьшает давление на сборщик мусора и позволяет реже запускать сборку.

© Теория и практика Java: Еще раз о городских легендах о производительности. Аллокация гораздо быстрее, чем вы думаете, и все больше ускоряется, Брайан Гетц

{
    vector<int> v1, v2, v3;
    //
    {
        push_back_tx tx1 (v1, 1);
        //
        {
            push_back_tx tx2 (v2, 2);
            v3.push_back(3);
            tx1.commit();
            tx2.commit();
        }
        //
    }
    //    
}

R>void f()
R>{
R>    using (lock l1 = m1.lock())
R>    {
R>        //...
R>        using (lock l2 = m2.lock())
R>        {
R>            //...
R>            using (file f = open_file())
R>            {
R>                //...
R>            }
R>        }
R>    }
R>}
R>

void f()
{
    using (lock l1 = m1.lock(), l2 = m2.lock())
        using file f = open_file()
        {
                //...
        }
}

lock(obj)
{
    ...
}

WH>Программист на языке с этими самыми барьерами ( ) вобще не думает о освобождении памяти.

R>>

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

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

_>Особенно сладки стековые объекты в С++, когда идёт отмотка стека из-за исключения и тут из деструктора вылетает новое исключение

list1.push(v1);
try
{
  list2.push(v2);
}
catch (...)
{
  try
  {
    list1.pop();
  }
  catch (...)
  {
    //!!! <--------------
  }
}

import std.stdio;

class Base
{   
   static Base someExternalVariable;
    
    this()
    {
        writefln("Base constructor"); 
        someExternalVariable=this;
    }
   
   ~this()
    {    
        writefln("Base destructor ");
    }
    
    void Test()
    {
        writefln("Test");
    }
   
}

scope class Derived : Base
{
   this()
   {
       super();
   }
}


void main()
{
    {
    scope sc = new Derived();
    }
    
    writefln("end");
    
    Base.someExternalVariable.Test();
}