Re[6]: Сборщик мусора и размещение объектов в стеке
От: remark Россия http://www.1024cores.net/
Дата: 14.12.07 13:33
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


R>>Ищи по "The Real-Time Specification for Java". Фактически они добавили синхронное освобождение памяти — схема применяемая в современном С++.

C>Нет. В realtime Java _нет_ синхронного освобождения памяти — это сделать в общем случае чрезвычайно дорого. Для realtime Java гарантируются только верхние границы на время отклика сборщика мусора, ничего более.


Смотрю описание интерфейса 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"

Или я что-то не так понял?



1024cores — all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[6]: Сборщик мусора и размещение объектов в стеке
От: nikov США http://www.linkedin.com/in/nikov
Дата: 14.12.07 13:35
Оценка:
Здравствуйте, remark, Вы писали:

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>


Отступы и скобки писать необязательно.
Re[4]: Смотри шире
От: remark Россия http://www.1024cores.net/
Дата: 14.12.07 13:41
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


R>>Ресурсами, которые контролируются стековым объектом, могут быть не только такие объекты как соединение, файл и т.д.

R>>Техника значительно шире. Например, с помощью стекового объекта может контролироваться временный перевод курсора в "часики", блокировка/разблокировка мьютекса, задержка/возобновление обновления графического элемента управления, резервирование/разрезервирование какого-либо места/счётчика и т.д. и т.д.

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


VD>Вот тебе реальные факты. В проекте компилятора Немерле есть 5 файлов (из 124 файлов) в которых используется using:



Это ни о чём не говорит. Возможно разработчики просто его не применяли.
У того, кто использует компонент, мотивация не использовать using — надо писать дополнительные строчки кода + дополнительный отступ.
У того, кто разрабатывает компонент, мотивация не предоставлять объекты, которые можно использовать в using — нет гарантии, что их будет кто-то использовать. using — это не более необязательного синтаксического сахара.


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


Я не согласен с твоими утвержедниями:
1. стековые объекты нужны крайне редко, если есть GC
2. у стековых объектов есть какие-то проблемы, когда время жизни больше времени работы функции



1024cores — all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[4]: Смотри шире
От: remark Россия http://www.1024cores.net/
Дата: 14.12.07 13:45
Оценка: +3
Здравствуйте, AndrewVK, Вы писали:

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


R>>Техника значительно шире. Например, с помощью стекового объекта может контролироваться временный перевод курсора в "часики", блокировка/разблокировка мьютекса, задержка/возобновление обновления графического элемента управления, резервирование/разрезервирование какого-либо места/счётчика и т.д. и т.д.


AVK>Это прекрасно реализуется при помощи using. Более того, именно для таких фич using предпочтительнее, потому что явно выделяет регион действия и при чтении сразу видно, что и как происходит.



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



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>


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



AVK>Для этого, помимо стековой семантики, нужен еще и автоматический вызов деструкторов всех членов класса.


Да. В c++/cli так и делается.



1024cores — all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: Сборщик мусора и размещение объектов в стеке
От: remark Россия http://www.1024cores.net/
Дата: 14.12.07 13:46
Оценка:
Здравствуйте, nikov, Вы писали:

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


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>>


N>Отступы и скобки писать необязательно.



Специально написал "//..." — под этим подразумевается произвольный код.



1024cores — all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[5]: Смотри шире
От: Константин Б. Россия  
Дата: 14.12.07 14:04
Оценка:
Здравствуйте, remark, Вы писали:

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

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

Каким образом? Кто запретит разработчику создать lock в куче?

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


Со стековыми объектами тоже самое:
{
    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();
        }
        //
    }
    //    
}


И это безобразие лучше чем using?
... << RSDN@Home 1.2.0 alpha rev. 784>>
Re[6]: Смотри шире
От: remark Россия http://www.1024cores.net/
Дата: 14.12.07 15:08
Оценка:
Здравствуйте, Константин Б., Вы писали:

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


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

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

КБ>Каким образом? Кто запретит разработчику создать lock в куче?



Согласен. С форсированием я погорячился. Тогда скажем так:
С using по-умолчанию получается некорректный код, что бы получить корректный надо приложить усилия.
Со стеком по-умолчанию получается корректный код, что бы получить некорректный надо приложить усилия.
Возможно, это даже лучше полного форсирования.
К тому же можно закрыть operator new, тогда некорректное использование станет ещё сложнее.



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


КБ>Со стековыми объектами тоже самое:

КБ>
КБ>{
КБ>    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();
КБ>        }
КБ>        //
КБ>    }
КБ>    //    
КБ>}
КБ>


КБ>И это безобразие лучше чем using?



Тем, что в большинстве случаев эти скобки и отступы не нужны. Особенно при наличии commit()'a.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[5]: Смотри шире
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.07 15:40
Оценка: +1
Здравствуйте, remark, Вы писали:

R>Это ни о чём не говорит. Возможно разработчики просто его не применяли.


С то же вероятностью С++-программист может создавать стековые хелперы через new или запихивать их в динамически создаваемые объекты. Это не серьезно. Компилятор обложен тестами и утечек ресурсов в нем не замечено.

К тому же я работал далеко не над одним проектом и все было очень похоже. Более того я обычно вообще старался избегать using-ов. Например, если заранее известно, что файлы не будут большим, то я скорее считаю его в память одним вызовм File.ReadAllText()\File.ReadAllLines().
Кроме того есть еще один интересный подход.
Обычно ресурсы вроде файлов обрабатываются последовательным перебором. При этом их или используют в foreach-е или применяют к ним разные фунции вроде Map(), Iter(), Fold() и т.п. Так вот если сделать для подобного ресурса оболочку реализующую IEnumerable<тип перечисляемого ресурса>, то освобождение ресурсов будет производиться автоматически. Делается подобная обертка на раз. Вот смотри как может выглядеть оболочка для построчного чтения текстового файла:
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();
  }
}

Оба варианта применения вызывают Dispose() автоматически.

Все это нужно для блокирующих ресурсов вроде файлов. Для соеденений с БД вполне полходит использование финалийзеров.
В общем, не та это проблема чтобы о нее пытаться лоб разбить. Била бы она актуальна, ее бы давно решили. Ну, или все бы давно использовали C++/CLI вместо Шарпа и Немерла. Меж тем все с точностью до наоборот.

R>У того, кто использует компонент, мотивация не использовать using — надо писать дополнительные строчки кода + дополнительный отступ.

R>У того, кто разрабатывает компонент, мотивация не предоставлять объекты, которые можно использовать в using — нет гарантии, что их будет кто-то использовать. using — это не более необязательного синтаксического сахара.

Это не более чем пустые слова. Если бы они были не пыстыми, то весь дотнетный форум был бы завален вопросами по утечкам ресурсов. Меж тем подобными вопросами завален форум по С++.

R>Я не согласен с твоими утвержедниями:

R>1. стековые объекты нужны крайне редко, если есть GC
R>2. у стековых объектов есть какие-то проблемы, когда время жизни больше времени работы функции

Не согласен, так не согласен. Всегда есть море теоретиков несогласных с чем угодно. Попробуй, через годик расскажешь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Смотри шире
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.07 15:40
Оценка: -2
Здравствуйте, remark, Вы писали:

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


Слушай, уж не приверженцам С++ о размерах кода писать. Не тот язык.

К тому на разработку и соблюдение стратегий управления памяти в С++-программах тратится так много времени разработчиков, что скорость разработки С++-программ становится просто черепашьей. И при этом каждая вторая С++-ная программа "течет" как дырявый самовар.

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


Тебе виднее. В моих программах такого нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Сборщик мусора и размещение объектов в стеке
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.07 15:40
Оценка:
Здравствуйте, remark, Вы писали:

R>
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>



R>Не говоря о том, что using это всё ещё просто сахар, который можно забыть, а стековый объект — способ форсирования корректного использования.


Попробуй на досуге так:
void f()
{
    using (lock l1 = m1.lock(), l2 = m2.lock())
        using file f = open_file()
        {
                //...
        }
}

Кстати, для блокировок никаких внешних примитивов использовать не надо. В Ява и дотнете блокировки можно делать на любых объектах и без создания каких-то левых переенных:
lock(obj)
{
    ...
}


В прочем, мое мнение — многопоточность на явных блокировках и разделяемых ресурсах — это путь в ад.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: LOL
От: remark Россия http://www.1024cores.net/
Дата: 14.12.07 16:36
Оценка: 11 (2) :)))
Здравствуйте, VladD2, Вы писали:

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



Помедитируй над этим С++ кодом, и почувствуй какой бред ты говоришь. Подсказка: здесь есть не менее 5 выделений/освобождений памяти, программа течёт не более, чем аналогичная на Java/C#/Nemerle/Ocaml, программа безопасна при возникновении исключений, вся память освобождается синхронно при завершении функции. Так же подумай, сколько времени я затратил на управление памятью в этой абсолютно не текущей программе.


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




1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: Сборщик мусора и размещение объектов в стеке
От: remark Россия http://www.1024cores.net/
Дата: 14.12.07 16:46
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Попробуй на досуге так:


Задача была — впихнуть между захватами ресурсов ещё стейтменты.


VD>Кстати, для блокировок никаких внешних примитивов использовать не надо. В Ява и дотнете блокировки можно делать на любых объектах и без создания каких-то левых переенных:



Да, я знаю. Эта одна из причин, по которым программы в этих языках жирные, и не получается делать красивый ретейловый софт...



VD>В прочем, мое мнение — многопоточность на явных блокировках и разделяемых ресурсах — это путь в ад.



Передача сообщений, кстати, всегда реализуется через "разделяемые ресурсы" на SMP/multicore машинах. Хороший вопрос — почему?



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: LOL
От: WolfHound  
Дата: 14.12.07 17:01
Оценка: +1 -1
Здравствуйте, remark, Вы писали:

Хватит, а?
Ты тут далеко не один на С/С++ пишешь.

R>Помедитируй над этим С++ кодом, и почувствуй какой бред ты говоришь.

Бред тут говоришь ты.

R>Подсказка: здесь есть не менее 5 выделений/освобождений памяти,

В аналогичном коде на C# одно выделение памяти. (то что происходит в f2 не учитываем)

R>программа течёт не более, чем аналогичная на Java/C#/Nemerle/Ocaml, программа безопасна при возникновении исключений, вся память освобождается синхронно при завершении функции.

В том что память освобождается синхронно никаких преимеществ нет.
Скорее одни проблемы... скажем нужно мъютексом лишний раз щелкать...

R>Так же подумай, сколько времени я затратил на управление памятью в этой абсолютно не текущей программе.

В примитивных случаях все действительно просто (хотя если вспомнить про то сколько вариантов реализации std::string ).
Но как только дело доходит то чегото посложнее.
Скажем завернуть сишную либу в нетекущий интерфейс и чтобы оно при этом не тормозило
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: LOL
От: remark Россия http://www.1024cores.net/
Дата: 14.12.07 17:10
Оценка: :)
Здравствуйте, WolfHound, Вы писали:


R>>Подсказка: здесь есть не менее 5 выделений/освобождений памяти,

WH>В аналогичном коде на C# одно выделение памяти. (то что происходит в f2 не учитываем)

В С++ тоже может быть одно


R>>программа течёт не более, чем аналогичная на Java/C#/Nemerle/Ocaml, программа безопасна при возникновении исключений, вся память освобождается синхронно при завершении функции.

WH>В том что память освобождается синхронно никаких преимеществ нет.
WH>Скорее одни проблемы... скажем нужно мъютексом лишний раз щелкать...

Ничем щёлкать не надо


R>>Так же подумай, сколько времени я затратил на управление памятью в этой абсолютно не текущей программе.

WH>В примитивных случаях все действительно просто (хотя если вспомнить про то сколько вариантов реализации std::string ).


Как реализация std::string отразится на этом код? На его семантике? Утечкам?
С++ программист хотя бы знает про реализацию строки, которую он использует


WH>Но как только дело доходит то чегото посложнее.

WH>Скажем завернуть сишную либу в нетекущий интерфейс и чтобы оно при этом не тормозило


А какие проблемы? Таких примеров тонны. Погляди С++ обёртки к популярным либам типа libxml2, pqsql.
Про "тормозило" вообще не понятно. На современных компиляторах ран-тайм цена такой обёртки — 0 тактов процессора, 0 байт оперативной памяти, 0 байт размера выполняемого файла.



Ну так по сути-то что? Где эта программа течёт? Или как сильно это затормозило разработку?



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re: Сборщик мусора и размещение объектов в стеке
От: IT Россия linq2db.com
Дата: 14.12.07 17:13
Оценка: +1
Здравствуйте, PC Car, Вы писали:

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


Зачем что-то ещё? Используй тот же using.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: LOL
От: remark Россия http://www.1024cores.net/
Дата: 14.12.07 17:53
Оценка:
Здравствуйте, WolfHound, Вы писали:

R>>Помедитируй над этим С++ кодом, и почувствуй какой бред ты говоришь.


WH>Бред тут говоришь ты.


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



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[9]: LOL
От: WolfHound  
Дата: 14.12.07 18:16
Оценка: +1
Здравствуйте, remark, Вы писали:

R>В С++ тоже может быть одно

И куча щелканей interlocked функциями... а они всетки не дешевы.

R>Ничем щёлкать не надо

При освобождении памяти в многопоточной программе надо.

R>Как реализация std::string отразится на этом код? На его семантике? Утечкам?

На этом коде никак.
Но Влад говорил не об этом.
Влад говорил о том что кто-то очень долго и нудно думал какже эту строку реализовать.

R>С++ программист хотя бы знает про реализацию строки, которую он использует

Нормальные программисты на C# тоже.

R>А какие проблемы? Таких примеров тонны. Погляди С++ обёртки к популярным либам типа libxml2, pqsql.

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

R>Ну так по сути-то что? Где эта программа течёт? Или как сильно это затормозило разработку?

По сути ты просто не знаешь что значит работать в среде где про управление памятью задумыватся не нужно.
Вот и говоришь всякую ерунду.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: LOL
От: WolfHound  
Дата: 14.12.07 18:16
Оценка:
Здравствуйте, remark, Вы писали:

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

Они проводят очень не маленькую часть своего времени за обдумыванием того как эти утечки недопустить.
Прикладники которые тупо педалят код на std::string'ах меньше.
Писатели библиотек больше.
Но тратят все.
В то время как программисты на C# или Java про управление памятью ваще не думают.
Максимум в совсем клинических случаях ключики GC крутит.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: LOL
От: remark Россия http://www.1024cores.net/
Дата: 14.12.07 18:51
Оценка: 7 (2) +1
Здравствуйте, WolfHound, Вы писали:

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


R>>В С++ тоже может быть одно

WH>И куча щелканей interlocked функциями... а они всетки не дешевы.

Если ты имешь в виду interlocked в функции освобождения памяти, то если одно копирование, то и interlocked один


R>>Ничем щёлкать не надо

WH>При освобождении памяти в многопоточной программе надо.

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




R>>Как реализация std::string отразится на этом код? На его семантике? Утечкам?

WH>На этом коде никак.
WH>Но Влад говорил не об этом.
WH>Влад говорил о том что кто-то очень долго и нудно думал какже эту строку реализовать.

Это достаточно тривиально при наличии небольшого опыта.
Вот гляди — вот небольшая полностью безопасная обёртка для ресурса, которой можно пользоваться годами без каких либо утечек и дополнительных затрат времени:
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;



Всё это чистая механика. Всё делается полностью по шаблонам. Никакой фантазии.



R>>А какие проблемы? Таких примеров тонны. Погляди С++ обёртки к популярным либам типа libxml2, pqsql.

R>>Про "тормозило" вообще не понятно. На современных компиляторах ран-тайм цена такой обёртки — 0 тактов процессора, 0 байт оперативной памяти, 0 байт размера выполняемого файла.
WH>Можно конечно тупо понаписать тупых ScopeGuard'ов но ими пользоватся не удобно.

А от них сильно много и не требуется...


R>>Ну так по сути-то что? Где эта программа течёт? Или как сильно это затормозило разработку?

WH>По сути ты просто не знаешь что значит работать в среде где про управление памятью задумыватся не нужно.
WH>Вот и говоришь всякую ерунду.


Ну давай я ещё раз приведу свой пример:
string f(string s)
{
  string s2 = f2();
  return s + s2 + "!";
}


Попробую сформулировать так: С++ позволяет большую часть времени не задумываться об управлении памятью. Если в начале проекта потратить пару дней на создание некого общего инструментария, либо возможно он уже есть у программиста/компании, то об управлении памятью можно не задумываться 99.9% времени. Но тем не менее, и это имхо сильная сторона, об управлении памяти хотя бы можно задуматься при большой необходимости.
И ещё раз повторюсь: обеспечивается гарантия отсутствия утечек не меньшая чем в других современных языках, обеспечивается полная безопасность при возникновении исключений.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[11]: LOL
От: WolfHound  
Дата: 14.12.07 19:09
Оценка: +1 -1
Здравствуйте, remark, Вы писали:

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

R>Если ты имешь в виду interlocked в функции освобождения памяти, то если одно копирование, то и interlocked один

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

R>В этом основное отличие программистов на языках с наличием семантических барьеров от программистов на языках без наличия семантических барьеров.

Сколько пафоса то...

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

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

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

R>







Это потом не настанет никогда.

WH>>Можно конечно тупо понаписать тупых ScopeGuard'ов но ими пользоватся не удобно.

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

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

В тривиальных случаях.

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








Наивный чукотский юноша. Я несколько лет назад тоже таким был.

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

Конечно же меньшая.
С этим спорить бессмысленно.
Это факт.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.