Имена остались прежними, но возможно Джеффри Рихтер встречал другие ситуации (иначе зачем он обратил на это внимание) или в компиляторе были изменения. У меня VS 2013, летом на 2015 :)
Самое смешное в этом диалоге то что мы в поисках ответа не подумали о том что бы запустить отладчик поддерживающий ring 0 и проверить это собственными руками, а не ссылаться вслепую на авторитетов.
Напишу тоже.
1) «Заблуждаются не потому что не знают, а потому что думают что знают». Жан Жак Руссо.
2) Программист который способен разобраться в предметной области заказчика в степени достаточной для понимания вопроса — хороший программист. (Это между строчек у Стив Макконнелла и Джона Роббинса)
3) Подходов к разработке много, моделей реализации тоже, что лучше знают те кто на этом зарабатывает.
Да, сам «код» заказчика не интересует. Он требует продукт который решает его задачи.
Про качество кода написано много, но мало вспоминают про архитектуру, не даром у них з.п. с пятью нулями.
Лишний функционал не делают, его не требуют, но он отнимает время и деньги которые никто не закладывал.
Прочитал ваше сообщение, даже засомневался, отыскал в книге этот пункт, нашел в статью в msdn, как еще одно подтверждение перехода в режим ядра.
1) "Я говорил об ущербе производительности, потому что, несмотря на свободу исключений в .NET, внутри они реализуются через SEH. Если хотите это проверить, отладьте приложение .NET, используя отладку в неуправляемом режиме (native mode–only debugging), — вы увидите те же первые случаи исключения при инициации вашего исключения. Это подразумевает переход в режим ядра при каждом исключении. Идея, повторяю, в том, чтобы инициировать исключения при ошибках, а не в нормальном ходе выполнения программы."
2) «Actually, .NET exceptions are implemented in terms of SEH exceptions, which means that they do go on a trip through kernel mode. See blogs.msdn.com/cbrumme/archive/2003/10/01/51524.aspx3 for Chris Brumme's explanation.»
С такими отзывами, я раз 10 перечитаю эти заметки, спасибо!
Редкий комментарий, который стоит как целый пост.
Но Стивен Хокинг тоже прав, я так думаю, потому что человек с его интеллектом смотрит на сто шагов вперед, в то время как большинство не видит дальше собственного носа.
1) Enum структурный тип, но не примитивный. Согласен что предложение не самое удачное (спасибо что указали), но это не делает его не правильным.
2) Цитата из бесплатной книги (ссылка на нее выше):
«Паттерн Visitor – позволяет единообразно обойти набор элементов с разнородными интерфейсами (т.е. набор объектов разных классов не приводя их к общему базовому типу), а также позволяет добавить новый метод (функцию) в класс объекта, при этом не изменяя сам класс этого объекта.»
Я не имею такой же квалификации как автор этих слов, но согласен с ним.
1) У структурных типов и примитивных (byte,int,long...) нет блока синхронизации, который присутствует у объектов в управляемой куче на ряду с ссылкой.
Если не читать то что после запятой, то да, такое допущение будет ошибочным.
2) Методы расширения — прочитайте паттерн Visitor в бесплатной книге itvdn.com/ru/patterns (которая идет как дополнение к первоисточнику GOF).
Я не сам это придумал, это ведь заметки а не мои домыслы.
P.S.
Скачать IDA и нажать F5 стало так просто :)
А цена и условия приобретения кусаются, но кого это интересует, мы даже не замечаем что пишем.
Класс:
Имена остались прежними, но возможно Джеффри Рихтер встречал другие ситуации (иначе зачем он обратил на это внимание) или в компиляторе были изменения. У меня VS 2013, летом на 2015 :)
Но тема интересна.
Блог надо прочитать целиком, не Испанский ведь.
1) «Заблуждаются не потому что не знают, а потому что думают что знают». Жан Жак Руссо.
2) Программист который способен разобраться в предметной области заказчика в степени достаточной для понимания вопроса — хороший программист. (Это между строчек у Стив Макконнелла и Джона Роббинса)
3) Подходов к разработке много, моделей реализации тоже, что лучше знают те кто на этом зарабатывает.
Да, сам «код» заказчика не интересует. Он требует продукт который решает его задачи.
Про качество кода написано много, но мало вспоминают про архитектуру, не даром у них з.п. с пятью нулями.
Лишний функционал не делают, его не требуют, но он отнимает время и деньги которые никто не закладывал.
1) "Я говорил об ущербе производительности, потому что, несмотря на свободу исключений в .NET, внутри они реализуются через SEH. Если хотите это проверить, отладьте приложение .NET, используя отладку в неуправляемом режиме (native mode–only debugging), — вы увидите те же первые случаи исключения при инициации вашего исключения. Это подразумевает переход в режим ядра при каждом исключении. Идея, повторяю, в том, чтобы инициировать исключения при ошибках, а не в нормальном ходе выполнения программы."
2) «Actually, .NET exceptions are implemented in terms of SEH exceptions, which means that they do go on a trip through kernel mode. See blogs.msdn.com/cbrumme/archive/2003/10/01/51524.aspx3 for Chris Brumme's explanation.»
С такими отзывами, я раз 10 перечитаю эти заметки, спасибо!
Но Стивен Хокинг тоже прав, я так думаю, потому что человек с его интеллектом смотрит на сто шагов вперед, в то время как большинство не видит дальше собственного носа.
Да, есть явные и неявные числовые преобразования с потерей точности, но имелось ввиду другое.
«Известные применения паттерна в .Net
Паттерн Visitor, выражен в платформе .Net в виде идеи использования расширяющих методов.»
По моему скромному мнению нет смысла спорить о теплом и твердом. Но раз вы считаете иначе, возможно так и есть.
2) Цитата из бесплатной книги (ссылка на нее выше):
«Паттерн Visitor – позволяет единообразно обойти набор элементов с разнородными интерфейсами (т.е. набор объектов разных классов не приводя их к общему базовому типу), а также позволяет добавить новый метод (функцию) в класс объекта, при этом не изменяя сам класс этого объекта.»
Я не имею такой же квалификации как автор этих слов, но согласен с ним.
Если не читать то что после запятой, то да, такое допущение будет ошибочным.
2) Методы расширения — прочитайте паттерн Visitor в бесплатной книге itvdn.com/ru/patterns (которая идет как дополнение к первоисточнику GOF).
Я не сам это придумал, это ведь заметки а не мои домыслы.
п. 30 дополнил примерами, он правильный.