Мой Дедушка отправил подарок как раз во время, я должен был получить его перед самым Новым Годом, 30 декабря. Но при оформлении письма немного ошиблись с номером телефона, чем Дедушка подарил мне еще один квест на новогодние праздники, под названием: «Как забрать подарочек у почтовых оленей».
И вот через почти две недели, я наконец-то получил долгожданный подарок. От радости я уже не дождусь поста «Хвастовства подарками», поэтому пишу здесь.
А мой подарочек оказался таким же чудесным, как и сам факт того, что я смог забрать его у Новогодних Оленей.
Это сертификат на прохождение квест комнаты в моём городе, и замечательное письмо к нему.
И я уже отправил, и внучок получил. А вот АДМ последний раз 3 января заходил и пропал. Такое ощущение что увидев куда надо отправлять подарок, решил его не отправлять. ИМХО это его проблемы. А может я наговариваю и человек просто занят. Получать подарок в последний момент тоже по своему приятно.
P.S. 25 подарков уже получины. Может пора открывать тему «хвастовства подарками»?
Уже не надеялся получить подарок в этом году. Но каким-то чудесным образом, посылка оказалась на почте 30 декабря. Сегодня утром забрал с почты здоровенную коробку. Открыв ее дома, я почувствовал себя меленьким ребенком которому подарили на Новый Год самую лучшую игрушку.
В коробке я обнаружил отличный блокнот-ежедневник с загадочной обложкой «Как управлять вселенной, не привлекая внимания санитаров », флешку USB 3.0 на 64 Гб, и судя по описанию, великолепную настольную игру «Колонизаторы»( будем осваивать в эту новогоднюю ночь), а так же набор защитных пакетиков для карт настольной игры.
Фотоотчет
А вот небольшой сюрприз от моего АДМ, авторская работа, выполнено обычной шариковой ручкой на первой странице блокнота-ежедневника. Очень красиво.
Как видно на снимке выше, из меня плохой фотограф. В жизни этот рисунок намного красивее.
Дедушка спасибо тебе большое. Давно я так не радовался подаркам на Новый Год. Ты самый лучший Дед Мороз!
P.S. Всех с наступающим, желаю таких же отличный подарков как мне подарил мой Дедушка Мороз.
Описанный мною подход мы используем практически как де-факто стандарт для исключений. Было придумано много мелких улучшений на основе этого подхода. Решение оправдало себя. Но как я говорил в статье:
В этой статье я попытался поделиться решением, которое как мне показалось, оптимальное для решения моих задач.
Тут ключевая фраза «для решения моих задач». Сейчас, оглядываясь на весь написанный код, видно что данный поход использован в основном для одной цели: вывести/достать сообщение об ошибки. И только где-то в 1-2 случаев из 100, такой подход понадобился для чего-то другого( конвертация одних исключений в другие ). В итоге, возможно, можно было упростить работу с исключениями и вместо метода accept в базовом классе сделать что-типа:
С другой стороны, визиторы дали нам достаточно гибкий механизм для обработки исключений, что позволило вынести «тематический» код в отдельный классы. Так вывод текста ошибки для всех исключений и все что с этим связано находится в одном классе, что очень удобно при расширении связанного с этим функционала.
В целом мое мнение, что данный подход себя оправдал, и у него больше преимуществ чем недостатков.
Вот другая точка зрения( осторожно, нецензурная лексика ): www.kharkovforum.com/showthread.php?t=910568
Отрывок из поста:
"… мало кто знает как этот пасажир стал директором… переспав с хозяйкой)))..."
Думаю Watson будет больше ориентирован на аналитические задачи, типа: какие акции сегодня лучше купить, или что-то такое. SiRi, на сколько я знаю, это больше «Сказал -> Сделал» или «Сказал -> Нашел». Watson это скорее «Сказал -> Подумал -> Ответил» или «Сказал -> Нашел -> Проанализировал -> Ответил».
Согласен. Но я считаю лучше хотя бы такой механизм чем ничего. Не всегда есть возможность использовать gdb. У нас иногда случается, что определенная ошибка повторяется только на компьютере клиента, и нет возможности ехать к нему на другой континент. Тогда хотя бы обрывки call stack'а очень помогают в определении не правильного поведения.
Заходя под кат надеялся увидеть что-то типа: svn.pld-linux.org/svn/backtracexx.
В GCC и MSVS есть все средства для расчета call stack'a, и не надо ничего в каждую функцию добавлять.
В собственном продукте я реализовывал базовые классы исключение с использованием подобного функционала, чтобы у любого исключения можно было спросить call stack на момент его генерации. Если такое исключение никем не поймано, то в лог выводится call stack этого исключения.
Плюс такого подхода, что при наличии pdb файлов он работает и в Release конфигурации.
В остальных случаях, как по мне, call stack удобно видеть при выводе ошибки в лог файл, но никак не на каждую функцию при нормальной работе программы.
Я очень негодую отсутствую в препроцессоре возможности перегрузки макросов хотя бы по числу аргументов
На сколько я знаю, с помощью boost preprocessor'а можно указать параметр с любым количеством параметров или что-то похожее. Перегрузить конечно макрос нельзя, но можно вроде обойтись листом параметров. Вот небольшая тема как реализовать подобное на gcc без boost'а.
Когда я учился в институте, интернет был далеко не в каждой лаборатории, да и то не для всех…
От знакомых студентов слышал, что они сейчас эффективно используют DropBox с расшариными для всех однокурсников папками. Просто, и доступно.
Виртуальные функции тоже свой overhead имеют, надо от них отказаться?
Нет конечно. Просто как даже видно из таблиц лучше даже вызвать виртуальную функцию чем сделать dynamic_cast. ИМХО dynamic_cast лучше использовать в крайнем случае.
Спасибо, я это знаю. Но наш продукт кросс платформенный, и мы не используем функциональность WinApi. В наших ресурсах кроме строк так же хранятся иконки и картинки. Так же возможен перевод всех ресурсов и переключение языков.
По поводу GUI не gui, у нас два режима работы: gui и консольный режим. И на данный момент, мы стараемся везде использовать ресурсы. Исключения только для log файлов.
И вот через почти две недели, я наконец-то получил долгожданный подарок. От радости я уже не дождусь поста «Хвастовства подарками», поэтому пишу здесь.
А мой подарочек оказался таким же чудесным, как и сам факт того, что я смог забрать его у Новогодних Оленей.
Это сертификат на прохождение квест комнаты в моём городе, и замечательное письмо к нему.
P.S. 25 подарков уже получины. Может пора открывать тему «хвастовства подарками»?
В коробке я обнаружил отличный блокнот-ежедневник с загадочной обложкой «Как управлять вселенной, не привлекая внимания санитаров », флешку USB 3.0 на 64 Гб, и судя по описанию, великолепную настольную игру «Колонизаторы»( будем осваивать в эту новогоднюю ночь), а так же набор защитных пакетиков для карт настольной игры.
А вот небольшой сюрприз от моего АДМ, авторская работа, выполнено обычной шариковой ручкой на первой странице блокнота-ежедневника. Очень красиво.
Как видно на снимке выше, из меня плохой фотограф. В жизни этот рисунок намного красивее.
Дедушка спасибо тебе большое. Давно я так не радовался подаркам на Новый Год. Ты самый лучший Дед Мороз!
P.S. Всех с наступающим, желаю таких же отличный подарков как мне подарил мой Дедушка Мороз.
Тут ключевая фраза «для решения моих задач». Сейчас, оглядываясь на весь написанный код, видно что данный поход использован в основном для одной цели: вывести/достать сообщение об ошибки. И только где-то в 1-2 случаев из 100, такой подход понадобился для чего-то другого( конвертация одних исключений в другие ). В итоге, возможно, можно было упростить работу с исключениями и вместо метода accept в базовом классе сделать что-типа:
С другой стороны, визиторы дали нам достаточно гибкий механизм для обработки исключений, что позволило вынести «тематический» код в отдельный классы. Так вывод текста ошибки для всех исключений и все что с этим связано находится в одном классе, что очень удобно при расширении связанного с этим функционала.
В целом мое мнение, что данный подход себя оправдал, и у него больше преимуществ чем недостатков.
Отрывок из поста:
"… мало кто знает как этот пасажир стал директором… переспав с хозяйкой)))..."
В GCC и MSVS есть все средства для расчета call stack'a, и не надо ничего в каждую функцию добавлять.
В собственном продукте я реализовывал базовые классы исключение с использованием подобного функционала, чтобы у любого исключения можно было спросить call stack на момент его генерации. Если такое исключение никем не поймано, то в лог выводится call stack этого исключения.
Плюс такого подхода, что при наличии pdb файлов он работает и в Release конфигурации.
В остальных случаях, как по мне, call stack удобно видеть при выводе ошибки в лог файл, но никак не на каждую функцию при нормальной работе программы.
На сколько я знаю, с помощью boost preprocessor'а можно указать параметр с любым количеством параметров или что-то похожее. Перегрузить конечно макрос нельзя, но можно вроде обойтись листом параметров. Вот небольшая тема как реализовать подобное на gcc без boost'а.
От знакомых студентов слышал, что они сейчас эффективно используют DropBox с расшариными для всех однокурсников папками. Просто, и доступно.
Нет конечно. Просто как даже видно из таблиц лучше даже вызвать виртуальную функцию чем сделать dynamic_cast. ИМХО dynamic_cast лучше использовать в крайнем случае.
По поводу GUI не gui, у нас два режима работы: gui и консольный режим. И на данный момент, мы стараемся везде использовать ресурсы. Исключения только для log файлов.