ИзопропилandreybsКороче, не работает. Ваши предложения, по настройке проекта?
блд, русским языком говорил - /clr:safe или /clr:pure

Да блин, а это что? 38 попугаев??

andreybsДалее меняем на "CLR-поддержка безопасного MSIL (/clr:safe)".

CREATE ASSEMBLY for assembly 'TestCPP' failed because the assembly is built for an unsupported version of the CLR runtime.


Строка компоновщика:

/Yu"stdafx.h" /GS /analyze- /W3 /Zc:wchar_t /Zi /Od /Fd"Debug\vc110.pdb" /fp:precise /D "WIN32" /D "_DEBUG" /D "_WINDLL" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /Oy- /clr:pure /FU"C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll" /FU"C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll" /FU"C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll" /FU"C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll" /MDd /Fa"Debug\" /EHa /nologo /Fo"Debug\" /Fp"Debug\TestCPP.pch"

Только толку от этого нет. Работает только через Platform Invoke. А это черте-что цеплять DLL на C#, которая цепляет другую DLL на С++. Как этого монстра дебагить ваще не ясно.

Изопропил- только возможкности ничем не будкут отличасться от c#

Вот именно. CLR он и в африке CLR. Тогда что говорить о том, что код С++ в два раза быстрее?

SeVaЕсли нужно быстродействие,то зачем какие-то бубны со сборками в sql server?

Ваши варианты? Пользовательское приложение? Я пока не придумал, как взаимодействовать с ним из БД. Предполагается, что источник вызова на вычисление - ХП в БД.

ИзопропилandreybsПредполагается, что источник вызова на вычисление - ХП в БД.
попробуйте вызвать ХП из клиентского приложения.

Это кажется более разумным, чем WCF. Как-то не верится, что HTTP-шная прослойка (мы же о веб-сервисах горовим, если я не ошибаюсь) обеспечит быстрое взаимодействие со сборкой. Возможно, перенос управления в модуль C++ (клиентское приложение) будет самым производительным и верным решением. Попробую реализовать такой вариант, посмотрим, как это повлияет на производительность.

ИзопропилandreybsWCF
это для управления, а не для вычислений - вроде с управлением траблы были

В этом плане проще тогда создать интерфейсную табличку в БД и постоянно "слушать" ее. Тот же WCF, только без HTTP.

Я придумал, как организовать взаимодействие - консольная программа, звпускаемая "on demand" через shell или джоб со стороны sql-сервера. Ограничение только одно - она не должна запускаться слишком часто, т.к. процессы запуска приложения в Windows несут большие временные затраты. Это похоже на механизм работы агента репликации, который так же запускается и висит в памяти до тех пор, пока джоб не остановят.

beg-in-erпри построении в памяти естесно лучше использовать типа стека, а после перехерачивать в массив. ToArray()


Копирование из массива в массив (в моем случае копирование таких массивов тысячи) слишком затратно по операциям. Нужно сразу писать в рабочий массив.

beg-in-erещё раз. улучшив алгоритм можно качественно улучшить скорость. гонка за запятую даст слишком мало прироста.
уж что что а прирост может дать совершенно другие вещи. как то другой проц ( типа extream edition ) или GPU, генерация кода под специфику задачи, отказ от рекурсий, отказ от LINQ..... - это много эффективнее , чем ловля блох.

Согласен. Поэтому решу задачу на С++ в виде отдельного приложения, а там посмотрим. Есть у меня пара идей, ка на инлайн ассемблере все в разы ускорить...

ИзопропилAssembler - это опять преждевременная оптимизация

Ладно, ладно, это далекая перспектива, но вполне реальная. О ней позже, сначала С++. Давно писал кучу приложений на С++ Builder по работе с БД, а на VC++ такое ПО не писал - что то немного застрял разбираясь, как к проекту консольного приложения библиотеки adodb подцепить, чтобы нативный доступ к SQL-сервер организовать...

Изопропилandreybsкак к проекту консольного приложения библиотеки adodb подцепить


http://msdn.microsoft.com/en-us/library/windows/desktop/ms675103(v=vs.85).aspx

Вот спасибо! Как раз включил комп, ща закодим...

Я сделал вчера замеры вычислений простенькой нейросети в сборке на С#, реализую аналогичный алгоритм на С++ и сравню результаты производительности по той же сети. Самому интересно - одно дело статьи читать, а другое дело в живую убедиться.

Наконец то добрался до своей задачи, сейчас пишу компактную библиотеку оберточных классов для ADO DB под мою задачу.

Есть вопрос... Для сохранения высокой производительности нужно максимально эффективно организовать работу с БД. Для этого нужно избегать многократной перекомпиляции одинаковых запросов. Для этого запросы нужно писать с использованием параметров. Все работает отлично, но один момент мне не нравится... Есть маленькое неудобство, которое заключается в том, что при создании параметра приходится указывать тип DataTypeEnum, значение _variant_t и размер long. Очевидно, что в большинстве случаев можно на основании типа значения _variant_t.vt извлечь и тип значения и его размер, сократив таким образом количество входных параметров на два.

Мне не удается найти описание типа VARTYPE. Например, здесь есть только часть возможных значений

Вообще, какие существуют УНИВЕРСАЛЬНЫЕ (т.е. не зависящие от значения _variant_t) способы извлечения DataTypeEnum и размера данных из переменной _variant_t?

Изопропилandreybs,

ADO DB - это и так обёртка над OLEDB для скриптовых языков - отсюда и VARIANT
вместо VARIANT можно использовать CComVariant ( это обёртка над VARIANT )
полное описание в wtypes.h и http://msdn.microsoft.com/en-us/library/windows/desktop/ms221170(v=vs.85).aspx

если не хочется возиться с OLE - ODBC используй.

Именно этот кодификатор мне и нужен, спасибо!

Я сделал обертку только части функций ado, сгруппировав их конкретно под мою задачу. Максимально компактно и без лишних наворотов, исключительно для удобства использования и читабельности кода.

А по поводу odbc не уверен, что он подойдет. У меня используется много специфики от sql-сервера - работа с временными таблицами, табличными функциями, прямая-обратная передача параметров и пр. Не факт, что это будет поддерживаться в odbc. Так что я повожусь с ole... :) Тем более, что уже библиотечку написал, оттестировал и подготовил к работе.

ИзопропилandreybsУ меня используется много специфики от sql-сервера
тогда OLEDB лучше чем ADODB, хотя на старте усилий больше потребует

А чем принципиально лучше? Производительность? Если да, то можно ли как-то оценить ожидаемый прирост производительности до того, как углубляться в OLE? Со временем могу свою обертку переделать на OLE вместо ADO.

ИзопропилandreybsА чем принципиально лучше?
вроде ж табличные параметры передавать хотел - http://msdn.microsoft.com/ru-ru/library/ff877933.aspx

Я говорил о табличных функциях и возвращаемых параметрах, но не важно... Я как-то не думал, что мне потребуется работать с табличными переменными, хотя эта идея тоже хорошая. Буду иметь ввиду, что это через OLE DB можно реализовать. Спасибо за инфу!

Хотел уточнить по поводу хранения кода методов классов в памяти...

Правильно ли я понимаю, что:
1. объект класса хранит лишь таблицу указателей на экземпляры методов класса
2. все экземпляры методов всех классов хранятся в одной и той же области памяти программы
3. для всех объектов одного и того же класса используются одни и те же экземпляры методов (т.е. число экземпляров методов классов не увеличивается с увеличением числа объектов классов)
4. размер памяти, выделяемой на хранение объекта класса, увеличивается на N байт при добавлении в класс нестатического метода, где N-размер ссылки в текущем адресном пространстве памяти (обычно 4 байта, для x32)

Изопропилandreybs,

1) да, адрес таблицы
2) все экземпляры методов - что имеется ввиду? Код общий, хранится в сегменте кода
3) да, но забудьте про "экземпляры методов", в с++/c# все экземпляры класса разделяют код
4) нет, увеличивается только размер таблицы методов, которая одна на класс.

P.S. детали(ка-то метаданные, виртуальные методы, отличия c# от с++) опущены

Ясно, спасибо.

А конструкторы тоже хранятся в памяти, как обычные методы в общем сегменте кода? Вопрос возник в связи с тем, что конструкторы могут быть включены в состав структуру (struct), у которой не должно быть таблицы методов в отличие от классов (class).