Ты просто еще не проникся дзеном простоты, не понимаешь всего величия и фундаментальности безусловных переходов! :lol:

Для некоторых личностей - скорее цель ;)

только с одной целью - впилить туда всеми правдами и неправдами RAII

Добавлено 22.07.20, 02:50
:jokingly: А если он ещё и работает...

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

Но при такой практически нулевой вероятности - предусматривать последующий рефакторинг как минимум странно. Лучше уж к врачу паранойю лечить :)

Да не вопрос. Я может быть его и на гитхаб выкину (кстати, переписываю его без Qt), . Потому как норм библиотеки для SFTP нету. А платные я покупать не намерен! Вот там и форкнешь.

Нет, это единый процесс! :) Полу-логина не бывает.

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

Это не лапша

Это не единый процесс

Вот тебе нужно будет поменять что-то в коде load

Во всех мануалх и бест-практиках твердят: используйте инструментарий там, где это уместно.

искусственное разбиение единого процесса

Короче. Возвращаюсь к goto. Ваши попытки - неубедительны :lol:

Если тебе нравится лапша в коде, то кто ж тебе помешает?

Поэтому - гвардов вполне достаточно, хоть и таких мудреных с if-фами.

1) winsock_class - WSAStartup /WSACleanup();
2) libssh2_class - libssh2_init / libssh2_exit
3) resolv_slass - getaddrinfo / freeaddrinfo <----------------- можно не хранить, т.к. резольвится один первый раз
4) socket_class - socket / closesocket
5) connect_class - connect / shutdown
6) libssh2_session_init_class - libssh2_session_init / libssh2_session_free
7) libssh2_sftp_sesstion_class - libssh2_sftp_init / libssh2_sftp_shutdown

1) Ты собираешь независимые ресурсы в свой wrapper (хотя логичнее назвать holder). У меня они зависимые. Т.е. результат одного передается в инициализацию другого. Но и это не главное.
2) Один (или несколько, пока один) из ресурсов у меня "временный" и его хранить не нужно. Т.е. r1,rc2, rc3, rc4 проинициализировали, все rc3 уже не нужен, удалили, потом - rc5, rc6

3) Ну и самое наверное важное - ты решил в свой wrapper запилить в конструкторе больше чем нужно. Т.е., как объект создается - так он сразу бежит логиниться. Такое мне не нужно!

Но я понимаю, к чему ты клонишь - раздербанить мой sftp_class в целую "инфраструктуру", типа:

winsock_class - WSAStartup /WSACleanup();
libssh2_class - libssh2_init / libssh2_exit
resolv_slass - getaddrinfo / freeaddrinfo
socket_class - socket / closesocket
connect_class - connect / shutdown
libssh2_session_init_class - libssh2_session_init / libssh2_session_free
libssh2_sftp_sesstion_class - libssh2_sftp_init / libssh2_sftp_shutdown

Потом мне придется писать такую же портянку исключений, чтобы понять кто бросил, и можно ли продолжить работу ( допустим сделать еще 3 попытки соединения)

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

На ка тебе пример еще в догонку, расскажи пожалуйста что тут работает не так, как ты описал? Очень интересно послушать.

В твоем варианте - обеспечить передачу владения.

Но раз, ты нагородил еще более моего

В моем варианте - обеспечить неудаление нужного. В твоем варианте - обеспечить передачу владения. Что по сути звучит. и то, и то одинаково: не потерять лишнее.

В данном случае никаких противоречий не вижу. Класс изначально проектировался для соблюдения состояний:

1) Ожидает
2) В состоянии соединения
3) В состоянии ошибки
4) В состоянии передачи

Причем возможные переходы между состояниями заранее предопределены. В этом случае инвариантность не нарушается.

Плохая практика, не надо так делать. Прочитай про инварианты класса.

Инвариа́нт — это свойство некоторого класса (множества) математических объектов, остающееся неизменным при преобразованиях определённого типа.

Ну так это не RAII

наверное можно было бы и всю лямбду в макро загнать?

Сколько ждали появления в плюсах лямбд и auto?

Ну так scope(...) и надо применять только в таких случаях. Я же говорил много раз.

Я хз как такое можно забыть. Ты же вот прямо только что выделил память, и если ты не страдаешь склерозом, в голове автоматом возникает мысль: "надо освободить ресурс", и ты тут же пишешь scope(exit). С таким же успехом ты можешь забыть написать кастомный делетер в unique_ptr. Вот если у тебя такое встречается много раз, то уже становится неудобно, но в таких случаях и unique_ptr с кастомным делетером становится неудобным.

Конечно корректно, ведь конструирование происходит до scope(exit), соотвественно, если при конструировании произошло исключение, то scope(exit) не отработает. Разве это не очевидно?

Установили соединение
Открыли базу
Начали получать доступ к таблице - исключение

scope(exit){
Очистили ресурсы от таблицы
Закрыли Базу
Закрыли соединение
}

Он положился на scope и scope сделал ровно то, что он и ожидал, не больше не меньше. Его "обманул" GC, а не scope.

Неверно. scope(exit) и GC - вещи ортогональные. В моем же примере с PQClean, GC вообще никак не используется. И повторю еще раз: scope(...) может работать не только с ресурсами (в частности не только с памятью). И также повторю, что все парадигмы C++, в том числе и RAII работают и в D. Ну и какой это сахар, если для его реализации в плюсах надо маленькую либку написать, что и сделал Qraizer.

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

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

Но ведь разные есть случаи, я понял бы если бы это была единная конструкция, хотя бы там через точку например. Но понимаешь ли, бывает так что пишешь new int, и тут же забываешь сделать delete, потому что это две конструкции, независимы друг от друга семантически. Так и тут.

Тут как бы и коню понятно что до второго scope оно не дойдет. Корректно ли отработает первый scope, если исключение произошло на этапе конструирования сложного объекта, вот в чем вопрос.

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

Я его притащил - показать с какими проблемами можно столкнуться, полностью положившись на него.

В С++ нет scope, потому что там нет GC, а в D есть GC, поэтому там и scope актуален. Для С++ этот scope(exit) - не более, чем синтаксический сахар.

но например тотже try-with-resources/using

Да и в такие языки любят тащить все попало, но scope(exit) - я там как то не встречал. Видимо даже там разрабы посчитали - что излишне вводить то, что уже есть в языке.

Ну так они и пишут, в деструкторах оберток и кастомных делетерах unique_ptr.

Нет в сяшке не тот же. Вызовуться только те scope(), которые успели отработать. Поведение scope(exit) в плане очистки ресурсов полностью совпадает с unique_ptr с кастомным деструктором. Похоже, ты не совсем понял оно работает. Вот посмотри очень короткий пример: https://run.dlang.io/is/7jJE7b

Я это понял так, что ты решил, что scope(exit) как-то влияет на это.

Ну я не тащил сюда всякие странные багнутые куски кода. А так да, в C++ нет scope, но есть RAII, а в D есть и scope и RAII.

Я не сразу понял. Когда я писал try/catch/finally я имел в виду совокупность всех возможных комбинаций и так же понял и твое try/catch/finally.
Важно понимать, что scope(success)/scope(failure)/scope(exit) похожи на try/catch/finally, но отличия достаточно большие.

А with*-функции используют?

Это освобождение в моей обертке фигурировало буквально внутри одной функции.

Если мы это сделаем, то это будет уже другой подход. Понимаешь?

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

Я тебя уже просил привести свое определение термина "костыль".

Если ты используешь scope(exit) просто в реализации bracket pattern, то для работы с ресурсом ты используешь bracket pattern, а не scope(exit), понимаешь? scope(exit) у тебя просто часть реализации, там вооще мог быть try...catch, это не имеет принципиального значения
Впрочем, я писал уже, что scope(exit) лучше finally, хотя и не принципиально.

Тогда двай уж и scope(exit) вынесем в отдельную функцию

И знаешь чем второе лучше первого?

Нет бесполезного и странно выглядящего для людей не знающих C++ объявления переменной lock, которая нигде потом явно не используется.

Самый что ни на есть настоящий костыль.

заверни scope(...) в отдельную функцию (получится тот же using/with/try-with-resources, только лучше, потому что гибче) или делай RAII.

Это как сказать, что вездеход лучше автомобиля, потому что вездеход может быть точно также использован для езды по болотам. :lol:

Да

Вот. Собственно это и есть тот критерий, который оправдано можно закостылить scope()ом...

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

Может быть иногда и не удобно, но всегда надёжно.

Исполнение данных тобой инструкций – да, автоматическое. С этим и __attribute__((__cleanup__())) справляется. Интересно, почему его не включали в Стандарт C? Это же так удобно, по твоим словам.

и ещё Zig, например

А ты разве не такой пример привел?

Не согласен, он все равно лучше, чем явный defer/scope(exit).
Классический пример скоупа - блокировка.

Верно. И к этому примеру никаких претензий, это аналог RAII, хотя и с ограничениями.
Но ты привел не этот код

Можно согласиться, что defer/scope(exit) лучше finally(хотя и не сильно).

Но еще лучше using/with/try-with-resources. Тем, что не нужно каждый раз указывать действие по освобождению.

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

Ну да, нахер юзать все эти RAII в плюсах. Вот дебилы, правда? че сложно написать delete ptr - где это нужно.

В Сяшке ровно тот же механизм, только вид с боку. Когда ты юзаешь мой любимый unique_ptr, то это полноценная RAII обертка, и она лишена практически всех недостатков. Например что будет у тебя, если во время выделения ресурса произойдет исключение? Будет очищать ресурс, который не существует?

Ну как не пишут, если пишут? Я ж даже ссылку привел на того, кто написал

сам по себе scope(exit) - Не влияет на порядок вызовов деструкторов, я нигде не утверждал что он влияет.

Ну и к слову, встречал что если класс в D создавать через new, то порядок вызовов с этим scope(exit) - уже не такой однозначный, а все из за GC, так что даже эта "плюшка" может запросто поломать программу.

Ага, с тебя взял пример. Ты же первый начал рассказывать как без него тяжко в плюсах жить

Ты как раз таки все понял, просто тебе видимо потроллить хочеца. Я слышал в Java его частенько называют именно так. И название идет от полной конструкции. Finally не фигурирует сам по себе. Так что ты тоже ошибся выходит, если цеплятся к словам, как ты любишь

А зачем так писать? Заворачиваем в функцию и вызываем сколько угодно раз не парясь об освобождении ресурса

А вот в случае когда нужен скоуп владеющий ресурсом, RAII зачастую совершенно излишен.

Ну так в моем случае оно тоже автоматическое.

А вот в случае когда нужен скоуп владеющий ресурсом, RAII зачастую совершенно излишен.

Угадай, как функциональщики без всяких RAII управляют, допустим, транзакциями в БД? :)

В таком случае вероятность забывания написания scope равна вероятности забывания написания деструктора. :)

Но я привожу примеры, где scope(exit) проще и понятнее и не менее безопасно, чем RAII.

scope это скорее про try/catch/finally.