Ну если тебе нравится подход с вектором из кучи элементов в виде mpl-каши, то тоже вариант. Но вообще мой подход даёт возможность писать классы, просто описывая классы как обычно, просто они становятся юзабельными по значению, независимо от размера, прячут данные в реализацию и могут быть контейнерами для наследников. А так конечно можно и на void* всё то же самое сделать.
Тут тоже не ломается бинарная совместимость и о классе с данными мы знаем только то, что он есть, в API вынесен только указатель на него. Мало того, этот подход позволяет не принудительно использовать D-pointer'ы, а применять их только для больших объектов.
Большие объекты не обязательно пихать в стек, для этого есть куча и copy-on-write из прошлой статьи. А вот множество операций над маленькими объектами, теми же скалярами и небольшими составными типами, лучше всего делать на стеке, на это его хватает.
Неправда Ваша, смотрите, то что я предлагаю — это по сути аналог pqxx::field, только в более широком спектре использования. Никто не мешает сделать так:
template <typename value_type> value_type object::to() const;
Скажу больше, ровно так и нужно сделать. Обобщённый тип всегда должен давать возможность работать с содержимым в виде нативного значения.
Пользователь ORM-системы или SQL-генератора, наподобие LINQ является точно такой же программист, которому нужен удобный API, эффективность при выполнении инструкций и интуитивно понятный код в результате разработки. Разработчик библиотеки в свою очередь разумеется не знает заранее о том, что за типы придут с некой заранее неизвестной базы данных или с удалённого клиента RPC-протокола.
Если делать SQL-конструктор на основе конструкций C++ или просто даже библиотеку общего пользования, то на этапе компиляции знать типы того, что придёт из БД не известно. То же касается и RPC.
Похоже, но здесь нет ни одного шаблона снаружи (в отличие от type_erasure), а в статье как раз целый раздел посвящён тому, за что можно не любить шаблоны. Подход в статье также не призывает делать лишние cast'ы. К тому же можно свободно использовать наследники, не заморачиваясь только на object, как в Boost на any.
Это именно она и есть, просто скрещена с Pimpl подходом. Можно чуть перестроить, чтобы было удобнее видеть параллели, но так как в статье удобнее использовать и читать понятнее.
Это не pimpl, я понимаю откуда такая аналогия. По сути это инкапсуляция интерфейса и подразумевает наследование. Pimpl — по сути просто класс с реализацией, с прокси-декоратором снаружи. У одного класса, в подходе Майерса, есть как правило класс двойник, и инкапсулировать прокси-класс с API может только его. Здесь подход именно на том, что наследование внутренних классов с данными инкапсулировано. Мы запросто можем положить в object любой его наследник.
Затем, что в большинстве случаев тебе надо запаковывать результат запроса в компактный набор значений, неопределённого на этапе компиляции типа, причём память, желательно, выделить однажды, а значениями всё забить так, чтобы с набором было удобно работать.
Ну преподавать СРАЗУ С++ я считаю слишком для юной психики. Миф о том что С++ — это хороший язык чтобы понять основы — не более чем миф.
Начинать надо с простого языка, чтобы преподавать основы алгоритмики: Python для начала хорош, C# если к типам хочется приучать сразу, Pascal старый добрый тоже хорош, но на нём просто уже не пишут.
C++ и Java всё же два языка, до которых надо дорасти, особенно C++. Как правило к языку C++ и идут через язык C, потому что язык C позволяет понять работу с памятью и адресацией, чтобы потом перейти к Assembly, а затем также пойти вверх и выучить ООП и шаблоны языка C++.
И да, инициализация вектора как массива в C++ работает далеко не во всех компиляторах, которые заявляют о поддержке C++11.
Слишком оптимистичная статья в отношении C++. Могу пройти по всем мифам, но в целом всё верно, за исключением тона подачи материала.
Ну что вам сказать, ребята-зептолабята, вы — большие молодцы!
Жаль что программирование на мобильных устройствах не очень моё.
Продолжайте в том же духе и вас будет не догнать никому и никогда.
P.S. Ам-ням!
Раз такое дело и все хотят продолжения, попробую всё расписать по порядку, не забыть бы чего.
Первая моя работа была в лаборатории компьютерной графики. Чтобы попасть туда мне понадобились знания аналитической геометрии, линейной алгебры и математического анализа. Ну и конечно знания 3D pipeline, поскольку пришлось всё визуализировать вручную без помощи Direct3D или OpenGL. Однако попав туда, я очень здорово пролетел, так как отдел переформировали в железячный, мы писали драйвера для протоколов и высокоуровневый функционал для взаимодействия с интерфейсом этих драйверов. Тогда я и познал .NET 1.1 и 2.0 (как только вышел) в деталях, выучил C#, научился маршаллить C/C++ интерфейсы в менеджед библиотеки. Было интересно, но числился я тогда студентом и получал соответственно.
Математическая статистика, теория вероятностей и, главное, численные методы — первая моя серьёзная работа на ныне норвежскую компанию, кроме текучки типа запилить доверительные интервалы при вычислении некоторого прогноза, мне тогда доверили (а зря, студенту-то) оптимизировать расчёт стоимости рекламной компании. Моей задачей была оптимизация функции стоимости рекламы в N-мерном пространстве, где каждое измерение — стоимость по определённому рекламному носителю по заданной целевой аудитории. В ряде случаев получалась дробно-рациональная функция от N переменных и кроме как численными методами оптимизации такое не решается. В университете ЧМ были моим коньком, вместе со знанием 3D я рисовал решения университетских задач, визуализируя решения в 3D по времени в виде анимации. Столкнувшись с реальными проблемами при решении реальной задачи: сложная область определения, поиск решения на границе, множественный поиск и параллельные вычисления (из-за попадания в локальные минимумы) я понял КАК МАЛО Я ЗНАЮ после первых 4-х курсов и то, что университетские задачки дают общее представление о том как решать, но в жизни всё намного сложнее. Оптимизатор получился довольно неплохой, но предыдущая реализация была лучше, поэтому мою работу тогда забраковали. Опыт был горький, но весьма полезный, я усвоил не только ряд новых методов, но и то, что не стоит бросаться и бить себя пяткой в грудь «да я смогу!» если ты вчерашний студент и не понимаешь мастерства коллеги, который убил кучу времени на предыдущую реализацию, на её оптимизацию, он работал с этим продуктом в этой компании много лет и наверняка у него были причины гордиться своей работой.
Следующая работа была с CAD-системой, в 3D с геометрией, линейной алгеброй, немного дифурами и матанищем, по сути всё сводилось к движению резца по кромке детали, в результате резец что-то вырезал, не ломался и изготавливалась некоторая заготовка на автоматизированном станке. Работа была интересная, в 3D как и мечталось, но начисто убивало всё желание копание в багах старших коллег, которые скидывали все задания «найди утечку» и «найди выход за границы массива» в наш местный филиал. В результате было минимум геометрии и максимум шаманства с помечанием памяти.
Позже пригодилась даже физика, переменный ток с напряжением нужно было визуализировать. Здесь геометрия была уже двумерной, и оттачивалось мастерство моё как разработчика, ибо прошивка кастомного устройства замера элекроэнергии должно было крайне экономно расходовать любые ресурсы. Зато на стороне PC-интерфейса можно было разгуляться. Был даже проект с обёрткой C API нашей обёртки в C# .NET для отображения, благо опыт уже был.
На облачную платформу, где я сейчас работаю, пригласили внезапно. Компания лидер в нашем городе, решения интересные, то чем я занимаюсь активно оперирует мат.статистикой, сильно завязана на взаимодействие между C++ и Python (собственно я автор этой связки), ядро написано на C++, всё проходит через него. Геометрии и 3D минимум, однако зачастую требуются самые разнообразные знания, поскольку роль у меня сейчас руководящая и спектр задач довольно широк. Здесь лучше бы знать абсолютно всё, включая весь курс математики, не говоря уже о целом спектре технологий, которые я просто физически не успеваю изучить и знакомлюсь с ними разведкой боем, впрочем тут уже появляется чутьё фарватера, а вот с математикой сложнее, её либо знаешь, либо нет.
От себя замечу, что мне на разных местах работы пригодился почти весь курс математики, особенно линейная алгебра, аналитическая геометрия, математический анализ, математическая статистика, теория вероятностей и, конечно же, численные методы с дифференциальными уравнениями.
Пожалуй только функциональный анализ и топология не пригодились вообще. Хотя, возможно, я просто не побывал на такой позиции где и это тоже нужно.
Если интересно, могу расписать где какая прикладная задача потребовала каких знаний. Ну кроме линейной алгебры, аналитической геометрии и математического анализа, которые вообще везде нужны, особенно если 3D часто появляется.
В результате, не так давно, принял решение продолжать обучение и расти как математик. Поступил в свой родной университет, вот, доучиваюсь до магистра Йоды с претензией расти выше и выше.
Дык, пусть своих друзей из ЦРУ попросят базу студентов слить. Всё равно это безлимитное облако безлимитно будет уходить в США с каждым новым файлом, так что это будет неплохой вклад во взаимовыгодное сотрудничество. Так будет гораздо проще проверять студент ты или нет, например по номеру студенческого вместе с фамилией и именем.
Кину свои 0,5 копеек.
Приоритеты при разработке:
1. Должен быть результат, т.е. програма должна работать и выполнять свою работу — это главное. Всё остальное — лирика.
2. Результат должен быть эффективным, т.е. всё должно выполняться за приемлимое время и кушать приемлимое количество ресурсов, и т.д.
3. Результат должен быть стабилен, без косяков. Если результат нестабилен, но эффективно выполняет свою работу с некоторыми косяками, то это лучше, чем стабильный код съедающий все ресурсы либо выполняющийся год. Не относится к случаю из пункта 1.
4. Код результата должен быть оформлен по правилам KISS, YAGNI и DRY + правила вашей среды разработки.
5. Все остальные требования.
6. Profit.
template <typename value_type> value_type object::to() const;
Скажу больше, ровно так и нужно сделать. Обобщённый тип всегда должен давать возможность работать с содержимым в виде нативного значения.
Начинать надо с простого языка, чтобы преподавать основы алгоритмики: Python для начала хорош, C# если к типам хочется приучать сразу, Pascal старый добрый тоже хорош, но на нём просто уже не пишут.
C++ и Java всё же два языка, до которых надо дорасти, особенно C++. Как правило к языку C++ и идут через язык C, потому что язык C позволяет понять работу с памятью и адресацией, чтобы потом перейти к Assembly, а затем также пойти вверх и выучить ООП и шаблоны языка C++.
И да, инициализация вектора как массива в C++ работает далеко не во всех компиляторах, которые заявляют о поддержке C++11.
Слишком оптимистичная статья в отношении C++. Могу пройти по всем мифам, но в целом всё верно, за исключением тона подачи материала.
Жаль что программирование на мобильных устройствах не очень моё.
Продолжайте в том же духе и вас будет не догнать никому и никогда.
P.S. Ам-ням!
Первая моя работа была в лаборатории компьютерной графики. Чтобы попасть туда мне понадобились знания аналитической геометрии, линейной алгебры и математического анализа. Ну и конечно знания 3D pipeline, поскольку пришлось всё визуализировать вручную без помощи Direct3D или OpenGL. Однако попав туда, я очень здорово пролетел, так как отдел переформировали в железячный, мы писали драйвера для протоколов и высокоуровневый функционал для взаимодействия с интерфейсом этих драйверов. Тогда я и познал .NET 1.1 и 2.0 (как только вышел) в деталях, выучил C#, научился маршаллить C/C++ интерфейсы в менеджед библиотеки. Было интересно, но числился я тогда студентом и получал соответственно.
Математическая статистика, теория вероятностей и, главное, численные методы — первая моя серьёзная работа на ныне норвежскую компанию, кроме текучки типа запилить доверительные интервалы при вычислении некоторого прогноза, мне тогда доверили (а зря, студенту-то) оптимизировать расчёт стоимости рекламной компании. Моей задачей была оптимизация функции стоимости рекламы в N-мерном пространстве, где каждое измерение — стоимость по определённому рекламному носителю по заданной целевой аудитории. В ряде случаев получалась дробно-рациональная функция от N переменных и кроме как численными методами оптимизации такое не решается. В университете ЧМ были моим коньком, вместе со знанием 3D я рисовал решения университетских задач, визуализируя решения в 3D по времени в виде анимации. Столкнувшись с реальными проблемами при решении реальной задачи: сложная область определения, поиск решения на границе, множественный поиск и параллельные вычисления (из-за попадания в локальные минимумы) я понял КАК МАЛО Я ЗНАЮ после первых 4-х курсов и то, что университетские задачки дают общее представление о том как решать, но в жизни всё намного сложнее. Оптимизатор получился довольно неплохой, но предыдущая реализация была лучше, поэтому мою работу тогда забраковали. Опыт был горький, но весьма полезный, я усвоил не только ряд новых методов, но и то, что не стоит бросаться и бить себя пяткой в грудь «да я смогу!» если ты вчерашний студент и не понимаешь мастерства коллеги, который убил кучу времени на предыдущую реализацию, на её оптимизацию, он работал с этим продуктом в этой компании много лет и наверняка у него были причины гордиться своей работой.
Следующая работа была с CAD-системой, в 3D с геометрией, линейной алгеброй, немного дифурами и матанищем, по сути всё сводилось к движению резца по кромке детали, в результате резец что-то вырезал, не ломался и изготавливалась некоторая заготовка на автоматизированном станке. Работа была интересная, в 3D как и мечталось, но начисто убивало всё желание копание в багах старших коллег, которые скидывали все задания «найди утечку» и «найди выход за границы массива» в наш местный филиал. В результате было минимум геометрии и максимум шаманства с помечанием памяти.
Позже пригодилась даже физика, переменный ток с напряжением нужно было визуализировать. Здесь геометрия была уже двумерной, и оттачивалось мастерство моё как разработчика, ибо прошивка кастомного устройства замера элекроэнергии должно было крайне экономно расходовать любые ресурсы. Зато на стороне PC-интерфейса можно было разгуляться. Был даже проект с обёрткой C API нашей обёртки в C# .NET для отображения, благо опыт уже был.
На облачную платформу, где я сейчас работаю, пригласили внезапно. Компания лидер в нашем городе, решения интересные, то чем я занимаюсь активно оперирует мат.статистикой, сильно завязана на взаимодействие между C++ и Python (собственно я автор этой связки), ядро написано на C++, всё проходит через него. Геометрии и 3D минимум, однако зачастую требуются самые разнообразные знания, поскольку роль у меня сейчас руководящая и спектр задач довольно широк. Здесь лучше бы знать абсолютно всё, включая весь курс математики, не говоря уже о целом спектре технологий, которые я просто физически не успеваю изучить и знакомлюсь с ними разведкой боем, впрочем тут уже появляется чутьё фарватера, а вот с математикой сложнее, её либо знаешь, либо нет.
Пожалуй только функциональный анализ и топология не пригодились вообще. Хотя, возможно, я просто не побывал на такой позиции где и это тоже нужно.
Если интересно, могу расписать где какая прикладная задача потребовала каких знаний. Ну кроме линейной алгебры, аналитической геометрии и математического анализа, которые вообще везде нужны, особенно если 3D часто появляется.
В результате, не так давно, принял решение продолжать обучение и расти как математик. Поступил в свой родной университет, вот, доучиваюсь до магистра Йоды с претензией расти выше и выше.
Ну его нафиг!
Приоритеты при разработке:
1. Должен быть результат, т.е. програма должна работать и выполнять свою работу — это главное. Всё остальное — лирика.
2. Результат должен быть эффективным, т.е. всё должно выполняться за приемлимое время и кушать приемлимое количество ресурсов, и т.д.
3. Результат должен быть стабилен, без косяков. Если результат нестабилен, но эффективно выполняет свою работу с некоторыми косяками, то это лучше, чем стабильный код съедающий все ресурсы либо выполняющийся год. Не относится к случаю из пункта 1.
4. Код результата должен быть оформлен по правилам KISS, YAGNI и DRY + правила вашей среды разработки.
5. Все остальные требования.
6. Profit.