create vector in C++/Clr

Question

0.00/5 (No votes)

See more:

I have converted a console application of a OCR application to a windows form application.The program runs accurately on console application but after converting it gives error for the vector that I have used to store image set.I have changed the configuration properties to Common Language Runtime Support (/clr) and I changed the header file cliext since clr does not support for std/vector. This is my code.But still it has errors.

C++

#pragma once
#include <opencv\highgui.h>
#include <string>
#include <cliext/vector>

ref class Segmentation
{
public:
    IplImage *PreprocessedImage;
    cliext::vector<IplImage *> Lineimgs;
    cliext::vector<IplImage *> Characterimgs;
    Segmentation(IplImage *);
    ~Segmentation(void);
    IplImage* Resize(IplImage *);
    void Horizontal_projection(int,int,int,int *);
    int Vertical_Projection(int,int);
};

The error is

VB

Error   1   error C3225: generic type argument for 'TValue' cannot be '_IplImage *', it must be a value type or a handle to a reference type    C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\cliext\vector    14  1   Prototype 3

Please help me with this problem.Thank You

Posted 3-Jun-13 4:03am

123ezone

Updated 3-Jun-13 4:09am

v4

Add a Solution

Comments

Santhosh G_ 3-Jun-13 11:34am

Is it possible to create vector as a native type, say long.
Then convert IplImage* to long while inserting an IplImage* instance to the vector and
convert long to IplImage* while retrieving IplImage* from vector.

cliext::vector<<long>> Lineimgs;

Lineimgs.push_back((long) new IplImage);
IplImage* pTemp = (IplImage*)Lineimgs[nIndex];

123ezone 3-Jun-13 12:36pm

Thank You very much. It helped to fix those errors.I'm still struggling with converting my console application to a windows form application.I think now my code has no other error but 25 of this kind of errors which I cannot fix.

Error 1 error LNK2001: unresolved external symbol "public: virtual void __thiscall cv::HOGDescriptor::setSVMDetector(class cv::_InputArray const &)" (?setSVMDetector@HOGDescriptor@cv@@UAEXABV_InputArray@2@@Z)

Please Can you help me with this problem.Thank you.

Philippe Mori 3-Jun-13 19:59pm

You can still uses std containers in mixed mode... I uses a l lot of them before converting my application to compile in pure or safe mode (one reason was to be able to eventually use Any CPU mode so that my application would run in 64 bit on 64 bit processor).

By the way some errors are definitively bugs in the compiler or linker. When I tried to converter std container to cliext one, there were some unexpected errors.

As implied by my solution, either you should use std containe on umanaged types or uses .NET containers on managed types. cliext containers give unexplainable errors in perfectly valid cases (for example a container might works only with value type or reference type when it should works with both). If I remember well, I had much problems with cliext::deque.

Santhosh G_ 3-Jun-13 12:39pm

Please ensure required libraries for opencv is added in additional libraries.

123ezone 3-Jun-13 12:45pm

I have used same additional libraries that I used for the console application and it worked.

2 solutions

Solution 1

There is no such thing as C++/Clr, it's C++/CLI:
http://en.wikipedia.org/wiki/C%2B%2B/CLI[^],
http://www.ecma-international.org/publications/standards/Ecma-372.htm[^].

I would not advise to mix up managed "ref" code with unmanaged unless it is absolutely needed, even if you use mixed-mode projects. On managed (.NET) part, you should better use System::Collections::Generic::List generic class:
http://msdn.microsoft.com/en-us/library/6sh2ey19%28v=vs.110%29.aspx[^].

Mixing managed and unmanaged code is generally done like this: you wrap some unmanaged code in managed "ref" C++/CLI class and expose purely managed members. Or visa versa.

—SA

Posted 3-Jun-13 5:21am

Sergey Alexandrovich Kryukov

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Philippe Mori · Accepted Answer · 2013-06-03T13:55:00

If you want to hold native type, then you should uses std::vector. You can uses std::vector under C++/CLI provided that you use /clr option.

cliext container would works with managed types and not native types. Sometime you get weird compilation or link error when using cliext containers. In my application I have finally abandonned cliext containers as it was too much trouble mainly because of limitation of the compiler, language and libraries.

In my opinion, C++/CLI and managed STL were not properly designed. As a result, it does not integrate well with C++. I would think that C++/CLI was not design with STL in mind (or more generally all related principles). Thus it was not possible to reuse standard STL algorithms (and container) directly as it should have been the case if there were not all those artificial différences like using ^, % and gcnew instead of *, & and new.

Although the performance of STL in mixed mode code is not as good as someone would expect. Generally using .NET containers is faster. I don't know the exact reason...