Несмотря на то, что я и C++ программист, я считаю, что C# и .Net придумали не для того, чтобы думать много о том, как он работает. Какие абстракции создает, что там внутри сидит, какой там там ассемблер генерится, если я P/Invoke сделаю для memcpy, итд. Если об этом думать, то получится программирование еще сложнее, чем на С++. Основной критерий тут, имхо, — это трудозатраты и расширяемость. Если мы можем писать на C# код, который нас устраивает по функциональной корректности, производительности и расширяемости — это даже вредно знать, что там внутри сидит.
Суть проблемы в том, что если нужно вам дропнуть в WinRT специфический конкретный асинхронный таск, то вместе с этим таском дропнется и COM объект (и не один), который дропаться никак не должен. Это кстати и есть пример abstraction leak.
Про SС — вызывающий код может находится в потоке, который создал я сам. В этом случае то, что стоит после await не будет выполнено в вызывающем потоке, если это явно не написали такую логику.
Это пустословие, коллега :)
Вы сначала определите, что такое грамотный уровень, а что такое — неграмотный :) Но я думаю мы эту цепочку будем долго раскручивать.
Гораздо проще здесь опираться на то, что говорит опыт. А опыт говорит мне, что WinAPI в .Net торчит там, куда разработчик залез сам по ошибке. Классический пример — это попытки низкоуравневой работы с Windows Forms, вызов всяких API функций для этого, итд. В этом случае не нужно использовать технологии, которые не предназначены для такого. Есть WPF, есть Silverlight.
Не в вызывающий поток :) А в поток, который задан текущим SynchronizationContext — это раз. Я знаю предмет лучше Вас — это два. Вы суть проблемы не понимаете. Вы не о том.
Это очень редкий случай, но я через это проходил.При определенных условиях — это не только сложно, но и невозможно. API не все умеет для таких сценариев. Зачем: чтобы не переписывать много зависимого кода, который работает в рамках синхронной модели.
Вы говорите очень общими словами, они не отражают истину.
Давайте сначала формально объясним, что такое «закон применим» :) Иначе из его применимости не следует, что какое-то явление имеет место.
На счет Silverlight все просто: это не только не WinApi, но и не .Net даже. Поэтому, говорить, что из .Net торчит WinAPI — это неверно.
WinRT — это прекрасное general purpose API, однако с некоторыми его недоработками на практике приходится сталкиваться. Например, не всегда хорошо иметь только асинхронные методы, а сделать из ассинхронных синхронные — это местами вытекает в серьезные проблемы с контролем ошибок.
Разговор другой. Однако, начнем с того, что в семействе Windows (десктоп/планшет/телефон) кодовая база и так будет одна и та же. Про другие платформы: Ядро будет на С++, остальное — platform specific. Наличие единой кодбазы — это, имхо, вопрос очень сложный. На сколько это оптимально — зависит от конкретного проекта.
Логика министерства вполне понятна. Уровень образования в целом падает, количество вузов до последнего времени только росло. Количество вузов, которые предлагают т.н. дистанционное обучение возрастает. Способны ли они обеспечить качество обучения? Думаю, ответ на этот вопрос очевиден.
А, я понял вашу идею. Сначала подумал, что вы имели в виду, что в одной клетке такое может быть.
Вы в процедуре Merge вычисляете ключ заново (в вызове). Я имел в виду, что у вас функция getKey имеет какой-то совершенно монструозный вид. Можно ведь просто возвращать номер клетки в матрице.
«Правда точки, расстояние между которыми меньше 1 метра, могут иметь разные ключи»
Можете пояснить, почему это может иметь место? Вообще, хэш функция у Вас выбрана достаточно сложно (getKey). Почему было бы просто не взять номер точки в сетке, с учетом того, что у вас 8-байтовый ключ?
В статье описан злой анти-подход. Давайте все начнем индусить, писать спагетти код и потом умрем от количества багов. Автор пишет, что типа добавление одной функции очень быстро делается. Только стоит их добавить 20 — и крен кто потом найдет, где эти функции запрятаны. Метод для компаний, нанимающих низкоквалифицированных индусов и пытающихся с помощью них делать неподъемные проекты. Лучше как раз наоборот как можно раньше прививать культуру написания хорошо структурированного и поддерживаемого кода, рассказывать про такие вещи как SOLID, антипаттерны, дать почитать книгу Code complete, итд Но главное — это практика.
Пока вы там спите, уже 2 стандарта вышло с функциональным программированием в С++
Про SС — вызывающий код может находится в потоке, который создал я сам. В этом случае то, что стоит после await не будет выполнено в вызывающем потоке, если это явно не написали такую логику.
Вы сначала определите, что такое грамотный уровень, а что такое — неграмотный :) Но я думаю мы эту цепочку будем долго раскручивать.
Гораздо проще здесь опираться на то, что говорит опыт. А опыт говорит мне, что WinAPI в .Net торчит там, куда разработчик залез сам по ошибке. Классический пример — это попытки низкоуравневой работы с Windows Forms, вызов всяких API функций для этого, итд. В этом случае не нужно использовать технологии, которые не предназначены для такого. Есть WPF, есть Silverlight.
Давайте сначала формально объясним, что такое «закон применим» :) Иначе из его применимости не следует, что какое-то явление имеет место.
На счет Silverlight все просто: это не только не WinApi, но и не .Net даже. Поэтому, говорить, что из .Net торчит WinAPI — это неверно.
Вообще, как WP разработчик скажу, что идея использования Qt на данной платформе может быть пятой ногой.
Вы в процедуре Merge вычисляете ключ заново (в вызове). Я имел в виду, что у вас функция getKey имеет какой-то совершенно монструозный вид. Можно ведь просто возвращать номер клетки в матрице.
Один только вопрос:
«Правда точки, расстояние между которыми меньше 1 метра, могут иметь разные ключи»
Можете пояснить, почему это может иметь место? Вообще, хэш функция у Вас выбрана достаточно сложно (getKey). Почему было бы просто не взять номер точки в сетке, с учетом того, что у вас 8-байтовый ключ?