首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    SWIG 官方文档第三部分 - 机翻中文人肉修正

    很有可能,您正在阅读本章是出于以下两个原因之一;您要么想自定义 SWIG 的行为,要么无意中听到有人嘟囔着一些关于“typemaps”的难以理解的胡言乱语,然后问自己“typemaps,那些是什么?” 也就是说,让我们先做一个简短的免责声明,即“Typemaps”是一种高级自定义功能,可以直接访问 SWIG 的低级代码生成器。不仅如此,它们还是 SWIG C++ 类型系统(它自己的一个重要主题)的组成部分。typemaps 通常不是使用 SWIG 的必需部分。因此,如果您已经找到了进入本章的方法,并且对 SWIG 默认情况下已经做了什么只有一个模糊的概念,那么您可能需要重新阅读前面的章节。

    03

    LPCTSTR类型

    如何理解LPCTSTR类型? L表示long指针 这是为了兼容Windows 3.1等16位操作系统遗留下来的,在win32中以及其他的32为操作系统中, long指针和near指针及far修饰符都是为了兼容的作用。没有实际意义。 P表示这是一个指针 C表示是一个常量 T表示在Win32环境中, 有一个_T宏 这个宏用来表示你的字符是否使用UNICODE, 如果你的程序定义了UNICODE或者其他相关的宏,那么这个字符或者字符串将被作为UNICODE字符串,否则就是标准的ANSI字符串。 STR表示这个变量是一个字符串 所以LPCTSTR就表示一个指向常固定地址的可以根据一些宏定义改变语义的字符串。 同样, LPCSTR就只能是一个ANSI字符串,在程序中我们大部分时间要使用带T的类型定义。 LPCTSTR == const TCHAR * CString 和 LPCTSTR 可以说通用。 原因在于CString定义的自动类型转换,没什么奇特的,最简单的C++操作符重载而已。 常量字符串ansi和unicode的区分是由宏_T来决定的。但是用_T("abcd")时, 字符串"abcd"就会根据编译时的是否定一_UNICODE来决定是char* 还是 w_char*。 同样,TCHAR 也是相同目的字符宏。 看看定义就明白了。简单起见,下面只介绍 ansi 的情况,unicode 可以类推。 ansi情况下,LPCTSTR 就是 const char*, 是常量字符串(不能修改的)。 而LPTSTR 就是 char*, 即普通字符串(非常量,可修改的)。 这两种都是基本类型, 而CString 是 C++类, 兼容这两种基本类型是最起码的任务了。 由于const char* 最简单(常量,不涉及内存变更,操作迅速), CString 直接定义了一个类型转换函数 operator LPCTSTR() {......}, 直接返回他所维护的字符串。 当你需要一个const char* 而传入了CString时, C++编译器自动调用 CString重载的操作符 LPCTSTR()来进行隐式的类型转换。 当需要CString , 而传入了 const char* 时(其实 char* 也可以),C++编译器则自动调用CString的构造函数来构造临时的 CString对象。 因此CString 和 LPCTSTR 基本可以通用。 但是 LPTSTR又不同了,他是 char*, 意味着你随时可能修改里面的数据,这就需要内存管理了(如字符串变长,原来的存贮空间就不够了,则需要重新调整分配内存)。 所以 不能随便的将 const char* 强制转换成 char* 使用。 楼主举的例子 LPSTR lpstr = (LPSTR)(LPCTSTR)string; 就是这种不安全的使用方法。 这个地方使用的是强制类型转换,你都强制转换了,C++编译器当然不会拒绝你,但同时他也认为你确实知道自己要做的是什么。因此是不会给出警告的。 强制的任意类型转换是C(++)的一项强大之处,但也是一大弊端。这一问题在 vc6 以后的版本(仅针对vc而言)中得到逐步的改进(你需要更明确的类型转换声明)。 其实在很多地方都可以看到类似 LPSTR lpstr = (LPSTR)(LPCTSTR)string; 地用法,这种情况一般是函数的约束定义不够完善的原因, 比如一个函数接受一个字符串参数的输入,里面对该字符串又没有任何的修改,那么该参数就应该定义成 const char*, 但是很多初学者弄不清const地用法,或者是懒, 总之就是随意写成了 char* 。 这样子传入CString时就需要强制的转换一下。 这种做法是不安全的,也是不被建议的用法,你必须完全明白、确认该字符串没有被修改。 CString 转换到 LPTSTR (char*), 预定的做法是调用CString的GetBuffer函数,使用完毕之后一般都要再调用ReleaseBuffer函数来确认修改 (某些情况下也有不调用ReleaseBuffer的,同样你需要非常明确为什么这么做时才能这样子处理,一般应用环境可以不考虑这种情况)。 同时需要注意的是, 在GetBuffer 和 ReleaseBuffer之间,CString分配了内存交由你来处理,因此不能再调用其他的CString函数。 CString 转LPCTSTR: CString cStr; const char *lpctStr=(LPCTSTR)cStr; LPCTSTR转CString: LPCTSTR lpctStr; CString cStr=lpctStr;

    03

    萌新不看会后悔的C++基本类型总结(二)

    上一篇大概地说了浮点数的精度问题和有效范围大小,还是有些东西没有说出来,我觉得还是应该说一说,我们常说的单精度有6 ~ 7位的有效范围,而双精度有15 ~ 16位的有效范围,这里所指的有效范围并不是该数值的大小,这是很多初学者的一个误区,并不是说这个单精度的float只能存储6 ~ 7位怎么大的数,如果是1234578这样的数则无法存储,这是错误的,想要理解这里的有效范围,还需要知道浮点数的存储方法,浮点数使用科学记数法来表示存储的,最大可以达到3.4E38,这是一个很大的数,达到了38位之多,显然不是上面所说的6 ~ 7位,这个有效范围可以认为是38位中的前6 ~ 7位,因为是使用科学记数法表示,而6 ~ 7 位又是根据尾数来得出来的,尾数又规定在1到2之间,也就是说最高位必须是1,而后面的数可以是000000(23个0),或者最大值为2,也就是1.1111111(23个1)需要注意这里的尾数使用二进制表示的,而2 ^23在6 ~ 7位之间,尾数可以保存6 ~ 7 位,然后后面38个0,这才是精度的根源。如果看不懂就去百度IEEE754,还是看不懂也没关系,初学者不需要了解怎么多,我只是普及一下。

    02

    Flutter ffi实践录

    最近琢磨着要给自己的 APP 接一个日志收集的 SDK 备用。考虑到一个问题,目前大多数开源的日志库,例如美团的 Logan 和腾讯的 XLog ,日志的存取都选择了使用 mmap 建立内存文件映射来提升读写效率和日志防丢。如果直接封装 plugin 调用 Android、iOS平台代码的话,就会出现 Flutter -> Platform -> Native 的情况。很显然,这种调用是没有必要的。那可以直接 Dart 调用 C/C++ 吗?答案是可以的。 实践了一下 Flutter 通过 ffi 包调用 native C/C++ 代码,ffi 代表 Foreign function interface (外部函数接口),入门实践 可以在 Flutter 的官方文档(https://flutter.cn/docs/development/platform-integration/c-interop)中找到。 我们使用 DynamicLibrary 来加载 C/C++ 编写的动态库。在 iOS 中,可以直接在源代码目录写,在Android 中则需要在 Gradle 中配置 CMakeList 。 接下来我们以接入 Logan 的 C 代码为例来实践一下,关于 Logan ,可以参考它的 github (https://github.com/Meituan-Dianping/Logan)。

    02

    C++实现对16进制字符串和字节数组的tea加密和解密算法

    TEA(Tiny Encryption Algorithm) 是一种简单高效的加密算法,以加密解密速度快,实现简单著称。算法真的很简单,TEA算法每一次可以操作64-bit(8-byte),采用128-bit(16-byte)作为key,算法采用迭代的形式,推荐的迭代轮数是64轮,最少32轮。 TEA 算法最初是由剑桥计算机实验室的 David Wheeler 和 Roger Needham 在 1994 年设计的。该算法使用 128 位的密钥为 64 位的信息块进行加密,它需要进行 64 轮迭代,尽管作者认为 32 轮已经足够了。该算法使用了一个神秘常数δ作为倍数,它来源于黄金比率,以保证每一轮加密都不相同。但δ的精确值似乎并不重要,这里 TEA 把它定义为 δ=「(√5 - 1)231」(也就是程序中的 0×9E3779B9)。 下面是维基百科中个关于该算法的C语言描述的代码片段,如下:

    02
    领券