Pull to refresh
88
0
Victor Pavlychko @nullbie

User

Send message
Насчет устарелости MS VS — в контексте C/C++ 2005 и 2008 студии не особо отличаются, а если не лезть в GUI, то и Express от полной не сразу отличить :)
Прошу прощения за глупый вопрос, но там макрорсы работают более интеллектуально сишных? В плане наличия контроля типов, локальных переменным, by-value аргументом, отсутствия сайд-эффектов и прочих радостей препроцессора на уровне потока лексем.
Ну тут лично у меня скорее интерес «как оно внутри работает» :)
Кстати, пример с девиртуализацией/профайлингом уровня JIT не совсем корректен — у нас есть два случая:
— передаем интерфейс, полчаем один метод сортировки на все случиа компарера и выбираем реализацию сравнения через механизм виртуальных вызовом
— передаем тип в параметры генерика, получаем по одной копии сортировки на каждый вариант компарера, зато избегаем виртуальных вызовов.

Так сказать «закон сохранения бяки» :) Или тип в генериках, или виртуальные вызовы. А разрешать копилятору самому выносить аргументы-интерфейсы в параметры генериков особо смысла нету — всегда хочется иметь выбор :)
1. да, уверен, проверял, убиралось. Кстати даже у Рихтера написано что все null-проверки удаляются если в генерик приходит value тип )

3. Вариант с протаскиванием типа навеян STL из C++, там это сделано для обеспечения компилятору доступа к информации о типах и последующего разворачивания inline-методов. Как по мне — чем раньше появится доступ к информации, тем проще ее использовать. Насчет хака — да, в идеологии нынешней версии фреймворка — это хак, но ведь всякое может еще случится :)

4. Ну я вообще изначально С-шиник, мне не привыкать ко всяким ужасам. Да и вряд-ли есть смысл писать код требующий такие оптимизации на шарпе — проще и логичней сделать специализированную либу или сервер для ресурсоемких частей :)
Если верить тому, что я видел где-то в блогах MSDN, то CLR вообще не умеет инлайнить функции у которых есть аргументы передаваемые по значению (в том числе int).

И еще мои наблюдения за результатами работы JIT показали что оно на данном этапе эволюции разворачивает только статические методы классов. Если с методами классов еще понятно — нужны всякие проверки, то со структурами это выглядит странно.
1. В первом случае проверки на null удаляет JIT поскольку int таковым быть не может.

2. Не совсем понял насчет девиртуализатора, но callvirt генерируется шарповским компилятором всегда, и главная причина — проверка чтоб инстанс не был null (кстати в С++ как правило можно запросто вызывать методы для NULL указателя если они не используют данные инстанса)

3. В CIL информация о типах то есть, только инструкция записи в массив, как оказалось, одна на все ссылочные типы и принимает Object :)

4. Вообще-то писать на C#/.Net нагруженный вычислениями код слегка не логично — не для этого он предназначен. Но если приходится, то как правило все средства хороши, и тут указаны только наименее хардкорные оптимизации :)
Алгоритмов сортировки есть много и разных, я знаю примеры когда оптимальным является самый обычный «тормозящий» пузырёк :) Не в алгоритме сортировки тут суть :)
Всякий интеллектуальный синтаксический сахар как раз усложняет докапывание до внутреннего устройства, а дефайны и инклуды как раз наоборот работают до ужаса тупо на уровне склеивания кусков текста :)

А вообще я о другом — постоянно появляется что-то новое, целостное. Потом в него включает все новые модные штучки и делают помойку. Потом все устаканится и появится новый язык, чистый и стройный. И все по кругу :)
<sarcasm>И эти люди говорят что C++ сложная каша из парадигм, а C# новый чистый язык...</sarcasm>
При разовой правке дискомфорта нету, а если работы много — начинаешь на автомате жать привычные хоткеи, а в ответ происходит непонятно что. А это как раз занимает много времени — хочешь что-то сделать как обычно, происходит какая-то лажа, ищешь как вернуть обратно, пробуешь по-другому…

Я лично VS пользуюсь еще с VC6, к его дефолтам и привык, а всякие финты вроде «пересунуть Solution Explorer в правый сайдбар» (началось с 7.0) меня ужасно расстроили… Хорошо хоть начиная с 2005 можно при установке выбрать привычные опции :)
он же закрытый, кто его знает как они шифруют и шифруют ли вообще.

Вопрос закрытости протокола оставим в стороне, но если бы они не шифровали вообще, или плохо шифровали, то наверное протокол давно уже бы расковыряли народные умельцы :D
Word, Excel и Lotus вполне умеют читать и писать стандартизированые документированые форматы, пусть и не с полным функционалом. Что касается Oracle, PL/SQL базируется на стандартном ANSI SQL. Так что в данном случае проблемы стыковки с альтернативным ПО особо нетую, в отличие от Skype, который «вещь в себе»…
Спорить смысла нету — это вопрос опредения понятия «виртуальный конструктор», которое отсутствует в С++. Фабрики ближе к понятию «метакласс», но по большому счету оба паттерна по-своему подходят под это название.
Фабрика вообще-то самый популярный способ реализации «виртуального конструктора». А метод clone (оно же паттерн прототип) это по сути некий аналог аналог «виртуального» конструктора копии, более узкий случай.
Вообще само по себе определение «виртуальный конструктор» не совсем корректно — виртуальный метод выбирается зависимо от реальной интстанции объекта стоящего за указателем на базовый класс. К конструктору то применить вообще-то нельзя :)

С другой стороны, если пойти в торону метаклассов, то конструктор есть методом метакласса, и тогда надо делать объект Type с виртуальным методом CreateInstance. Получим абстрактную фабрику.

В этом примере действительно смущает оператор switch, такой код в принципе несложно переписать с фабриками и он будет выглядеть более изящно. Для выбора по элементу энама можно сделать например массив фабрик.

Впрочем это все философия на тему что такое «виртуальный конструктор» вообще. Термин не определен языком С++, так что спорсить особо некуда :)
ну хорошо если так, только главное чтоб там буфера не копировались, а шарились :)
Поясню проблему с сокетами в данном случае: отправка большой текстуры в сокет вынуждает прокачку этих данных процессором. Это сводит на нет всякие DMA — да, видеокарта захватит данные из оперативы напрямую, только сначала мы их через процессор прокачаем из одного приложения в другое.

Принятие решения о том, что видеоподсистема (Х-сервер) работает на одной машине с приложением (Х-клиент), может существенно повысить производительность не снижая стабильность и независимость компонент.
Когда придумали концепт Х-сервера:
1. компьютеры были дороги и возлагались большие надежды на терминальные решения
2. графика не была настолько жирной — гонять по сети фактически векторные картинки (линии/прямоугольники + текст + пара иконок xmp формата 16х16 на 256 цветов) не проблема

Сейчас требования поменялись, а архитектура — нет.
Дело в том, что с этим слоем не обязательно через сокет общаться :)
В виндах тоже много «слишком сложных» решений, но общение с видеоподсистемой через сокеты не самое быстрое решение, особенно во времена больших «декоративных» текстур…

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity