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

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

И если вы сами явно где нибудь не дернете free, сишный мьютекс так и не пустит поток.

У С все хорошо с полнотой языка, поэтому сделать на нем получится все. Другой вопрос, какой ценой.

Ну покажите мне, как на pure C реализовать автоматический захват ресурса - допустим, выделить память под структуру.
А потом, когда закончится время жизни указателя - автоматически освободит ресурс.

Lukkoye, если трактовать raii как паттерн, исключительно основанный на автоматическом вызове конструктора/деструктора, то да. ближе к ООП он от этого не становится

Вы путаете наследование и агрегирование.
Наследования на pure C не существует.

надо просто создать дополнительный контекст, владеющий ресурсом. с точки зрения внутренней функции use() все происходит автоматически 


Добавлено через 3 минуты и 12 секунд
естественно, можно написать более изощренный пример, позволяющий use() влиять на создание объекта. только это многословней

Это сообщение отредактировал(а) baldina - 3.4.2014, 22:56

Я не совсем понимаю фразу "трактовать raii как паттерн".

Слово "паттерн" я понимаю, как "решение", которое наиболее практичным образом решает некоторую проблему.

raii (Resource Acquisition Is Initialization) я понимаю, как идеому: получение ресурса - есть инициализация.

Суть которой - автоматический захват ресурса, и автоматическое же его освобождение.

Из этого вытекает важнейшее следствие: раии-механизмы позволяют простым способом контролировать вопросы владения и времени жизни объектов.

Собственно это главное и единственное, что вообще требуется от raii.

При этом raii - это не только автоматические вызовы конструкторов/диструкторов.

У этой концепции есть более широкая область применения.

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

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

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

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

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


Резюмируя: идеома raii - это идея, как можно очень легко и просто контролировать вопросы владения и времени жизни объектов.

Добавлено через 1 минуту и 29 секунд


Я просил автоматику.

Меня не интересует точка зрения функции use
Меня интересует точка зрения программиста, которому нужно вручную дергать 

construct (obj);
destruct (obj);

И не дай боже этого забывать.

Это ни разу не автоматика.

программист пишет только use(). внешнюю функцию написали за него и для него (или он сам, в рамках решения не прикладной задачи, а подготовки низкоуровневого слоя). ясно, что в С где-то придется вызвать вручную.

название "raii" это идиома. raii в отношении к с++ это паттерн. в отношении к любым языкам - это концепция единственного владельца ресурса. и вот эту концепцию можно реализовать в любом языке

Это сообщение отредактировал(а) baldina - 3.4.2014, 23:22

У вас последнее предложение противоречит первому.
Кто-то вручную должен написать construct и destruct.

Это уже не автоматика. 
И если ближе к реальной практике, то весь pure C - это один сплошной низкоуровневый слой.

Для сишника - выделить память, чем то её заполнить, а потом освободить - это обычная рутинная работа.
И сишник знает - кроме него самого, никто это это за него не сделает.
И ни одна сишная программа без этого не обходится.




Вот мне не понятно: в отношении к с++, как понять "raii -это паттерн" ?

Как вариант:





Только 1) нужно придерживаться определенного соглашения и 2) при возникновении аварийной ситуации (сегфолт например) внутри body, деструктор не вызовется (насколько я понимаю).

k0rvin, awesome !
Лямбда ни Си. ЗдОрово !

Это сообщение отредактировал(а) borisbn - 4.4.2014, 10:25

Ну что ж, в таком случае есть универсальный ответ: на C можно написать компилятор C++. Исходные коды приводить не будем ввиду их объемности.   

О чем Lukkoye уже сказал здесь.

Это сообщение отредактировал(а) k0rvin - 4.4.2014, 10:42

Ага. Но вот где проходит граница между "можно реализовать на самом языке" и "нельзя реализовать на самом языке" - вопрос открытый. 

Очевидно, что если можно написать компилятор, то можно и интерпретатор, а это означает, что все те же средства принципиально возможно приделать и к программе на C. Следовательно, имеет смысл обсуждать только вопрос о том, насколько это удобно.

На самом языке - на уровне исходного текста программ, которые пишутся на этом языке


Пример:

с++2003 стандарт не поддерживает оператор decltype. В коробке с гцц идет в поставке оператор typeof, но лишь, как расширение от компилятора.
Стандартного средства не существовало.

Реализовать самодельный typeof кросскомпиляторно, который предоставлял бы полную автоматику (как decltype) было не возможно.

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



Ну так вот, с++11 decltype - это технология новых компиляторов.
Программист может пользоваться и не геммороится о том, кто и как ему эту возможность обеспечивает.

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

Итого: 
с++03 не поддерживает технологию decltype , и реализовать её в полноценном виде на языке невозможно. Можно сделать лишь сильно ограниченные костыли-велосипеды.
с++11 поддерживает технологию из коробки. Программист может просто пользоваться и не париться.



Это сообщение отредактировал(а) Lukkoye - 4.4.2014, 13:42