ОК, вот Вам конструктив: какие преимущества у ADAMANT'а? Хранить огромное количество данных клиента на девайсах других клиентов, не имеющих к нему отношения, вместо того, что бы хранить их в зашифрованном виде на сервере, который ни одному клиенту не мешает? Или достоинством можно считать отсутствие множества фич, таких, как импорт телефонной книги или уведомление о том, что сообщение прочитано? Или может круто то, что любой достаточно подкованный человек может найти уязвимость в открытом коде месседжера и эксплуатировать ее до посинения, при чем администрация не сможет забанить аккаунт этого клиента, потому что это невозможно? Хотя нет, наверное самое лучшее то, что при этом всем клиенты еще и будут платить за каждое сообщение разработчикам только потому, что они существуют. Ой, опять ирония, прошу прощения)
Как раз потому, что слишком опасно. Это имеет смысл только если нужны команды процессора, невыразимые в С. Поэтому ИМХО Ваша уверенность в своих ассемблерных силах не всяким будет воспринята всерьез.
Ах да, прошу прощения, неправильно прочитал. Но мне все же не кажется, что это противоречит какому-то духу. Если данные какой то сущности должна особым образом обрабатывать другая сущность, это не повод все мешать в один класс. Другое дело, если это происходит постоянно — тогда стоит задуматься над архитектурой проекта. Если все становится слишком уж сложным — никто не мешает пересесть на процедурщину. Но само ООП ни в чем не виновато.
Прошу прощения, если обидел лично Вас, мои замечания на счет «духа» ООП относятся к предыдущим комментаторам, которые обвиняли С++ в том, что их личная бизнес логика не совместима с их личным пониманием ООП.
В моем понимании ООП — это то, что написано на Вики, только без последней фразы про иерархию наследования. Просто объединяем данные и методы их обработки в классы — вот и ООП. Если у меня четко одно поведение — не будет полиморфизма, ничего страшного. Если у меня простая структура, содержащая данные, к которым много где нужен прямой доступ — долой инкапсуляцию. А наследование всегда пытаюсь использовать по минимуму, ибо, несмотря на его удобство в правильных ситуациях, в остальных оно всегда вызывает проблемы. Принципы принципами, но пусть все же ООП работает на меня, а не наоборот. Это лишь мое понимание, которое, очевидно, не совсем совпадает с мнением большинства, но пока что как то так.
Единственное же, что я хотел сказать оскорбившим Вас комментарием — это то, что не стоит обвинять ООП в своих проблемах, а С++ — в проблемах ООП, ибо ООП — не единственная парадигма поддерживаемая в С++, а решение проблем — это не задача ООП.
методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определённого класса, а классы образуют иерархию наследования
Инкапсуляция, наследование, полиморфизм — это принципы ООП, которые, ИМХО, не есть сама суть ООП. А так называемый «дух», ИМХО, присущ не самому ООП, а программисту, который его использует. И если для кого то «дух» ООП — это использование наследования везде, где только можно, я советую обратиться к Саттеру и Александреску — они доходчиво объясняют, когда стоит использовать наследование, а когда рак на горе таки не свистит.
Просто обычно слова «баг компилятора» используются как шутка над неопытным программистом. Если же это не шутка, то, как я уже писал выше, отсутствие нормального компилятора С для обсуждаемой архитектуры, на мой взгляд, является весомой причиной полагать, что архитектура сильно устарела.
Это говорит о том, что в 2018 году для обсуждаемой архитектуры еще нет нормального C-компилятора — еще одна причина оставить эту архитектуру в прошлом.
и совсем не похож на код исходника
Про это не очень понял. Он ведь и не должен быть похожим, то С, а то Ассемблер.
Скорость разработки программы зависит больше не от того, на чем написано, а от того, кто пишет.
Если Вы способны писать качественный код на Ассемблере с той же скоростью, что и на С, то мне остается только Вас поздравить. Но мне все же кажется, что большинство людей в мире не такие.
Ну, наверное Вы, раз умеете сразу работающий код писать)
Зачем?
Ну так не обновляйте ПО.
Если это текст, то его открыть можно любым блокнотом. Или компилировать нечем?
Если так, почему никто не взял да не написал нормальный пакет программирования?
В моем понимании ООП — это то, что написано на Вики, только без последней фразы про иерархию наследования. Просто объединяем данные и методы их обработки в классы — вот и ООП. Если у меня четко одно поведение — не будет полиморфизма, ничего страшного. Если у меня простая структура, содержащая данные, к которым много где нужен прямой доступ — долой инкапсуляцию. А наследование всегда пытаюсь использовать по минимуму, ибо, несмотря на его удобство в правильных ситуациях, в остальных оно всегда вызывает проблемы. Принципы принципами, но пусть все же ООП работает на меня, а не наоборот. Это лишь мое понимание, которое, очевидно, не совсем совпадает с мнением большинства, но пока что как то так.
Единственное же, что я хотел сказать оскорбившим Вас комментарием — это то, что не стоит обвинять ООП в своих проблемах, а С++ — в проблемах ООП, ибо ООП — не единственная парадигма поддерживаемая в С++, а решение проблем — это не задача ООП.
Инкапсуляция, наследование, полиморфизм — это принципы ООП, которые, ИМХО, не есть сама суть ООП. А так называемый «дух», ИМХО, присущ не самому ООП, а программисту, который его использует. И если для кого то «дух» ООП — это использование наследования везде, где только можно, я советую обратиться к Саттеру и Александреску — они доходчиво объясняют, когда стоит использовать наследование, а когда рак на горе таки не свистит.
Про это не очень понял. Он ведь и не должен быть похожим, то С, а то Ассемблер.
Если Вы способны писать качественный код на Ассемблере с той же скоростью, что и на С, то мне остается только Вас поздравить. Но мне все же кажется, что большинство людей в мире не такие.