Комментарии 41
И что, такие вещи кто-то действительно делает?
Да, человек делится жизненным опытом
Спасибо за статью, интересно.
Добавьте раскраску синтаксиса и отступы, а то некоторые примеры становятся плохо понятными.
Добавьте раскраску синтаксиса и отступы, а то некоторые примеры становятся плохо понятными.
А как раскраску добавить? Я в тэг code участки кода заключил. По идее при этом оно само и должно было раскрасить…
Попробуйте любой сервис, подобный этому.
Или такой, там даже отдельная галочка «для хабра» есть ;)
А какой смысл портировать такие библиотеки под C#, когда есть GDI+? Я понимаю смысл портирования AGG или ещё чего-то такого, но библиотеки для работы с форматами файлов?!
Sergius Bobrovsky:
К сожалению, GDI+ имеет множество ограничений. Самое главное — вся
картинка сразу грузится в память. Как следствие очень большие картинки
просто не открываются. Далеко не все варианты TIFF файлов
поддерживаются GDI+ (это существенно улучшили в Windows 7). Нет
тонкого контроля над способом сохранения данных в файл. Например, до
Windows 7 все файлы сохранялись в один strip (все скан-линии
сохранялись одним блоком). Начиная с Windows 7 все файлы сохраняются
во множество strip-ов (и это неьзя изменить), что тоже плохо, так как
есть ситуации, когда должен быть один strip. И таких тонкостей
достаточно много
К сожалению, GDI+ имеет множество ограничений. Самое главное — вся
картинка сразу грузится в память. Как следствие очень большие картинки
просто не открываются. Далеко не все варианты TIFF файлов
поддерживаются GDI+ (это существенно улучшили в Windows 7). Нет
тонкого контроля над способом сохранения данных в файл. Например, до
Windows 7 все файлы сохранялись в один strip (все скан-линии
сохранялись одним блоком). Начиная с Windows 7 все файлы сохраняются
во множество strip-ов (и это неьзя изменить), что тоже плохо, так как
есть ситуации, когда должен быть один strip. И таких тонкостей
достаточно много
Хотелось бы просто для саморазвития на будущее узнать: а была ли какая-нибудь проблема вместо замены указателей на функции применить функторы (иерархию функторов) или это просто не стоило того и затраты времени и сил оказались бы сравнимыми или даже больше?
Sergius Bobrovsky:
Можно было применить и функторы, тут вопрос вкуса. Я решил обойтись
без них, чтобы иметь «готовый к переносу» код еще до смены
компилятора.
Можно было применить и функторы, тут вопрос вкуса. Я решил обойтись
без них, чтобы иметь «готовый к переносу» код еще до смены
компилятора.
А как относительно директив препроцессора в C#?
Не извращенные define, конечно, а условная компиляция?
Не извращенные define, конечно, а условная компиляция?
В c# условная компиляция есть. То есть можно при помощи define-ов делать разные сборки из одного кода. Возможно, я не понял вопроса.
Мой вопрос следовало читать в контексте предыдущего: "… а была ли какая-нибудь проблема вместо..." выбрасывания директив препроцессора "… применить..." директивы препроцессора в С#. Тогда все становится на место.
Можно часть директив препроцессора оставить, об этом написано в статье. Но я рекомендую все-таки удалить все директивы, которые используются для создания разных вариантов программы/библиотеки, чтобы облегчить тестирование в процессе переноса.
Если есть необходимость, то можно потом добавить такие директивы снова.
Если есть необходимость, то можно потом добавить такие директивы снова.
О боже!
А чем плох managed C++? Получите тоже самое, но без большого количества ручной работы.
Sergius Bobrovsky:
Наверное, этот вариант позволил бы быстрее решить поставленную задачу,
но, имхо, читабельность кода была бы гораздо ниже. И все равно
некоторое количество рутинных усилий потребовалось бы. И самое
главное, полученный результат нельзя было бы включить в код сборки на
c# (у меня было такое требование). ILMerge я знаю, но это не
подходило.
Наверное, этот вариант позволил бы быстрее решить поставленную задачу,
но, имхо, читабельность кода была бы гораздо ниже. И все равно
некоторое количество рутинных усилий потребовалось бы. И самое
главное, полученный результат нельзя было бы включить в код сборки на
c# (у меня было такое требование). ILMerge я знаю, но это не
подходило.
Мне кажется, кроме академического интереса — толка в этом минимум.
На много проще и правильнее будет написать вреппер на Managed C++
На много проще и правильнее будет написать вреппер на Managed C++
Действительно какая-то странная методика перелопачивания сорцов. Тем более еще не факт, что оно после этого не будет жутко тормозить.
Соглашусь. Несмотря на свою похожесть C++ и C# — это, всё таки, разные языки. И далеко не всегда то, что хорошо работает, будучи написанное на C++, будет также хорошо работать переложенное «1-в-1» на C#.
Конечно, возможна ситуация, что после трансформации код начнет работать медленнее. Об этом и в статье написано. Поэтому описанный способ ни в коем случае не серебрянная пуля.
Все зависит от требований. То есть если нужно сделать простую консольную программу, которая использует стороннюю unmanaged dll, то можно обойтись и p/invoke (даже врэппер никакой не нужен). Если требования другие (например, возможность запуска в medium trust режиме), то и решения требуются другие.
В статье изложен способ трансформации кода, но не затронута тема необходимости такой трансформации. Иногда такая необходимость есть, иногда нет.
В статье изложен способ трансформации кода, но не затронута тема необходимости такой трансформации. Иногда такая необходимость есть, иногда нет.
За статью +, за выпрашивание инвайта -
А что, вот пусть сам Sergius Bobrovsky бы и написал статью в песочницу, как честные люди поступают
Уж не знаю как у других, но у меня с песочницой дружба «не срослась». У Сергея — тоже. Стати, которые нормально воспринимаются сообществом после получения инфайта, в песочницу или не проходят вообще без объяснения причин, или висят там незаметными. Данная статья из песочницы и есть.
а так нечестно, что ли?
Я дам инвайт
Не знаю как в C#, в Java можно подключать нативные Cшные библиотеки. Зачем городить огород, если можно просто заюзать?
например надо воспользоваться этой библиотекой в silverlight-приложении (ну или java-апплете), а там допускается только managed-код
В c# тоже можно использовать нативные dll. Другое дело, что такой подход имеет свои ограничения: он часто неприменим на веб-серверах (особенно в случае использования shared hosting), для некоторых приложений весьма вероятны проблемы, если идет частый обмен данными большого объема между managed и unmanaged кодом. В Silverlight приложениях такой подход вообще неприменим.
Потому я и описал этот способ, что столкнулся с невозможностью использовать p/invoke или COM Interop.
Потому я и описал этот способ, что столкнулся с невозможностью использовать p/invoke или COM Interop.
любопытный эволюционный подход. Постепенно меням под себя. Хоть и не пишу на си-шарпе, но понравилось
1.
на C# будет выглядеть так:
и не надо ничего мудрить
2. typedef vector<Command*> Commands;
будет выглядеть как:
using Commands = vector<Command*>;
case -1:
if ( line != buf + (bufsize - 1) )
continue;
/* falls through */
default:
на C# будет выглядеть так:
case -1:
if ( line != buf + (bufsize - 1) )
continue;
/* falls through */
goto default;
default:
и не надо ничего мудрить
2. typedef vector<Command*> Commands;
будет выглядеть как:
using Commands = vector<Command*>;
Найдут уязвимость или просто ошибку в «портированной» библиотеке — кто будет у вас её исправлять? Ведь фактически вы её не портировали, а форкнули.
Все зависит от ситуации. Если портируется собственный код компании (по какой-либо причине), то исправлять ошибку будет та же команда, что писала и оригинальный код. Если же портируется какая-то сторонняя библиотека или программа, то тут надежда только на свои силы / силы тех, кто будет пользоваться новой версией (если это разработчики и новая версия доступна в исходниках).
Поэтому я ни в коем случае не призываю портировать все, до чего дотянутся руки, а лишь описал способ, которым это можно сделать, если такая необходимость есть.
Поэтому я ни в коем случае не призываю портировать все, до чего дотянутся руки, а лишь описал способ, которым это можно сделать, если такая необходимость есть.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Затачиваем старый код под новые реалии