Здравствуйте, a7d3, Вы писали:
S>>Возможно, вы не можете пережить того, что не в состоянии предметно возразить какому-то колхознику из болот Полесья.
A>Колхозник в данном случае упорно отказывается понять разницу между параллелограммом и прямоугольником, заявляя, что это одно и то же. А так же, что он и трапецию готов называть прямоугольником, ведь у неё столько же сторон и углов. A>Лениво ему быть аккуратным в терминологии, держа в голове какие-то там эти все нафиг никому не нужные тонкости с нюансами. Даже когда предлагают перейти на использование термина «четырёхугольник», то всё равно пытается всех вокруг дерьмом полить.
Ибо возражая предметно вы бы могли сказать "стиль программирования -- это..., а парадигма программирования -- это..., исходя из чего стиль != парадигме".
Ну или вы могли вместо цитирования используемых вами (а это важно, т.к. используемые вами вовсе не обязательно окажутся общепринятыми, или хотя бы более-менее известными) определений вы могли бы дать ссылки на эти самые определения в других источниках.
Вот тогда бы было предметное возражение.
Но нет, вы не можете. Вы порождаете какой-то мутный поток собственных оценочных суждений, который отражает только бардак в вашей голове, а отнюдь не позицию вашего собеседника.
И так во всем споре. Особенно умиляет ваша позиция "я верю в некую неведомую ерунду, а вы мне покажите, где написано, что этой неведомой ерунды быть не может, но при этом ссылаться на авторитетов смешно". Это ведь игра, в которую можно играть вдвоем. Некто a7d3 может пить коньяк по утрам, а вечерам обнюхается кокаина и смотрит детское порно. И пусть мне приведут источники, в которых написано, что этого не может быть.
Здравствуйте, Maniacal, Вы писали:
M> Но идея кидания исключений в недостроенном конструкторе интересна. Когда нет try-catch-finally (как в java) особенно. Каждый раз велосипед.
Никаких велосипедов. Рекомендации по комфортной работе в этих условиях были даны еще в 1990-х: списки инициализации вместо ручного присваивания значений в конструкторе, индивидуальные RAII обертки для каждого подлежащего освобождению ресурса вместо ручной очистки ресурсов в деструкторе (что тут во множестве адекватных комментариев ТС-у и советуют).
Как за 20 лет стажа не узнать об этих рекомендациях...
Здравствуйте, Maniacal, Вы писали:
M>тут всё гораздо проще. Вся архитектура строится или на возвратах кода ошибки или на эксепшенах.
Вообще мой комментарий касался высказывания о моветоне и сделанных из этого выводов.
То, что, разумеется, при определенных стратегиях разработки некоторые инструменты могут не понадобиться или даже мешать, — это отдельный вопрос.
M>Но идея кидания исключений в недостроенном конструкторе интересна. Когда нет try-catch-finally (как в java) особенно. Каждый раз велосипед.
finally в С++ не нужен именно из-за RAII и деструкторов.
Здравствуйте, Maniacal, Вы писали:
M>.... Когда нет try-catch-finally (как в java) особенно. Каждый раз велосипед.
Какой велосипед? Это здравое разделение ответственности. Воплощение SRP в области управления ресурсами. А делегированный конструктор — средство языка, позволяющее воспользоваться стандартной схемой управления ресурсами — RAII.
Бесполезно вести диалог с человеком, который начинает «подгонять» определения, потому что спорил о парадигмах программирования, облажался несколько раз, но очень хочет отстоять собственную точку.
Если вы еще не в курсе, сами по себе "парадигмы" -- это как раз из категории "давно и широко известных вещей", т.к. парадигма -- это не свод строго проверяемых математически выверенных абстракций. А некий устоявшийся в сообществе набор взглядов. Сам факт фиксации этого набора взглядов в Wikipedia может считаться достаточным для того, чтобы считать GP именно что парадигмой.
Это уже «клиника», однозначно. Того разряда, когда солипсизм является симптомом.
Здравствуйте, Maniacal, Вы писали:
M>Здравствуйте, wander, Вы писали:
W>>Тут не что-то подобное? Может ну его этот стаж-то, может просто разобраться в теме надо, а не слепо верить установкам 20-летней давности?
M>тут всё гораздо проще. Вся архитектура строится или на возвратах кода ошибки или на эксепшенах. В первом случае идея с эксепшенами в конструкторе проваливается с самого начала. Конструктор не возвращает кода. Думаю, тут прикладная проблема миграции кода на ООП. Но идея кидания исключений в недостроенном конструкторе интересна. Когда нет try-catch-finally (как в java) особенно. Каждый раз велосипед.
Я не припомню когда в последний раз нужен был finally.
Всё обычно решается через try with resource в Java или using в C#.
A>Если вы еще не в курсе, сами по себе "парадигмы" -- это как раз из категории "давно и широко известных вещей", т.к. парадигма -- это не свод строго проверяемых математически выверенных абстракций. А некий устоявшийся в сообществе набор взглядов. Сам факт фиксации этого набора взглядов в Wikipedia может считаться достаточным для того, чтобы считать GP именно что парадигмой.
A>Это уже «клиника», однозначно. Того разряда, когда солипсизм является симптомом.
Для того, чтобы доказать, что это "клиника" и "солипсизм" следовало бы хотя бы привести ссылку на определение понятия "парадигма программирования", которого вы сами придерживаетесь (можно даже не обсуждать вопрос адекватности этого определения).
Здравствуйте, _NN_, Вы писали:
_NN>Я не припомню когда в последний раз нужен был finally. _NN>Всё обычно решается через try with resource в Java или using в C#.
На Java писал (по работе) последний раз в 2000 году, возможно, тогда таких конструкций в языке ещё не было. На C# пока писать не приходилось, но про using читал.
Но я уже понял, что ляпнул не подумавши. Смешал две вещи. Что не стоит использовать указатель this в конструкторе C++ (особенно в списке инициализации), ибо непредвиденный результат, в зависимости от реализации компилятора, и подход, когда код всегда возвращает код ошибки, а не бросает исключения (тут не надо быть капитаном очевидность, чтобы понять, что при таком подходе об исключениях речи идти не может, а конструктор это функция, которая ничего возвращать не должна, по-хорошему, но и тут есть нюансы).
Здравствуйте, so5team, Вы писали:
S>Для того, чтобы доказать, что это "клиника" и "солипсизм" следовало бы хотя бы привести ссылку на определение понятия "парадигма программирования", которого вы сами придерживаетесь (можно даже не обсуждать вопрос адекватности этого определения). S>Но вы и этого не смогли. S>Ожидаемо.
Важен сам факт того, что человек, испробовав ряд приёмов для защиты своего мировоззрения, так и не остановился, а пробил дно —дойдя уже до «подгонки» определений.
Очень странно выглядит, когда человек пытается в сфере программной инженерии разгуливать с определением парадигмы из научного мира. Игнорируя всю нелепость ситуации лишь потому, что это позволяет ему отстоять или как-то оправдать свою точку зрения.
Ни разу не похоже это всё на попытку сбросить накопившийся контекст и вести диалог уже в русле споров о терминах с определениях.
Здравствуйте, a7d3, Вы писали:
A>Здравствуйте, so5team, Вы писали:
S>>Для того, чтобы доказать, что это "клиника" и "солипсизм" следовало бы хотя бы привести ссылку на определение понятия "парадигма программирования", которого вы сами придерживаетесь (можно даже не обсуждать вопрос адекватности этого определения). S>>Но вы и этого не смогли. S>>Ожидаемо.
A>Очень странно выглядит, когда человек пытается в сфере программной инженерии разгуливать с определением парадигмы из научного мира.
Странно это когда человек отрицает одно определение и не приводит другое, при этом продолжая рассуждать о сферических конях в вакууме.
Здравствуйте, a7d3, Вы писали:
A>Очень странно выглядит, когда человек пытается в сфере программной инженерии разгуливать с определением парадигмы из научного мира.
Вас ведь не затруднит указать на хоть какое-либо определение парадигмы, которое я здесь привел? Хоть из научного мира, хоть из ненаучного.
А то вы утверждаете про "разгуливать с определением парадигмы из научного мира", хотя я лично ни одного определения для "парадигмы" пока здесь не озвучивал и ни на какие определения не ссылался.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, a7d3, Вы писали:
A>>Очень странно выглядит, когда человек пытается в сфере программной инженерии разгуливать с определением парадигмы из научного мира.
S>Вас ведь не затруднит указать на хоть какое-либо определение парадигмы, которое я здесь привел? Хоть из научного мира, хоть из ненаучного.
S>А то вы утверждаете про "разгуливать с определением парадигмы из научного мира", хотя я лично ни одного определения для "парадигмы" пока здесь не озвучивал и ни на какие определения не ссылался.
А вот это что было?
...сами по себе "парадигмы" -- это как раз из категории "давно и широко известных вещей", т.к. парадигма -- это не свод строго проверяемых математически выверенных абстракций. А некий устоявшийся в сообществе набор взглядов. ...
Очень напоминает пересказ своими словами классического варианта определения парадигмы принятое в научном мире. Взятый с какой-нибудь википедии или другого схожего ресурса.
Здравствуйте, a7d3, Вы писали:
S>>А то вы утверждаете про "разгуливать с определением парадигмы из научного мира", хотя я лично ни одного определения для "парадигмы" пока здесь не озвучивал и ни на какие определения не ссылался.
A>А вот это что было? A>
A>...сами по себе "парадигмы" -- это как раз из категории "давно и широко известных вещей", т.к. парадигма -- это не свод строго проверяемых математически выверенных абстракций. А некий устоявшийся в сообществе набор взглядов. ...
A>Очень напоминает пересказ своими словами классического варианта определения парадигмы принятое в научном мире. Взятый с какой-нибудь википедии или другого схожего ресурса.
Попытка объяснить чем "парадигма" не является, ваш К.О.
Под определение, с очень большой натяжкой, может сойти разве что вот эта часть фразы "А некий устоявшийся в сообществе набор взглядов". Но если для вас это сошло за определение, то: во-первых, ой, все еще хуже, чем я думал, и, во-вторых, вы-то и отдаленно чего-либо похожего привести не можете.
Здравствуйте, Maniacal, Вы писали:
M>Есть такая книжка хорошая, только не помню как называется, что-то типа "С++ для профессионалов", что-то то там про количество советов было в названии. M>Конструктор не должен бросать исключений принципиально.
Для конструктора же бросок исключения — самый естественный способ сообщить о невозможности конструирования объекта (аутпут параметры я даже рассматривать не хочу). Даже оператор new обязан подчистить за собой выделенную память, если в конструкторе возникло исключение. Это в стандарте прописано. Стандарт так же описывает, что должно происходить при броске исключения из конструкторов подобъектов составных типов — те подобъекты, которые сконструированы на этот момент, должны быть корректно разрушены, причем, в строго определенном порядке. Смотри, сколько всего предусмотрено, а ты говоришь "не должен бросать принципиально". Ты, видимо, просто перепутал конструкторы с деструкторами.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, so5team, Вы писали:
S>Попытка объяснить чем "парадигма" не является, ваш К.О.
S>Под определение, с очень большой натяжкой, может сойти разве что вот эта часть фразы "А некий устоявшийся в сообществе набор взглядов". Но если для вас это сошло за определение, то: во-первых, ой, все еще хуже, чем я думал, и, во-вторых, вы-то и отдаленно чего-либо похожего привести не можете.
Идея в том, чтобы посмотреть на разницу парадигмы в научном мире с парадигмой программирования в инженерии программной.
И растёт это всё из случившейся ранее попытки объявить стиль программирования синонимом парадигмы программирования.
Здравствуйте, a7d3, Вы писали:
S>>Под определение, с очень большой натяжкой, может сойти разве что вот эта часть фразы "А некий устоявшийся в сообществе набор взглядов". Но если для вас это сошло за определение, то: во-первых, ой, все еще хуже, чем я думал, и, во-вторых, вы-то и отдаленно чего-либо похожего привести не можете.
A>Идея в том, чтобы посмотреть на разницу парадигмы в научном мире с парадигмой программирования в инженерии программной. A>И растёт это всё из случившейся ранее попытки объявить стиль программирования синонимом парадигмы программирования.
"Если у вас есть идея, то купите селедку и морочьте ей голову" (c)
А если вы хотите предъявить что-то мне, то озвучивайте причины, почему в вашем мире, настолько оторванном от реальности, что аж страшно, "стиль программирования" не может быть синонимом "парадигмы программирования". Для чего вам придется либо озвучить свои определения, либо дать на них ссылки. О чем вам толкуют уже в который раз.
Здравствуйте, so5team, Вы писали:
S>"Если у вас есть идея, то купите селедку и морочьте ей голову" (c)
S>А если вы хотите предъявить что-то мне, то озвучивайте причины, почему в вашем мире, настолько оторванном от реальности, что аж страшно, "стиль программирования" не может быть синонимом "парадигмы программирования". Для чего вам придется либо озвучить свои определения, либо дать на них ссылки. О чем вам толкуют уже в который раз.
С какой целью? Чтобы общаться на одном языке с колхозником, показавшим себя во всей красе в этом тредике?
Спасибо, не интересно. Пусть дальше полагает, что единственно верный полиморфизм в контексте ООП сводится late & dynamic binding.
Что какая-нибудь двойная диспетчеризации может производиться лишь в рантайме, а если в компил-тайме, то это, якобы, уже не ООП.
Здравствуйте, a7d3, Вы писали:
A>Спасибо, не интересно.
Не интересно учиться и узнавать что-то новое? Обмениваться знаниями? Ну бывает. Когда думаешь, что за спиной 25 лет опыта, то можно и разучиться новую информацию воспринимать.
A>Пусть дальше полагает, что единственно верный полиморфизм в контексте ООП сводится late & dynamic binding.
Речь не про верный/неверный. А про то, что когда динамический полиморфизм, то это ООП. А другие случаи -- не ООП.
Всего лишь.
И да, сколько вы не будете пытаться надувать щеки, обосновать свою точку зрения у вас не выйдет. Многократо доказано и перепровенено.
Здравствуйте, a7d3, Вы писали:
A>Здравствуйте, so5team, Вы писали:
S>>"Если у вас есть идея, то купите селедку и морочьте ей голову" (c)
S>>А если вы хотите предъявить что-то мне, то озвучивайте причины, почему в вашем мире, настолько оторванном от реальности, что аж страшно, "стиль программирования" не может быть синонимом "парадигмы программирования". Для чего вам придется либо озвучить свои определения, либо дать на них ссылки. О чем вам толкуют уже в который раз.
A>С какой целью? Чтобы общаться на одном языке с "колхозником"
У тебя какой-то комплекс на тематике колхоза. Тяжелая деревенская жизнь? В школе били часто?
Здравствуйте, a7d3, Вы писали:
A>Здравствуйте, so5team, Вы писали:
S>>"Если у вас есть идея, то купите селедку и морочьте ей голову" (c)
S>>А если вы хотите предъявить что-то мне, то озвучивайте причины, почему в вашем мире, настолько оторванном от реальности, что аж страшно, "стиль программирования" не может быть синонимом "парадигмы программирования". Для чего вам придется либо озвучить свои определения, либо дать на них ссылки. О чем вам толкуют уже в который раз.
A>С какой целью? Чтобы общаться на одном языке с колхозником, показавшим себя во всей красе в этом тредике? A>Спасибо, не интересно. Пусть дальше полагает, что единственно верный полиморфизм в контексте ООП сводится late & dynamic binding.
Проведу сеанс снятия запоров ограничений в понимании ООП и полиморфизма.
Внимание! Следи за руками:
Чаще всего выделяют следующие необходимые и достаточные элементы ООП:
1) инкапсуляция;
2) наследование;
3) полиморфизм.
Реазация динамического полиморфизма подразумевает Наследование. Именно поэтому её и только её относят к ООП парадигме.
А теперь смотри фокус. Пример "статического полиморфизма"
template<class T>
struct A
{
void foo(T t)
{
...
t.do();
...
}
}
struct B
{
void do()
{...}
}
int main()
{
A<B> a;
a.foo(B());
...
...
}
Теперь вопрос: этот код можно назвать кодом в классической ООП парадигме?
