0

i have the following header file(data.h):

#pragma once
#include <cliext\vector>
#include <msclr\marshal_cppstd.h>
using namespace msclr::interop;
using namespace MySql::Data::MySqlClient;
using namespace System;
using namespace System::ComponentModel;
using namespace System::Collections;
using namespace System::Windows::Forms;
using namespace System::Data;
using namespace System::Drawing;
ref class data
{
private:
    bool connect(MySqlConnection^ &conDatabase);
    MySqlCommand^ query(String^ qry,MySqlConnection^ conDatabase);
public:

    cliext::vector< String^ > viewCourses(int department,int sem);

};

and the following cpp file (data.cpp):

#include "StdAfx.h"
#include "data.h"

bool data::connect(MySqlConnection^ &conDatabase)
{
    String ^constring=L"datasource=localhost;port=3306;username=root;password=root";
    conDatabase=gcnew MySqlConnection(constring);
    return true;
}

MySqlCommand^ data::query(String^ qry,MySqlConnection^ conDatabase)
{
    MySqlCommand ^cmdDatabase=gcnew MySqlCommand(qry,conDatabase);
    return cmdDatabase;
}

cliext::vector< String^ >  data::viewCourses(int department,int sem) 
{
     cliext::vector< String^ > courses;
     return courses;


}

This is giving me the following linker error:

 error LNK2022: metadata operation failed (801311D7) : Differing number of fields in duplicated types (cliext.impl.vector_impl<System::String ^,0>):

This is only happening whenever i am trying to use cliext::vector as a return type. This error is vanishing when i am using std::vector< std::string > as return type but I want to return a vector of String^ . I am not able to figure out what is causing this error. This error happens only when using cliext::vector as return type , when i use it for general processing then also it is working fine.

user2179293
  • 425
  • 9
  • 22
  • 2
    Template linking errors are always hard to diagnose and we can't see where else you use it. Just another good reason to not use STL/CLR, it [is horrible](http://www.codeproject.com/Articles/24206/A-look-at-STL-CLR-performance-for-linear-container). And pointless when used in a public method, it can't be called by another other managed language. Use `List` instead. – Hans Passant Feb 20 '14 at 14:28
  • @HansPassant Actually I wanted a 2d string array with 4 columns and variable number of rows. I tried using `List < List^ >` but it was showing error : ref class does not have a copy constructor. So I moved to clr/stl vector but found out that `vector` itself was not compiling. Presently I am using std::vector with std::string as `std::vector< std::vector < std::string> >` and using marshal_as to convert it back to String. Can you suggest any alternatives. – user2179293 Feb 20 '14 at 14:42
  • 1
    You are just not writing correct code when you get that compile error, usually forgetting the ^ hat in a declaration. Don't let a simple compile error bog you down like this. – Hans Passant Feb 20 '14 at 14:46
  • But why do we need a extra ^ at the end – user2179293 Feb 20 '14 at 14:49
  • 1
    Variables that store a reference to a .NET reference type should be declared with the hat. Just like you'd use & in native C++. Forget one and it is going to try to copy the object instead of the reference and that invariably ends up poorly since managed reference types don't have an automatic copy constructor. Covered pretty well in any introductory text on C++/CLI btw. Fwiw, it is the copy semantics that makes STL/CLR so doggone slow. – Hans Passant Feb 20 '14 at 15:00

1 Answers1

0

I got the same error when trying to pass cliext::vectorSystem::String^ as an argument to a function. If I declare a variable of type cliext::vectorSystem::String^ , then the error is gone(even if i am not using this variable anywhere in my program).

  • Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Feb 21 '23 at 13:58