Здравствуйте, a7d3, Вы писали:
A>Парадигмы в контексте программирования — это далеко не та сущность, которую можно обозначить «неким устоявшимся в обществе набором взглядов».
С каким же упорством вы отвергаете реальность. Просто удивительно.
A>Типа что нет ООП без соблюдения трёх условий (наследование, полиморфизм, инкапсуляция).
Очевидно, что вы не в курсе, что даже определение "наследование, инкапсуляция, полиморфизм" -- это всего лишь одно из.
Как и не в курсе, что даже в рамках этого определения для программирования в ОО-стиле не обязательно выполнения всех трех "условий". Запросто можно ограничится инкапсуляцией+наследованием или наследованием+полиморфизм.
Здравствуйте, a7d3, Вы писали:
A>Здравствуйте, C0x, Вы писали:
C0x>>Я извиняюсь, но не работает "Делегирующие конструкторы" в моем коде. У меня вся архитектура построена на стэковых объектах и ссылочной связи между ними. Делегирующий конструктор если я правильно понимаю нельзя вызывать если у меня в классе в полях ссылки есть. Меня свой подход я не собираюсь ради вызова делегирующего конструктора.
A>>>Да и глупо заниматься творчеством (отсебятиной). Особенно, так толком и не освоив инструментарий (С++), и на том поприще, где уже тридцать лет толкутся миллионы людей.
C0x>>Я творчеством занимался еще до того как в STL Си++ появились нормальные смартпоинтеры и делегирующие конструкторы. После 10-ти летней паузы не все стандартны успел изучить. Поэтому кстати и пришел сюда, со своей бедой.
A>стэковые объекты — это какой-то свой собственный изобретённый термин или же неказистая попытка обозначить экземпляры классов находящиеся на стэке, а не в динамически выделяемой памяти (heap'е)?
для особо ограниченных плюсовиков (в смысле любителей самоограничений) я постараюсь расширить твои границы и предложить пройтись для начала в Гугл stack objects
A>Что это за болезненное стремление нагородить колхозной мутоты по мере освоения какого-то инструмента?
A>Именно таким образом и выглядит поведение в этом треде.
Именно таким оно выглядит только в твоей голове, ни больше не меньше.
A>Зато теперь понятно, от кого защищаются собеседующие, когда просят прислать им примеры кода на том или ином языке программирования.
Утикакой! Не взяли на очередное собеседование? Вот почему ты самоограничениями так обложился.
Меня собеседования не волнуют уже лет 10, я давно уже сам решаю как писать программы и на чем. А ты не завидуй!
А вообще я не понимаю ну не взяли на собеседование, чего срываться то на коллегах???
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, a7d3, Вы писали:
A>>Парадигмы в контексте программирования — это далеко не та сущность, которую можно обозначить «неким устоявшимся в обществе набором взглядов».
S>С каким же упорством вы отвергаете реальность. Просто удивительно.
A>>Типа что нет ООП без соблюдения трёх условий (наследование, полиморфизм, инкапсуляция).
S>Очевидно, что вы не в курсе, что даже определение "наследование, инкапсуляция, полиморфизм" -- это всего лишь одно из. S>Как и не в курсе, что даже в рамках этого определения для программирования в ОО-стиле не обязательно выполнения всех трех "условий". Запросто можно ограничится инкапсуляцией+наследованием или наследованием+полиморфизм.
Вот только «программирование в ОО-стиле», это далеко не тоже самое, что парадигма ООП.
Здравствуйте, C0x, Вы писали:
C0x>Здравствуйте, a7d3, Вы писали:
A>>стэковые объекты — это какой-то свой собственный изобретённый термин или же неказистая попытка обозначить экземпляры классов находящиеся на стэке, а не в динамически выделяемой памяти (heap'е)?
C0x>для особо ограниченных плюсовиков (в смысле любителей самоограничений) я постараюсь расширить твои границы и предложить пройтись для начала в Гугл stack objects
Не надо так переживать и дёргаться. Ничего страшного, к 20-25 годам опыта этот гонор со снобизмом уходят. Вырабатывается привычка уточнять, что же именно собеседник пытается сообщить, что конкретно имеет в виду.
Это когда за плечами лишь полторы книжки прочитанных, тогда и кажется, что все на одном языке говорить должны/обязаны, в рамках какого-то одного набора терминов с определениями.
Здравствуйте, so5team, Вы писали:
S>Мне вот интересно, как вы классифицируете следующую ситуацию:
Что сотрудник решивший экспортировать С++ классы из DLL'ок подлежит увольнению, за вопиющую профнепригодность.
Если это в США, то в течении двух минут после обнаружения данного творчества в продакшен коде.
Здравствуйте, a7d3, Вы писали:
A>Здравствуйте, C0x, Вы писали:
C0x>>Здравствуйте, a7d3, Вы писали:
A>>>стэковые объекты — это какой-то свой собственный изобретённый термин или же неказистая попытка обозначить экземпляры классов находящиеся на стэке, а не в динамически выделяемой памяти (heap'е)?
C0x>>для особо ограниченных плюсовиков (в смысле любителей самоограничений) я постараюсь расширить твои границы и предложить пройтись для начала в Гугл stack objects
A>Не надо так переживать и дёргаться. Ничего страшного, к 20-25 годам опыта этот гонор со снобизмом уходят.
О наконец-то дошло дело до меряния пиписьками. У меня всего 15 лет проф.опыта, поэтому я пока не дотягиваю.
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, kov_serg, Вы писали:
_>>>>Гораздо логичнее что бы за все ресурсы, которые использует объект, отвечал не он, а тот кто заставил его работать. σ>>>https://youtu.be/rwOv_tw2eA4?t=1611 _>>Нет, я имею ввиду что в языке должна быть возможность отанавливать потоки не переводя программу в UB. _>>И всё сваливать на RAII это не очень хорошо. С++ никогда не сможет работать на оборудовании со сбоями. _>>Мне больше такой подход нравиться.
BFE>Почему это никогда? Если в С++ добавят std::process и он будет достаточно легким (легковесным), то отличия от Эрланга будут косметическими.
BFE>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1750r0.pdf
Поржал. Запуск нового процесса — легковеснная операция (особенно в винде — сотни миллисикунд).
Дело не в процессах, и не в стандарте c++, а в posix runtime. runtime должен быть контектозависимый, а не глобальным. так что бы родитель мог контролировать то чем и как пользуется порождаемый подпрограмма или поток. А пока можно похвастаться только разнобразием UB.
Здравствуйте, Maniacal, Вы писали:
M>Здравствуйте, so5team, Вы писали:
S>>Здравствуйте, Maniacal, Вы писали:
M>>>А в конструкторе не надо исключения кидать. Это моветон.
S>>И давно это стало моветоном?
M>Меня по рукам с института били за это. Просто плохая идея, хуже только указатель this в конструкторе использовать.
Странно так ограничивать любой конструктор. Default или move — это еще можно понять.
Любое выделение памяти в конструкторе — это как минимум возможность std::bad_alloc.
Многие конструкторы std::vector и std::string делают аллокации и потенциально кидают исключения.
Так что, не использовать вектора и строки как члены данных в своих классах?
Здравствуйте, qaz77, Вы писали:
M>>Меня по рукам с института били за это. Просто плохая идея, хуже только указатель this в конструкторе использовать.
Q>Странно так ограничивать любой конструктор. Default или move — это еще можно понять.
Не стоит принимать всерьез. Очевидно, что человек "слышал звон, но не знает где он"
Здравствуйте, Maniacal, Вы писали:
M>Есть такая книжка хорошая, только не помню как называется, что-то типа "С++ для профессионалов", что-то то там про количество советов было в названии.
я прочёл все хорошие книжки типа "C++ для профессионалов", в т.ч. где про количество советов было в названии, и ни в одной из них не было запрета на выброс исключений из конструктора.
Здравствуйте, Maniacal, Вы писали:
M>Ты меня сиплюсплюсника с двадцатилетним стажем
ИМХО, это вот главная трудность.
Ну то есть, условно говоря, сеньер с 20+ стажем что-то такое узнал в своем профессиональном "детстве", запомнил, и все 20 лет применяет,
а это — бац — и неверно оказалось, ну или просто бессмысленно.
Я так с одним уважаемым человеком несколько лет бодался насчет delete для указателя со значением nullptr.
Ни в какую не хотел убеждаться. Ни ссылки на стандарт, ни апелляции к здравому смыслу — не помогали.
Тут не что-то подобное? Может ну его этот стаж-то, может просто разобраться в теме надо, а не слепо верить установкам 20-летней давности?
Я вот так, кстати, однажды тоже через себя переступил и обнаружил, что не допускается, оказывается, по стандарту С и С++ разрядность char меньше 8-ми бит.
А ведь все 20+ лет был уверен, что может быть такое, я ведь даже машины с 4-х разрядными регистрами этими вот своими руками трогал.
Здравствуйте, kov_serg, Вы писали:
_>>>Мне больше такой подход нравиться. BFE>>Почему это никогда? Если в С++ добавят std::process и он будет достаточно легким (легковесным), то отличия от Эрланга будут косметическими. _>Поржал. Запуск нового процесса — легковеснная операция (особенно в винде — сотни миллисикунд). _>Дело не в процессах, и не в стандарте c++, а в posix runtime.
Расскажите, пожалуйста, про связь posix runtime с Эрланг.
_>runtime должен быть контектозависимый, а не глобальным. так что бы родитель мог контролировать то чем и как пользуется порождаемый подпрограмма или поток. А пока можно похвастаться только разнобразием UB.
Если у вас есть запуск процесса, то вокруг него можно навернуть любой контекст. Ничего особо сложного для С++ тут я не вижу. Если хотите запускать процессы в posix runtime контексте, то что же вам мешает?
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, a7d3, Вы писали:
A>>Вот только «программирование в ОО-стиле», это далеко не тоже самое, что парадигма ООП.
S>Доказывается это, традиционно для вас, аргументом "я так сказал", не правда ли?
Путать стиль программирования с парадигмой программирования допустимо лишь в среде АСУТПэшников. Людей привыкших работать топорно и толком не видевших в своей жизни ничего окромя промышленных линий на заводах и производствах.
Любой диспут на профессиональные темы всегда сводится к спору о терминах и определениях. Является ли этот факт открытием и насколько культурно проходят эти самые споры — это уже показатель/индикатор того, к каким социальным стратам относится визави.
Здравствуйте, Voivoid, Вы писали:
V>Здравствуйте, qaz77, Вы писали:
M>>>Меня по рукам с института били за это. Просто плохая идея, хуже только указатель this в конструкторе использовать.
Q>>Странно так ограничивать любой конструктор. Default или move — это еще можно понять.
V>Не стоит принимать всерьез. Очевидно, что человек "слышал звон, но не знает где он"
Били-то, небось, по рукам за исключение выбрасываемое из деструкторов.
Однако, система образования настолько замечательна, что потом в голове, по этому вопросу, конструкторы с деструкторами поменялись местами.
Здравствуйте, a7d3, Вы писали:
A>Путать стиль программирования с парадигмой программирования допустимо лишь в среде АСУТПэшников.
Как и предсказывалось, доказательство из категории "я так сказал".
Складывается впечатление, что "парадигма" для вас -- это нечто вроде физических законов или математических аксиом.
A>Является ли этот факт открытием и насколько культурно проходят эти самые споры — это уже показатель/индикатор того, к каким социальным стратам относится визави.
Поэтому, наверное, вы постоянно пытаетесь проехаться по личностям собеседников. Возможно, вы не можете пережить того, что не в состоянии предметно возразить какому-то колхознику из болот Полесья.
Здравствуйте, so5team, Вы писали:
S>Поэтому, наверное, вы постоянно пытаетесь проехаться по личностям собеседников. Возможно, вы не можете пережить того, что не в состоянии предметно возразить какому-то колхознику из болот Полесья.
Колхозник в данном случае упорно отказывается понять разницу между параллелограммом и прямоугольником, заявляя, что это одно и то же. А так же, что он и трапецию готов называть прямоугольником, ведь у неё столько же сторон и углов.
Лениво ему быть аккуратным в терминологии, держа в голове какие-то там эти все нафиг никому не нужные тонкости с нюансами. Даже когда предлагают перейти на использование термина «четырёхугольник», то всё равно пытается всех вокруг дерьмом полить.
Не со зла, конечно, а просто потому что иначе не умеет общаться, да и вообще — удобрение же, расти будет лучше.
Здравствуйте, wander, Вы писали:
W>Здравствуйте, Maniacal, Вы писали: W>ИМХО, это вот главная трудность.
Там все рога растут, насколько я помню, что до завершения работы конструктора не гарантирует полную инициализацию объекта. На этом всё. Нельзя к this обращаться и к мемберам нормально. А то может не повезти. И вообще эксепшн в конструкторе это как в анекдоте про бегемота "И правда, чего это я?!".
Здравствуйте, wander, Вы писали:
W>Тут не что-то подобное? Может ну его этот стаж-то, может просто разобраться в теме надо, а не слепо верить установкам 20-летней давности?
тут всё гораздо проще. Вся архитектура строится или на возвратах кода ошибки или на эксепшенах. В первом случае идея с эксепшенами в конструкторе проваливается с самого начала. Конструктор не возвращает кода. Думаю, тут прикладная проблема миграции кода на ООП. Но идея кидания исключений в недостроенном конструкторе интересна. Когда нет try-catch-finally (как в java) особенно. Каждый раз велосипед.
Здравствуйте, C0x, Вы писали:
C0x>Здравствуйте, a7d3, Вы писали:
A>>Здравствуйте, C0x, Вы писали:
A>>от любителя изобретать свои паттерны?... Моё раздражение вызвано тем, что в С++ вечно лезут кулибины...
C0x>Мдя... а как все хорошо начиналось...
