Здравствуйте, Pzz, Вы писали:
S>>им видится и полэкрана кода, который ничего не делает, и, что еще важнее, проверки на каждом присваивании.
Pzz>Тут и есть полэкрана кода. Там 12 строк, в стандартном экране их 24.
Здравствуйте, so5team, Вы писали:
S>Но гораздо конструктивнее просто спросить о главном: если вы весь из себя такой удавшийся, что позволяете судить всех остальных с позиции "а чего добился ты", то что вы вообще делаете на этом форуме и почему тратите время на лузера типа меня?
Второе высшее получаю по психологии, для курсовой собираю материал — почва здесь для исследований благодатная.
S>Или можно с другой стороны зайти: а чего добились вы?
Дорос до архитектора, в заказчиках известные крупнные компании, интересная работа, много выступаю на конференциях, можно сказал сделал себе из имени бренд, материально все в шоколаде: квартира в Москве в престижном районе, дача, машина из салона каждые 3 года.
Здравствуйте, Pzz, Вы писали:
S>>Чем они строгие? Любой в v может записать все, что захочет.
Pzz>Мы от чего защищаемся, от случайных ошибок, или от целенаправленного взлома?
От случайных. В сишном варианте у вас все манипуляции будут именно с var.v. И никто не защитит вас от того, что вы в var_distance.v по ошибке засунете var_weight.v.
Pzz>А, ну да, у вас в команде нет индусов. Будут, это вопрос времени.
Нет проблем, можно привести историю и из своего опыта. Когда-то давно в большой (для проектной команды) кодовой базе величины таймаутов было решено задавать просто в миллисекундах и хранить это все просто в unsigned-ах. Соответственно, со временем полезли ошибки связанные с тем, что где-то из конфига величины считывались в секундах или минутах, а потом без должных преобразований или с неправильными преобразованиями это все уходило на вход функциям, где ожидались просто unsigned-ы.
С учетом этого прошлого опыта теперь для таких вещей используются std::chrono::duration. И подобных проблем нет от слова совсем. При том, что все осталось в рамках того же языка.
S>>Это в Pascal-е было за 30 лет до появления Go.
Pzz>Ну во-первых, паскале не было.
С Виртовским Паскалем не работал, а в Turbo Pascal из середины 1980-х было.
Pzz>А в третьих, какая разница, где что и было?
Такая же, как и вмешивание Go в разговор про преимущества C++ перед C (или наоборот).
Здравствуйте, B0FEE664, Вы писали:
BFE>Если у вас есть указатель на базовый класс, то вызов виртуального метода оправдан. BFE>Но откуда у вас указатель, если все объекты либо глобальные/статические, либо лежат на стеке? (разумеется рекурсивные вызовы без ограничения глубины на стеке запрещены)
Блин, чтобы передать указатель/ссылку на этот объект куда-то, где умеют работать с интерфейсом базового класса, и кому на детали реализации этого интерфейса в конкретном классе глубоко наплевать.
Здравствуйте, Nikе, Вы писали:
BFE>>А зачем вам виртуальные функции если у вас есть целый объект? N>Их придумали, только чтобы тормозить выполнение в 100 раз, "Денис" не даст соврать!
Не в 100 раз, а в недетерминированное количество раз. Это важное отличие. Качественный источник энтропии — очень полезное в народном хозяйстве приспособление.
Здравствуйте, so5team, Вы писали:
S>Так что еще раз: А каким боком виртуальность функций к целому или не целому объекту?
Если у вас есть указатель на базовый объект, то этот указатель указывает только на часть объекта, а не на весь (целый) объект. Чтобы добраться до целого объекта можно использовать виртуальные методы, тогда (внутри метода) будет доступна та часть объекта, которая видна для типа, где этот виртуальный метод определён.
Допустим у нас есть два типа C и B. Вы можете выделить общую часть и положить её в A, затем отнаследовать C и B от А, добавить виртуальные методы. Но как вы это будете использовать?
Так:?
void fun()
{
C c;
B b;
c.my_virtual_method();
b.my_virtual_method();
}
S>>>Есть ощущение, что вам матчасть нужно сперва подучить. BFE>>Это иллюзия. S>Вы себе сильно льстите.
Не так сильно, как вы думаете. У меня рейтинг 46, а у вас 58.
S>Вот и получается, что отсутствие динамической памяти вообще никак не превращает современный C++ в Си с классами. Поэтому у вас в исходном утверждении ошибка. Что и определяет все последующие заблуждения.
Вообще-то я такого не утверждал.
S>>>Так у вас если нет динамической памяти и исключений не будет. BFE>>Это почему вы так думаете? Насколько я помню стандарт, память под исключения выделяется особым образом. Вроде бы implementation defined. S>Потому что в распространенных реализациях память для исключений гарантированно есть только под bad_alloc. Остальные объекты исключений размещаются в хипе. Что и делает возможным существование exception_ptr, который для исключений работает как умный указатель. S>Соответственно, если у вас нет динамической аллокации, то и исключений, скорее всего, не будет.
Что ж. Ещё один аргумент против исключений.
Т.е. получается С++ без исключений, без контейнеров, без умных указателей. И это следствие только одного требования.
Здравствуйте, Pzz, Вы писали:
BFE>>Что же должен делать автопилот, когда кончилась память? Pzz>Зажечь красную лампочку, и отключиться. Вот если он не зажгет красную лампочку и/или не отключится, это беда.
Ну да, ну да...
Инцидент произошел 12 апреля на рейсе Бангкок-Дэли. Как сообщает Times of India, когда лайнер набрал необходимую высоту, первый офицер Равиндра Нат ушел в туалет и прилег поспать в салоне бизнес-класса. Документы авиакомпании предписывают, чтобы минимум один пилот находился в кабине, контролируя полет и, в случае необходимости, отключая автопилот и принимая на себя управление. Однако командиру корабля Би Кею Сони также захотелось спать и он, включив автопилот, позвал двух бортпроводниц, в том числе молодую Канику Калу. Летчик объяснил им, как управлять самолетом, и ушел.
Здравствуйте, Pzz, Вы писали:
Pzz>Блин, чтобы передать указатель/ссылку на этот объект куда-то, где умеют работать с интерфейсом базового класса, и кому на детали реализации этого интерфейса в конкретном классе глубоко наплевать.
А смысл?
Если у вас есть подобъект, то его можно вызвать напрямую. Виртуальность нужна только если вы поднимаетесь от базового объекта к потомку — в другую сторону можно двигаться без виртуальности.
Здравствуйте, B0FEE664, Вы писали:
S>>Так что еще раз: А каким боком виртуальность функций к целому или не целому объекту?
BFE>Если у вас есть указатель на базовый объект, то этот указатель указывает только на часть объекта, а не на весь (целый) объект. Чтобы добраться до целого объекта можно использовать виртуальные методы, тогда (внутри метода) будет доступна та часть объекта, которая видна для типа, где этот виртуальный метод определён.
Неверно. Виртуальный метод определяет поведение, а не то, к какой части объекта вы через него можете получить доступ.
BFE>Допустим у нас есть два типа C и B. Вы можете выделить общую часть и положить её в A, затем отнаследовать C и B от А, добавить виртуальные методы. Но как вы это будете использовать?
Сдается мне, за рассказывание вам элементарных вещей нужно брать деньги.
Вот наглядный пример:
class abstract_launcher {
public:
void launch_rockets() = 0;
...
};
class launcher_commander {
abstract_launcher & launcher_;
...
public:
void run() {
while(...) {
if(target_detected()) launcher_.launch_rockets();
...
}
}
...
};
class vehicle_based_launcher : public abstract_launcher {
...
};
class ship_based_launcher : public abstract_launcher {
...
};
int main() {
#if VEHICLE_BUILD
vehicle_based_launcher launcher{...};
#else if SHIP_BUILD
ship_based_launcher launcher{...};
#else ...
#endif
launcher_commander commander{launcher};
commander.run();
...
}
S>>>>Есть ощущение, что вам матчасть нужно сперва подучить. BFE>>>Это иллюзия. S>>Вы себе сильно льстите. BFE>Не так сильно, как вы думаете. У меня рейтинг 46, а у вас 58.
Сильно. Поскольку речь шла вообще не о знании C++. Но вы даже этого не смогли понять.
S>>Вот и получается, что отсутствие динамической памяти вообще никак не превращает современный C++ в Си с классами. Поэтому у вас в исходном утверждении ошибка. Что и определяет все последующие заблуждения. BFE>Вообще-то я такого не утверждал.
Утверждали. И вам тут уже несколько человек указали на это.
BFE>Т.е. получается С++ без исключений, без контейнеров, без умных указателей. И это следствие только одного требования.
Вы еще и читать не умеете? Контейнеры вы можете использовать, но не из STL.
Здравствуйте, B0FEE664, Вы писали:
BFE>>>У меня 46 позиция в рейтинге С/С++ на этом сайте, а вас только 191-ая. N>>Зато я С++ знаю, а ты — нет.
BFE>Я знаю С++ лучше вас.
Ну-ну-ну, ты же тут уже писал как ты его знаешь. Это нормально для юниора, но не для сколько то опытного разработчика.
Здравствуйте, Marty, Вы писали:
BFE>>Ну раз нет динамического выделения памяти, значит нет виртуальных функций, смарт указателей, контейнеров...
M>Выделенное есть. M>Контейнеры и смарт указатели — да, их нет
Здравствуйте, Marty, Вы писали:
BFE>>Часть функционала оказывается неиспользуемой. Зачем, например, виртуальные функции, если нет динамически создаваемых объектов? M>Например, фабрика, возвращающая указатели на статические синглтоны в зависимости
синглтон — это антипатерн прежде всего из-за проблем тестирования.
Здравствуйте, Denis Ivlev, Вы писали:
S>>Или можно с другой стороны зайти: а чего добились вы?
DI>Дорос до архитектора, в заказчиках известные крупнные компании, интересная работа, много выступаю на конференциях, можно сказал сделал себе из имени бренд, материально все в шоколаде: квартира в Москве в престижном районе, дача, машина из салона каждые 3 года.
И вы с таким списком "достижений" пришли сюда, мягко говоря, выеживаться и учить кого-либо жизни?
Здравствуйте, Mamut, Вы писали:
BFE>>И проверяют, кстати, 100% покрытие кода, а не 100% сценариев. M>Ну то есть проверяют абсолютно бессмысленную цифру. А гонору-то
Здравствуйте, B0FEE664, Вы писали:
BFE>>>Ну раз нет динамического выделения памяти, значит нет виртуальных функций, смарт указателей, контейнеров...
M>>Выделенное есть. M>>Контейнеры и смарт указатели — да, их нет
BFE>Есть-то они есть, а какой в них смысл?
Смарт-указатели — — ну, у меня их вообще нет, а контейнеры — вполне бы можно использовать для статических данных
Здравствуйте, Pzz, Вы писали:
Pzz>Насчет быстро и эффективно, это не простой вопрос. Чтобы вставить объект в середину вектора объектов, простым советским memmove не обойдешься, придется конструкторы дергать. В новомодном C++ для этого, наверное, уже придумали какой-то навороченный синтаксис, состоящий из необычного сочетания обычных знаков препинания , но слабо могу себе представить, чтобы простой программист в своей прикладной программе им воспользовался.
Осталось понять, что грамотный разработчик использует функционал не просто так, чтобы было, а с какой-то предметной целью. Сам же про виртуальные функции доказывал: если ты их вставил в С++, то и в С придётся использовать. С шаблонами то же самое, если люди которые разрабатывали код знали, что делали — то каждый шаблон зачем-то нужен, соответственно решая какую-то проблему (которая при этом будет присутствовать в С).
Здравствуйте, B0FEE664, Вы писали:
BFE>>>Часть функционала оказывается неиспользуемой. Зачем, например, виртуальные функции, если нет динамически создаваемых объектов? M>>Например, фабрика, возвращающая указатели на статические синглтоны в зависимости
BFE>синглтон — это антипатерн прежде всего из-за проблем тестирования.
Ок, перефразирую:
Например, фабрика, возвращающая указатели на статические экземпляры объектов в зависимости от...
