cliext :: list奇怪的行为 [英] cliext::list strange behavior

查看:105
本文介绍了cliext :: list奇怪的行为的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试使用cliext :: list<>并遇到了各种各样的问题-道歉,很长的时间-但请坚持我:).在开始之前,我将Visual Studio 2008与Service Pack 1一起使用.(相对)我是混合模式编程的新手-我的背景是纯C ++/MFC等-所以我完全有可能误解某些东西.我已将第一个问题简化为以下内容:

头文件:
#pragma一次

#include< cliext/list>

私有引用类TestClass
{
     cliext :: list< int> ^ m_list;
public:
      TestClass(void);
};


.cpp文件:

#include"StdAfx.h"
#include"TestClass.h"

TestClass :: TestClass(void)
:m_list(gcnew cliext :: list< int>())
{
}


产生了很多东西... (项目名称为LNK2022)

1> ------建立开始:项目:LNK2022,配置:Debug Win32 ------
1>链接...
1> ; TestClass.obj:错误LNK2022:元数据操作失败(80131188):重复类型中的字段声明不一致(类型:cliext.impl.list_impl< int,0> ;;字段:_Myhead):(0x0400000a).
1> TestClass .obj:错误LNK2022:元数据操作失败(80131188):重复类型中的字段声明不一致(类型:cliext.impl.list_impl< int,0> ;;字段:_Mysize):(0x0400000b).
1> TestClass.obj :错误LNK2022:元数据操作失败(80131188):重复类型中的字段声明不一致(类型:cliext.impl.list_impl< int,0> ;;字段:_Mygen):(0x0400000c).
1> TestClass.obj:er ror LNK2022:元数据操作失败(801311D7):重复类型中的字段数目不同(cliext.impl.list_impl< int,0> ;-):(0x02000023).
1> TestClass.obj:错误LNK2022:元数据操作失败(8013118B):重复类型中实现的接口不一致(类型:cliext.impl.list_impl< int,0>接口:System.Runtime.CompilerServices.CallConvStdcall):(0x09000001).
1> TestClass.obj:错误LNK2022:元数据操作失败(8013118B):重复类型中实现的接口不一致(类型:cliext.impl.list_impl< int ,0> ;;接口:System.IDisposable):(0x09000002).
1> TestClass.obj:错误LNK2022:元数据操作失败(8013118B):重复类型中实现的接口不一致(类型:cliext.impl.list_base< int ,0> ;;接口:System.Runtime.CompilerServices.CallConvFastcall):(0x09000003).
1> TestClass.obj:错误LNK2022:元数据操作失败(8013118B):重复类型中实现的接口不一致(类型:cliext.impl .list_base< int,0> ;;接口:System.Runtime.CompilerServices.CallConvThiscall):(0x09000004).
1> TestClass.obj:错误LNK2022:元数据操作失败(8013118D):重复类型中的布局信息不一致(cliext ._Dehandle< int--):(0x02000021).
1> TestC lass.obj:错误LNK2022:元数据操作失败(8013118D):重复类型中的布局信息不一致(cliext.is_handle< ;-):(0x02000022).
1> LINK:致命错误LNK1255:由于元数据而导致链接失败错误
1>构建日志保存在文件://i:\ dev \ ians stuff \ LNK2022 \ LNK2022 \ Debug \ BuildLog.htm"中.
1> LNK2022-11个错误,0警告( s)
==========构建:0成功,1失败,0最新,跳过0 =========



有人有什么想法吗?如果我在标题中初始化列表,程序将编译并链接.

好吧,我可以接受,除非我想在.cpp中隐藏构造函数的实现以减少依赖关系(我代码更复杂).

无论如何,下一个问题...

头文件:
#pragma一次

#include< cliext/list> ;

私有引用类TestClass
{
     ref struct SInside
    {
        int mem1;
     };

     cliext :: list< SInside ^> ^ m_list;

public:
     TestClass()
         :m_list(gcnew cliext :: list< SInside ^>())
     {}
};


这里没有特殊的火箭科学,嵌套结构用作列表容器的类型.请注意头文件中的初始化-从上面第一点的.cpp''cos中删除的构造函数.

一旦我们用以下形式的构造函数构造了一个TestClass类型的对象:


TestClass ^ tmp = gcnew TestClass();


我收到一个带有以下内容的消息框(我的测试应用程序编译为LNK2022.exe):

未处理的类型异常LNK2022.exe中发生"System.TypeLoadException"

其他信息:访问被拒绝:"Microsoft.VisualC.StlClr.IList`1 [TestClass + SInside]".


我真的甚至不确定这是想告诉我什么,但是我确实知道了-经过大量搜索和头部抓取(以及随机移动代码)后,-如果我将嵌套struct移到了类声明之外,一切都好.再次,在我的实际示例中,这减少了封装,并且我宁愿不这样做.

如果我将嵌套的结构移到该类的公共部分,那么一切都还可以.我已经尝试过使用std :: list进行等效操作,并且一切都很好(带有对象或指针列表).

问题是,我是否在尝试做一些不受支持的事情,是否做了一些事情?显然是错误的,还是STL.net库中的错误?

< div class ="ForumMod">于2008年8月27日星期三9:38 AM</div>

I am trying to use a cliext::list<> and am hitting various problems - apologies, its a long one - but stick with me :) . Before I start, I am using Visual Studio 2008 with service pack 1. I am (relatively) new to mixed mode programming - my background is pure C++ / MFC, etc - so it is entirely possible I am misunderstanding something. I have reduced my first problem to the following:

Header file:

#pragma once

#include <cliext/list>

private ref class TestClass
{
      cliext::list<int> ^ m_list;
public:
      TestClass(void);
};


.cpp file:

#include "StdAfx.h"
#include "TestClass.h"

TestClass::TestClass(void)
: m_list(gcnew cliext::list<int>())
{
}


Produces this little lot... (project name is LNK2022)

1>------ Build started: Project: LNK2022, Configuration: Debug Win32 ------
1>Linking...
1>TestClass.obj : error LNK2022: metadata operation failed (80131188) : Inconsistent field declarations in duplicated types (types: cliext.impl.list_impl<int,0>; fields: _Myhead): (0x0400000a).
1>TestClass.obj : error LNK2022: metadata operation failed (80131188) : Inconsistent field declarations in duplicated types (types: cliext.impl.list_impl<int,0>; fields: _Mysize): (0x0400000b).
1>TestClass.obj : error LNK2022: metadata operation failed (80131188) : Inconsistent field declarations in duplicated types (types: cliext.impl.list_impl<int,0>; fields: _Mygen): (0x0400000c).
1>TestClass.obj : error LNK2022: metadata operation failed (801311D7) : Differing number of fields in duplicated types (cliext.impl.list_impl<int,0>-): (0x02000023).
1>TestClass.obj : error LNK2022: metadata operation failed (8013118B) : Inconsistent implemented interfaces in duplicated types (types: cliext.impl.list_impl<int,0>; interfaces: System.Runtime.CompilerServices.CallConvStdcall): (0x09000001).
1>TestClass.obj : error LNK2022: metadata operation failed (8013118B) : Inconsistent implemented interfaces in duplicated types (types: cliext.impl.list_impl<int,0>; interfaces: System.IDisposable): (0x09000002).
1>TestClass.obj : error LNK2022: metadata operation failed (8013118B) : Inconsistent implemented interfaces in duplicated types (types: cliext.impl.list_base<int,0>; interfaces: System.Runtime.CompilerServices.CallConvFastcall): (0x09000003).
1>TestClass.obj : error LNK2022: metadata operation failed (8013118B) : Inconsistent implemented interfaces in duplicated types (types: cliext.impl.list_base<int,0>; interfaces: System.Runtime.CompilerServices.CallConvThiscall): (0x09000004).
1>TestClass.obj : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (cliext._Dehandle<int>-): (0x02000021).
1>TestClass.obj : error LNK2022: metadata operation failed (8013118D) : Inconsistent layout information in duplicated types (cliext.is_handle<int>-): (0x02000022).
1>LINK : fatal error LNK1255: link failed because of metadata errors
1>Build log was saved at "file://i:\dev\ians stuff\LNK2022\LNK2022\Debug\BuildLog.htm"
1>LNK2022 - 11 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========



Does anyone have any ideas? If I initialise the list in the header, the program compiles and links ok.

Ok, fine, I can live with that unless I want to hide my implementation of the constructor in the .cpp to reduce dependencies (my code is more complicated).

Anyway, next problem...

Header file:

#pragma once

#include <cliext/list>

private ref class TestClass
{
     ref struct SInside
     {
          int mem1;
     };

     cliext::list<SInside ^> ^ m_list;

public:
     TestClass()
          : m_list(gcnew cliext::list<SInside ^>())
     {}
};


No particular rocket science here, a nested struct being used as the type for the list container. Note initialisation in header - constructor removed from .cpp ''cos of point one above.

As soon as we construct the an object of type TestClass with the following in the form constructor:


TestClass ^ tmp = gcnew TestClass();


I get a message box with the following (my test app compiles to LNK2022.exe):

An unhandled exception of type ''System.TypeLoadException'' occurred in LNK2022.exe

Additional information: Access is denied: ''Microsoft.VisualC.StlClr.IList`1[TestClass+SInside]''.


I am really not sure even what this is trying to tell me, but what I do know - after a lot of searching and head scratching (and randomly moving code) - if I move the nested struct outside of the class declaration, everything is fine. Again, in my real example this reduces my encapsulation, and I would rather not do it if possible.

If I move the nested struct to a public section of the class, all is ok too. I have tried the equivalent using std::list, and again all is fine (with a list of objects or pointers).

Question is, am I trying to do something that is not supported, have I done something obviously wrong, or is this a bug in the STL.net library?

<div class="ForumMod">modified on Wednesday, August 27, 2008 9:38 AM</div>

推荐答案

I认为由于STL/CLR中使用了泛型,因此您需要将ref struct SInside访问级别设置为公共".但是,如果仅在同一程序集中访问该ref struct SInside,则可以将其访问级别设为内部"或受保护的公共".

I think you need to make ref struct SInside access level "public" due to the usage of generics in STL/CLR. However, if this ref struct SInside is only going to be accessed within the same assembly, you can make it''s access level "internal" or "protected public".


这篇关于cliext :: list奇怪的行为的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆