Вопрос, может сталкивался кто с подобной задачей:
Что бы вы делали, какой инструментарий и библиотеки использовали если бы Вам нужно было конвертировать C# проект
(с частью .Net фреймворка, но это пока не так важно), который опирается одновремено на Generic и конкретные типы.
Т.е. что то типа членов Object, List, List<int>, при чем например List вполне может хранить еще один List....
Мне приходит на ум: boost::shared_ptr, boost::any, boost::any_cast и т.д.
Но может кто знает реальный опыт который можно было бы почтитать, посмотреть как делали другие.
З.Ы.
Только не надо меня спрашивать зачем, у меня честно, нет ответа на этот вопрос.
Про MONO я тоже в курсе.
Здравствуйте, nen777w, Вы писали:
N>Вопрос, может сталкивался кто с подобной задачей: N>Что бы вы делали, какой инструментарий и библиотеки использовали если бы Вам нужно было конвертировать C# проект N>(с частью .Net фреймворка, но это пока не так важно), который опирается одновремено на Generic и конкретные типы. N>Т.е. что то типа членов Object, List, List<int>, при чем например List вполне может хранить еще один List....
именно такую задачу не решал, но рассмотрел бы два варианта:
1) переписать в стиле C++ (без boost::any и тд )
2) затащить как .Net сборку в плюсовое приложение
надо больше специфики знать, чтобы принять решение. объем кода, специфика кода, в какие приложения и с какой целью затаскивать, требования к производительности / портабельности / гибкости дизайна
Здравствуйте, nen777w, Вы писали:
N>Вопрос, может сталкивался кто с подобной задачей: N>Что бы вы делали, какой инструментарий и библиотеки использовали если бы Вам нужно было конвертировать C# проект N>(с частью .Net фреймворка, но это пока не так важно), который опирается одновремено на Generic и конкретные типы. N>Т.е. что то типа членов Object, List, List<int>, при чем например List вполне может хранить еще один List....
В общем случае понадобится реализация сборщика мусора на C++.
Соответственно, все умные указатели придётся переделать под сборщик мусора.
Без GC кольцевые ссылки будут утекать.
Если реализация алгоритма не допускает кольцевые ссылки, то можно и без сборщика мусора.
Задача решаема в обоих случаях.
Потребуется парсер C#, модифицированный компилятор C# с возможностью строить AST C++ и его печатью в файлы.
Немерле может помочь, на мой взгляд.
PS: У меня была похожая задача по автоматизации конверсии Java 6 -> С++.
Здравствуйте, MTD, Вы писали:
N>>Но может кто знает реальный опыт который можно было бы почтитать, посмотреть как делали другие.
MTD>Я писал транслятор с шарпа в плюсы. Использовал сборщик мусора и либу для разбора шарповых проектов. Ты задай вопрос поконкретней, попробую помочь.
N>>Но может кто знает реальный опыт который можно было бы почтитать, посмотреть как делали другие. MTD>Я писал транслятор с шарпа в плюсы. Использовал сборщик мусора и либу для разбора шарповых проектов.
Круто, а как это потом использовалось?
MTD>Ты задай вопрос поконкретней, попробую помочь.
Да есть. Ну вот например. Возьмём класс List он наследует IEnumerable, ICollection ну и т.д.
Как Вы поступали когда писали свой проект?
Т.к. методы типа Current() в C# вовзращают Object то что делали вы:
1) Писали базовый Object (но тогда возникает невозможность применения POD типов C++, т.е. нужно писать свои классы типа:
struct Int : Object {
explicit Int(int n) : val( n ) {}
int operator=(int n) { val = n; }
operator int() const { return val; }
System::String ToString() const {...} (это если String тоже написан)
... ну еще до кучи всяких операторов
};
2) Забили на Object использовали например boost::any т.е. теперь Current() например возвращает boost::any и вообще везде в коде где Object то boost::any
Соответсвенно boost::any_cast и метод boost::any::type() который typeid возвращает, что бы например можно было проверить лежит ли там такой тип.
Ну еще я думаю boost::shared_ptr, использовали наверно его тоже в полный рост. Если например проблем с циклическими ссылками нет.
В свое время делал для 1С классов диспинтерфейсы. Но для нетовских классов легко через рефлексию написать обертки которые делают вызовы через IDispatch
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, nen777w, Вы писали:
N>Круто, а как это потом использовалось?
Либы на шарпе транслируются в плюсовый код, собранные бинарники линкуются в плюсовые приложения.
N>Да есть. Ну вот например. Возьмём класс List он наследует IEnumerable, ICollection ну и т.д. N>Как Вы поступали когда писали свой проект?
Был выбран наиболее простой и прямолинейный путь — затащить сборщик мусора и повторить всю иерархию классов.
N>Т.к. методы типа Current() в C# вовзращают Object то что делали вы:
Так же возвращаю Object.
N>1) Писали базовый Object (но тогда возникает невозможность применения POD типов C++, т.е. нужно писать свои классы типа:
Так точно, но зачем в транслированном коде POD типы С++? Это сильно бы все усложнило, а была ли выгода мне не известно.
N>Ну еще я думаю boost::shared_ptr, использовали наверно его тоже в полный рост. Если например проблем с циклическими ссылками нет.
Ага, циклические ссылки и приплыли. Если интересует скорость получившегося решения, то по памяти экономия приличная — до 2-3 раз, по скорости процентов на 10 быстрее оригинала. Транслируется код C# 2.0, то есть Linq и лямбд нет.
N>>Круто, а как это потом использовалось? MTD>Либы на шарпе транслируются в плюсовый код, собранные бинарники линкуются в плюсовые приложения.
Если не секрет, приходилось потом руцями всё дорабатывать или автоматом всё сразу компилировалось?
И еще интересна судьба этого вашего конвретора С#->C++, он где то лежит, может продается?
N>>Да есть. Ну вот например. Возьмём класс List он наследует IEnumerable, ICollection ну и т.д. N>>Как Вы поступали когда писали свой проект? MTD>Был выбран наиболее простой и прямолинейный путь — затащить сборщик мусора и повторить всю иерархию классов.
Понятно, надо подумать над таким вариантом. Если не секрет почему решили делать так?
N>>Т.к. методы типа Current() в C# вовзращают Object то что делали вы: MTD>Так же возвращаю Object. N>>1) Писали базовый Object (но тогда возникает невозможность применения POD типов C++, т.е. нужно писать свои классы типа: MTD>Так точно, но зачем в транслированном коде POD типы С++? Это сильно бы все усложнило, а была ли выгода мне не известно.
Да это я в прошлый раз не дописал, просто есть вариант посмотрить всё на шаблонах т.е. template<typename T> List {...}; соответсвено эти всякие
IEnumerable, ICollection тоже такими делать прийдется, отсюда и то что делать с POD типами. Но в сл, их замешеением самописными,
типа struct Int {}; такой проблемы конечно не возникает и можно использовать Object.
N>>Ну еще я думаю boost::shared_ptr, использовали наверно его тоже в полный рост. Если например проблем с циклическими ссылками нет. MTD>Ага, циклические ссылки и приплыли. Если интересует скорость получившегося решения, то по памяти экономия приличная — до 2-3 раз, по скорости процентов на 10 быстрее оригинала. Транслируется код C# 2.0, то есть Linq и лямбд нет.
Прикольно, это полезная информация. Если не секрет, большой ли это был проект и стал ли он после этого кросс-платформенным (это если специфики никакой Windows небыло конечно).
Здравствуйте, nen777w, Вы писали:
N>Если не секрет, приходилось потом руцями всё дорабатывать или автоматом всё сразу компилировалось?
Все автоматом.
N>И еще интересна судьба этого вашего конвретора С#->C++, он где то лежит, может продается?
Нет, для внутреннего использования.
MTD>>Был выбран наиболее простой и прямолинейный путь — затащить сборщик мусора и повторить всю иерархию классов.
N>Понятно, надо подумать над таким вариантом. Если не секрет почему решили делать так?
Так проще всего для реализации.
N>Да это я в прошлый раз не дописал, просто есть вариант посмотрить всё на шаблонах т.е. template<typename T> List {...}; соответсвено эти всякие
Шаблоны есть, одно другому не мешает или я что не понял.
N>типа struct Int {}; такой проблемы конечно не возникает и можно использовать Object.
Везде где можно я использую примитивные типы, но в шарпе они прозрачно приводятся к Object и обратно — боксинг. Определить такие преобразования можно на этапе компиляции, поэтому у меня примитивы когда надо упаковываются в класс производный от Object и соответственно обратно с проверкой типа и выбросом в случае чего исключения — все как в оригинале.
N>Прикольно, это полезная информация. Если не секрет, большой ли это был проект и стал ли он после этого кросс-платформенным (это если специфики никакой Windows небыло конечно).
Либы в полмилиона строк. Кроссплатформеность ключевое требование.
N>>Если не секрет, приходилось потом руцями всё дорабатывать или автоматом всё сразу компилировалось? MTD>Все автоматом.
Ого. Круто, реально ркуто т.к. ИМХО практически не решаемая задача.
N>>И еще интересна судьба этого вашего конвретора С#->C++, он где то лежит, может продается? MTD>Нет, для внутреннего использования.
И никак нельзя его купить?
MTD>>>Был выбран наиболее простой и прямолинейный путь — затащить сборщик мусора и повторить всю иерархию классов. N>>Понятно, надо подумать над таким вариантом. Если не секрет почему решили делать так? MTD>Так проще всего для реализации.
Понятно спасибо, подумю над этим.
N>>Да это я в прошлый раз не дописал, просто есть вариант посмотрить всё на шаблонах т.е. template<typename T> List {...}; соответсвено эти всякие MTD>Шаблоны есть, одно другому не мешает или я что не понял.
Да я просто для себя уточняю, заложив неправильную базу можно потом на грабельках танцевать бесконечно, потому и собираю опыт других.
Т.е. еще раз, если не сложно, тот же IEnumerator у Вас выглядит примерно вот так:
namespace System { namespace Collections {
template<typename T>
struct IEnumerator {
typedef T value_type;
typedef IEnumerator<T> this_type;
virtual System::Object* Current() const = 0; //<<--
/*
Т.е. тут т.к. используется GC возвращаем raw указатель (без никаких shared_ptr)
И к тому же Object (хотя есть соблазн возвращать T - как бы более С++-нуто.)
*/virtual bool MoveNext() = 0;
virtual void Reset() = 0;
};
}}
N>>типа struct Int {}; такой проблемы конечно не возникает и можно использовать Object. MTD>Везде где можно я использую примитивные типы, но в шарпе они прозрачно приводятся к Object и обратно — боксинг. Определить такие преобразования можно на этапе компиляции, поэтому у меня примитивы когда надо упаковываются в класс производный от Object и соответственно обратно с проверкой типа и выбросом в случае чего исключения — все как в оригинале.
Понял, спасибо, ценная информация.
N>>Прикольно, это полезная информация. Если не секрет, большой ли это был проект и стал ли он после этого кросс-платформенным (это если специфики никакой Windows небыло конечно). MTD>Либы в полмилиона строк. Кроссплатформеность ключевое требование.
У меня те же требования.
Здравствуйте, nen777w, Вы писали:
N>>>И еще интересна судьба этого вашего конвретора С#->C++, он где то лежит, может продается? MTD>>Нет, для внутреннего использования.
N>И никак нельзя его купить?
Кстати, MTD, а нет настроения актуализировать свой компилятор для современных версий .NET и выпустить его самостоятельным продуктом? Могло бы пользоваться спросом, имхо.
Здравствуйте, nen777w, Вы писали:
N>Т.е. еще раз, если не сложно, тот же IEnumerator у Вас выглядит примерно вот так:
IEnunerator в C# аж 2 — System.Collections.IEnumerator и System.Collections.Generic.IEnumerator<T>. И Current в первом случае возвращает Object, а во втором T. Поэтому первый случай у меня частный случай второго с некоторыми оговорками (конкретно для этих интерфейсов в трансляторе свой сценарий преобразований из простого в первого во второй). Объявление выглядит примерно так:
namespace System
{
namespace Collections
{
namespace Generic
{
template<typename T>
struct IEnumerator
: public System::Collections::IEnumerator
// Да, в C# можно написать:
// System.Collections.Generic.IEnumerator<int> i1 = null;
// System.Collections.IEnumerator i2 = i1;
{
DECLARE_TYPE_INFO
virtual bool MoveNext() = 0;
virtual void Reset() = 0;
virtual T GetCurrent() = 0; // К свойствам лепится Get и Set
};
}
}
}
Здравствуйте, Marty, Вы писали:
M>Кстати, MTD, а нет настроения актуализировать свой компилятор для современных версий .NET и выпустить его самостоятельным продуктом?
Я таких решений не принимаю, если компания решит, что так нужно — займусь с удовольствием.
Здравствуйте, MTD, Вы писали:
M>>Кстати, MTD, а нет настроения актуализировать свой компилятор для современных версий .NET и выпустить его самостоятельным продуктом?
MTD>Я таких решений не принимаю, если компания решит, что так нужно — займусь с удовольствием.
Спасибо за ответ.
А вот еще интересно как поступали с более сложными классами типа StreamReader, TextReader, Encoder, Decoder, ASCIIEncoding, UTF7Encoding, ... во общем тем зоопарком который тянет за собой массу других классов.
Портировали по сырцам MONO, или что то свое писали?
F3V>В общем случае понадобится реализация сборщика мусора на C++. F3V>Соответственно, все умные указатели придётся переделать под сборщик мусора. F3V>Без GC кольцевые ссылки будут утекать. F3V>Если реализация алгоритма не допускает кольцевые ссылки, то можно и без сборщика мусора. F3V>Задача решаема в обоих случаях.
Хотят без GC, циклических ссылок вроде нет, хотя в свте того что хотят без GC это уже проблемы C# команды об этом позаботиться.
Судя по ответу MTD о производительности
Если интересует скорость получившегося решения, то по памяти экономия приличная — до 2-3 раз, по скорости процентов на 10 быстрее оригинала.
хотят производительности еще больше, хотя с GC было бы проще.
F3V>Потребуется парсер C#, модифицированный компилятор C# с возможностью строить AST C++ и его печатью в файлы. F3V>Немерле может помочь, на мой взгляд.
Да есть уже такой проект, развивается потихоньку, результаты тоже вроде ничего.
F3V>PS: У меня была похожая задача по автоматизации конверсии Java 6 -> С++.
Тут вам повезло больше. Одна из громадных проблем которую надо будет как то решить это .Net фреймворк.
А это где то ~470 классов из .Net которые прямо или косвено используютсяв проекте который надо портировать (смотрел запросами в ReSahrp-ере).
Благо с Java всё проще в этом плане, то что фреймворки похожи, в том числе и с GC.
)
