Непонятки со смартами

посмотри что внутри release делается, это ведь не delete obj

пилять.

ну зачем ты shared-ptr бездумно воткнул?

даже не посмотрев описание что делает get(), и что он не делает. что происходит после удаления shared-ptr.

да он банально удаляет объект, оставив висящую ссылку, полученную через get().

нет, там все объекты наследуются от базового класса, который в себе содержит счетчик ссылок, на подобие как сделано в обж-с с retain-release

даже не посмотрев описание что делает get()

pointer get() const;
Returns the pointer pointing to the owned object

Значит, addChild ретейнит объект (что очень логично). А shared_ptr вызывает не release, а delete. Можно переписать на release.

очевидно obj->release(); не тоже самое, что delete obj, ну и shared_ptr уже в стандарте, нет смысла использовать бустовскую реализацию

очевидно obj->release(); не тоже самое

угу, это так они сделали

void Object::release(void)
{
	--m_uReference;

	if (m_uReference == 0)
	{
		delete this;
	}
}

тогда может внутри addChild увеличивается счетчик m_uReference

• Откройте konqueror
• Введите в адресную строчку gg:boost::intrusive_ptr
• Тыркните стрелку справа в конце адресной строчки

Было 7 строчек работающего читабельного кода, стало 6 неработающего нечитабельного, но он не парится.:)

Это типа такой костыльный gc для C++ что ли?

Конечно, ведь плюсисты уверены что gc не нужен.

Это типа такой костыльный gc для C++ что ли?

Умные указатели и сборка мусора - это всё-таки несколько разные вещи.

Да, шел 2012-ый год, а люди до сих пор писали прикладные программы с ручным управлением памятью...

Честно, абсолютно не знаком с «умными указателями» :)

Заметно :)

Умные указатели и сборка мусора - это всё-таки несколько разные вещи

Это не мешает многим личностям использовать первое в качестве второго.

gc не нужен.

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

using System;
using System.ComponentModel;

// The following example demonstrates how to create
// a resource class that implements the IDisposable interface
// and the IDisposable.Dispose method.

public class DisposeExample
{
    // A base class that implements IDisposable.
    // By implementing IDisposable, you are announcing that
    // instances of this type allocate scarce resources.
    public class MyResource: IDisposable
    {
        // Pointer to an external unmanaged resource.
        private IntPtr handle;
        // Other managed resource this class uses.
        private Component component = new Component();
        // Track whether Dispose has been called.
        private bool disposed = false;

        // The class constructor.
        public MyResource(IntPtr handle)
        {
            this.handle = handle;
        }

        // Implement IDisposable.
        // Do not make this method virtual.
        // A derived class should not be able to override this method.
        public void Dispose()
        {
            Dispose(true);
            // This object will be cleaned up by the Dispose method.
            // Therefore, you should call GC.SupressFinalize to
            // take this object off the finalization queue
            // and prevent finalization code for this object
            // from executing a second time.
            GC.SuppressFinalize(this);
        }

        // Dispose(bool disposing) executes in two distinct scenarios.
        // If disposing equals true, the method has been called directly
        // or indirectly by a user's code. Managed and unmanaged resources
        // can be disposed.
        // If disposing equals false, the method has been called by the
        // runtime from inside the finalizer and you should not reference
        // other objects. Only unmanaged resources can be disposed.
        protected virtual void Dispose(bool disposing)
        {
            // Check to see if Dispose has already been called.
            if(!this.disposed)
            {
                // If disposing equals true, dispose all managed
                // and unmanaged resources.
                if(disposing)
                {
                    // Dispose managed resources.
                    component.Dispose();
                }

                // Call the appropriate methods to clean up
                // unmanaged resources here.
                // If disposing is false,
                // only the following code is executed.
                CloseHandle(handle);
                handle = IntPtr.Zero;

                // Note disposing has been done.
                disposed = true;

            }
        }

        // Use interop to call the method necessary
        // to clean up the unmanaged resource.
        [System.Runtime.InteropServices.DllImport("Kernel32")]
        private extern static Boolean CloseHandle(IntPtr handle);

        // Use C# destructor syntax for finalization code.
        // This destructor will run only if the Dispose method
        // does not get called.
        // It gives your base class the opportunity to finalize.
        // Do not provide destructors in types derived from this class.
        ~MyResource()
        {
            // Do not re-create Dispose clean-up code here.
            // Calling Dispose(false) is optimal in terms of
            // readability and maintainability.
            Dispose(false);
        }
    }
    public static void Main()
    {
        // Insert code here to create
        // and use the MyResource object.
    }
}

вместо обычного деструктора

ну и конечно вызывать это дело тоже очень просто и удобно:

using(MyResource myRes = new MyResource(handle))
{
    myRes.DoSomething();
}

куда там плюсам:

MyResource(handle).DoSomething();

Спасибо, я за него и забыд вообще, т.к. раньше не использовал.
Единственное почему-то работает только как шаблонные ф-ции. Ладно потом разберемся.

умные указатели это не ручное управление памятью

просто не тот смарт взял, т.к. провтыкал посмотреть что делал метод, вот и все.

в ручном управлении памяти нет ничего плохого, если знать что делаешь. Смарты иногда хорошо помогают.

нет, это типа реализация NSObject-a, зачем именно так сделали я хз

Как понимаю, ты стянул пример из MSDN, где показано как удалять из управляемого кода неуправляемый ресурс (обратить внимание на приставку «не-»). Что ты хотел этим показать?

ну и конечно вызывать это дело тоже очень просто и удобно

Что тут сложного?

MyResource(handle).DoSomething();

Что будет если в DoSomething вылетит exception?

показано как удалять из управляемого кода неуправляемый ресурс

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

Что будет если в DoSomething вылетит exception?

сработает деструктор, как и положено

и да - это конструкция очень популярна в C# и Java, только в другом виде - try/finally + ручное дергание метода для освобождения ресурсов, но этого было мало и в этих ЯП родили еще костыли, вроде приведеного выше

что объект удаляется по фазам луны

Учи IDisposable. В реальном коде используют using для удаления ресурсов.

В реальном коде используют using для удаления ресурсов.

извиняюсь, я не знал, что вы плохо видите, ПОЖАЛУЙСТА ПОСМОТРИТЕ НА ЭТОТ КОММЕНТАРИЙ:

Непонятки со смартами (комментарий)

и да - это конструкция очень популярна в C# и Java, только в другом виде - try/finally + ручное дергание метода для освобождения ресурсов, но этого было мало и в этих ЯП родили еще костыли, вроде приведеного выше

Это и есть try/finally, конструкция:

using(var file = new FileStream(@"filename", FileMode.Open))
{
    //... code
}

FileStream file = new FileStream(@"filename", FileMode.Open);
try
{
    //... code
}
finally
{
    if(file != null)
       ((IDisposable)file).Dispose();
}

Это и есть try/finally

спасибо кэп, будешь вторым К.О. после dave

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

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

Неуправляемые ресурсы освобождаются сразу

конечно сразу, конечно, вот как вручную метод дернут - так сразу и освободятся, а если не дернут, или забудут костыль вокруг поставить - ну и хрен с ним, пусть висит

С ним нет смысла дальше дискутировать.

конечно сразу, конечно, вот как вручную метод дернут - так сразу и освободятся, а если не дернут, или забудут костыль вокруг поставить - ну и хрен с ним, пусть висит

Ты из цирка сбежал что-ли? Легче забыть реализовать закрытие дескриптора в деструкторе, чем не обернуть неуправляемый объект в using.

С ним нет смысла дальше дискутировать.

конечно нет, фанаты GC уверено слили - вместо ручного управления памятью они получили ручное управление ресурсами + длинный и костыльный код, но пыжаться изо всех сил

Легче забыть реализовать закрытие дескриптора в деструкторе, чем не обернуть неуправляемый объект в using.

у вас очень плохая память

хотя нужно сказать, что GC может быть удобным - например в D

конечно нет, фанаты GC уверено слили - вместо ручного управления памятью они получили ручное управление ресурсами + длинный и костыльный код, но пыжаться изо всех сил

Реализуй, например, персистентное дерево на смартпойнтерах и посмотри на производительность сего поделия. А потом посмотрим кто слил.

на смартпойнтерах

зачем именно на них?

Можно вручную, без разницы.

https://github.com/aidarbiktimirov/data-structures/blob/master/src/include/pe...

не оно?

Возможно, вечером подробно посмотрю.

Тогда отсылаю тебя читать книгу «Стандарты программирования на C++» в той части, где говорится об уровнях безопасности при работе с исключениями (по-моему так называется тема, книги нет сейчас под рукой, а заглядывал в нее последний раз очень давно за ненадобностью). «Фанаты GC» могут спать спокойно уже потому, что самый первый примитивный уровень безопасности обеспечивается у них автоматически. Нефанаты же должны его обеспечивать самостоятельно в Cи++.

Ты правда думаешь, что с ресурсами проще работать в Си++?

Тогда отсылаю тебя читать книгу «Стандарты программирования на C++» в той части, где говорится об уровнях безопасности при работе с исключениями

поверь - я в курсе, и знаю про грабли

Ты правда думаешь, что с ресурсами проще работать в Си++?

я б сказал лаконичнее, т.к. стек + RAII

П.С, убегаю, сегодня уже не буду

в общем, раз у тебя уже есть __встроенный__ счетчик ссылок, то используй его через intrusive_ptr.

shared_ptr создает __отдельный__ счетчик ссылок, поэтому он срать хотел на то, кто еще использует твой класс через встроенный счетчик.

Реализуй, например, персистентное дерево на смартпойнтерах и посмотри на производительность сего поделия. А потом посмотрим кто слил.

Twitter went from 60 second of Garbage Collection (GC) per hour to 5 seconds per 3.5 days, mainly because of the internal slab allocator.

школьники такие школьники