发表于 | 更新于 | 分类于

kubectl apply -f https://istio.io/operator.yaml

kubectl apply -f - <<EOF
apiVersion: install.istio.io/v1alpha2
kind: IstioControlPlane
metadata:
namespace: istio-operator
name: example-istiocontrolplane
spec:
profile: demo
EOF

kubectl get svc -n istio-system

发表于 | 更新于 | 分类于

Linkerd
Istio
Consul
Apache ServiceComb Mersher:
SOFAMesh

生产级微服务特性

高可用

水平扩展

多中心

多环境
虚拟机
K8S

Consul

docker run -h node1 –name consul -d -p 8400 -p 8500:8500 consul -server -bootstrap-expect 1 -advertise 127.0.0.1
docker run -h node1 –name consul -d -p 8400 -p 8500:0.0.0.0:8500 consul agent -server -ui -bootstrap-expect 1 -advertise 127.0.0.1

docker run -h node1 –name consul -d -p 8400 -p 8500:8500 -e CONSUL_BIND_INTERFACE=eth0 consul agent -dev

发表于 | 更新于 | 分类于

Oralce in 语句中当in(1,2,3…) 条件数量大于1000将会报错。

如果我们把in拆分成多个in就可以解决这个问题。
修改前

1
2
3
4
5
6
7
select *
from tbl_temp
where
id in
<foreach item="item" index="index" collection="ids" open="(" separator="," close=")">
	#{item}
</foreach>
1
2
3
4
select *
from tbl_temp
where
id in (1,2,3)

修改后

1
2
3
4
5
6
select *
from tbl_temp
where
<foreach item="item" index="index" collection="ids" open="(" separator="or" close=")">
	id in #{item}
</foreach>
1
2
3
4
select *
from tbl_temp
where
(id in 1 or id in 2 or id in 3)

发表于 | 更新于 | 分类于

转载自:http://wwywnp.blog.163.com/blog/static/16372208720112109039559/

这通常是由于以数据成员方式在DLL导出类中使用了模板类造成的。比如：

#include

#include
using namespace std;

class __declspec( dllexport ) Test
{
public:
std::vector m_objCon;
};

int main()
{

return 0;
}

这会导致这个警告:
warning C4251: “Test::m_objCon”: class“std::vector<_Ty>”需要有 dll 接口由 class“Test”的客户端使用
1> with
1> [
1> _Ty=int
1> ]
这个问题主要要描述的是不同的地方的vector的实现可能不一样所造成的问题。所以我们应该将其导出。有很多方法可以解决这个问题的。

第一种： 无视它或者#pragma warnind( disable: 4251 )
第二种：将该数据改为指针方式：
class __declspec( dllexport ) Test
{
public:
std::vector* m_objCon;
};
然后在构造函数和析构函数中分别初始化和释放它。
第三种：
将该模板类及其依赖类导出。

#include

#include
using namespace std;

class declspec( dllexport ) Test
{
public:
template class declspec( dllexport ) std::allocator;
template class __declspec( dllexport ) std::vector<int, std::allocator >;
public:

std::vector m_objCon;
};

int main()
{

return 0;
}
这种方法要注意的是必须要把要导出模板类的模板数据成员一并导出。有点类似于显式实例化。比如说你要导出boost::shared_ptr就还必须将其依赖的shared_count一并导出。导出map还需要导出对应pair等等。很麻烦啦~所以我们还是选择第四种吧。

第四种：Impl。

#include

#include
using namespace std;

// 这些放到.h中
class Test_imp;
class __declspec( dllexport ) Test
{
// 构造函数中初始化 析构中释放m_pImp;
void test();
public:
Test_imp* m_pImp;
};

// 这个类放到cpp中去
class Test_imp
{
public:
void test(){}
std::vector m_objCon;
};

// 放到cpp中
void Test::test()
{
m_pImp->test();
}

int main()
{

return 0;
}

个人推荐第二种和第四种，反对第一种。毕竟掩耳盗铃不是好习惯~~
第四种除了可以解决上面的问题之外还可以隐藏代码，当然多了一个桥接的过程。

程序中消除warning有两种方法：消极一点不去理他，反正不是error:-)；积极一点，则想办法去掉。去掉又用两种方法：一种使用#pragma warning(disable: xxxx)，眼不见，心不烦；另外就是找出解决问题的办法了。
今天做dll库时，在struct中用到了stl：
class CLASS_TEST
{
…
private:
std::vector<MY_STRUCT> m_structs;
}
但是编译时，vs2005给出了warning C4251: ‘CLASS_TEST::m_structs’ : class ‘std::vector<_Ty>’ needs to have dll-interface to be used by clients of class ‘CLASS_TEST’的警告信息。费了很大的劲才解决掉，记录下来。

在头文件中，定义宏

#ifdef MYDLL_EXPORTS

#define MYDLL_API __declspec(dllexport)

#else

#define MYDLL_API __declspec(dllimport)

#endif

现在，在变量m_structs前，添加：
template class MYDLL_API std::allocator;
template class MYDLL_API std::vector<myStruct, std::allocator >;
这样，即可以了。

另一篇:

1:情况一
如果类的定义里面仅含有 编译器内置的类型变量, int, float 等等. 或者成员函数仅使用了这些变量作为参数, 那么很简单.
直接
class __declspec(dllexport) YourClass

{
}
就行了.

2:情况二
如果类内部使用了别的类, 那么别的类最好也导出, 不然, 首先编译的时候会出现编译警告:
warning C4251: needs to have dll-interface
意思是,你使用另外的一些类型/接口, 但是这些类型或接口没有导出. 当你的client使用这些类型/接口的时候, 会出错!
class __declspec(dllexport) YourClass

{
YourAnatherClass m_data; // 这里会 出现 warning 4251. 如果YourAnatherClass 没有导出的话.
}
解决办法就是: 在YourAnatherClass定义的地方加上
class __declspec(dllexport) YourAnatherClass
{
}
如上, 当你的YourAnatherClass没有导出的时候, dll的使用方会出现链接错误

3:情况三
当类的内部使用了STL模板的时候, 也会出现C4251警告, 情况会有所不同
class __declspec(dllexport) YourClass

{
vector m_data; // 这里会 出现 warning 4251. 因为vector类型没有被导出
}
上面的使用模板(无论是stl模板,还是自定义模板)的代码,编译dll时会出现C4251警告, 但是dll的使用方, 却不会出现链接错误!!!
这个因为, dll的使用方那里也有一套模板的定义, 当他们使用那个vector的时候, 虽没有导出, 但是用户自己也有一套STL模板(或者是自定义的模板),用户会利用自己的模板实例化这个dll中没有导出的东西!

所以, 对于因为使用STL(或模板)出现的c4251警告, 关闭之即可

#pragma warning(push)

#pragma warning(disable:4251)
//your declarations that cause 4251

#pragma warning(pop)

若想不使用通过关闭警告的方式关闭警告, 那么就这样
1)对于用户自定义的模板
template class DLLImportExportMacro SomeTemplate;
SomeTemplate y;
2)对于STL的模板
template class DLLImportExportMacro std::allocator
template class DLLImportExportMacro std::vector<int,
std::allocator >;
vector m_data;

发表于 | 更新于 | 分类于

DLL生成DEF

使用方法，将pexports.exe放到X:\Microsoft Visual Studio X.0\VC\bin目录下，在命令行里输入pexports x.dll > x.def

DEF生成LIB

然后在输入lib /machine:ix86 /def:x.def
即在当前目录生成x.lib

发表于 | 更新于 | 分类于
  1. 到网上下载一个Dependency Walker(简称depends)工具，该工具主要是用来检查某个文件的运行需要使用哪些链接库。下载后直接双击Depends.exe打开，然后点文件-〉打开，选择你要检查的文件，然后会出现下面的画面：

可以看到左上角是该控件所需要的所有的动态链接库，右边是每个链接库的具体信息，最下面一栏显示状态，之前因为少装了4个链接库，下面就会显示缺少xxxx，中间的那部分第一栏模块名称那里会用红色表示缺少的模块。

  1. 到网上找到那几个链接库，然后把它们放到%systemroot%\WINDOWS\system32下面。

  2. 在开始-〉运行里键入regsvr32 xxxxx.ocx，该控件就成功注册了！

发表于 | 更新于 | 分类于

如果在编译MFC程序的时候出现下列及类似的错误：

1>uafxcwd.lib(afxmem.obj) : error LNK2005: “void cdecl operator new(unsigned int)” (??2@YAPAXI@Z) 已经在 LIBCMTD.lib(new.obj) 中定义
1>uafxcwd.lib(afxmem.obj) : error LNK2005: “void cdecl operator delete(void )” (??3@YAXPAX@Z) 已经在 LIBCMTD.lib(dbgdel.obj) 中定义
1>uafxcwd.lib(afxmem.obj) : error LNK2005: “void cdecl operator new“ (??_U@YAPAXI@Z) 已经在 libcpmtd.lib(newaop.obj) 中定义
1>uafxcwd.lib(afxmem.obj) : error LNK2005: “void cdecl operator delete[](void )” (??_V@YAXPAX@Z) 已经在 LIBCMTD.lib(delete2.obj) 中定义

解决方法如下：
项目属性页-》链接器-》输入

做如下改动，注意顺序

附加依赖库：uafxcwd.lib;LIBCMTD.lib;

忽略特定默认库：LIBCMTD.lib;uafxcwd.lib

转自:http://blog.csdn.net/dotphoenix/article/details/13511863

发表于 | 更新于 | 分类于

什么是静态代码分析

静态代码分析是指无需运行被测代码，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性，找出代码隐藏的错误和缺陷，如参数不匹配，有歧义的嵌套语句，错误的递归，非法计算，可能出现的空指针引用等等。

在软件开发过程中，静态代码分析往往先于动态测试之前进行，同时也可以作为制定动态测试用例的参考。统计证明，在整个软件开发生命周期中，30% 至 70% 的代码逻辑设计和编码缺陷是可以通过静态代码分析来发现和修复的。
但是，由于静态代码分析往往要求大量的时间消耗和相关知识的积累，因此对于软件开发团队来说，使用静态代码分析工具自动化执行代码检查和分析，能够极大地提高软件可靠性并节省软件开发和测试成本。

静态代码分析工具的优势

  1. 帮助程序开发人员自动执行静态代码分析，快速定位代码隐藏错误和缺陷。
  2. 帮助代码设计人员更专注于分析和解决代码设计缺陷。

  3. 显著减少在代码逐行检查上花费的时间，提高软件可靠性并节省软件开发和测试成本。

    Java 静态分析工具

    Checkstyle

    Checkstyle 是 SourceForge 的开源项目，通过检查对代码编码格式，命名约定，Javadoc，类设计等方面进行代码规范和风格的检查，从而有效约束开发人员更好地遵循代码编写规范。
Checkstyle 提供了支持大多数常见 IDE 的插件，文本主要使用 Eclipse 中的 Checkstyle 插件。

    C/C++静态分析工具

    Cppcheck

    Cppcheck是一个C/C++代码的静态分析工具。它和其他C/C++编译器不同的是它不检测语法的错误，它通常检测编译器不检测的错误。

发表于 | 更新于 | 分类于

错误处理很重要，但如果它搞乱了代码逻辑，就是错误的做法。

使用异常而非返回码

这类问题在于，调用者必须在调用之后即刻检查错误。不幸的是，这个步骤很容易被遗忘。所以遇到错误时，最好抛出一个异常。调用代码很整洁，其逻辑不会被错误处理搞乱。

发表于 | 更新于 | 分类于

1 Big-endian

按照最高位字节(包含最高位，即MSB，的字节)至最低位字节(包含最低位，即LSB，的字节)的顺序，存放在连续的地址中。

采用这种机制的处理器有IBM3700系列、PDP-10、Mortolora微处理器系列和绝大多数的RISC处理器。
例如：双字节数0x1234以big-endian的方式存在起始地址0x00000000中
数据<–地址
| 0x12 |<– 0x00000000

| 0x34 |<– 0x00000001
2 Little-endian

按照最低位字节(包含LSB的字节)至最高位字节(包含MSB的字节)的顺序，存放在连续的地址中。

采用这种机制的处理器有PDP-11、VAX、Intel系列微处理器和一些网络通信设备。
例如：双字节数0x1234以little-endian的方式存在起始地址0x00000000中
数据<–地址
| 0x34 |<– 0x00000000

| 0x12 |<– 0x00000001
3 Middle-endian

除了big-endian和little-endian之外的多字节存储顺序就是middle-endian。

比如以4个字节为例：象以3-4-1-2或者2-1-4-3这样的顺序存储的就是middle-endian。

这种存储顺序偶尔会在一些小型机体系中的十进制数的压缩格式中出现。

为什么要注意字节序的问题呢？你可能这么问。当然，如果你写的程序只在单机环境下面运行，并且不和别人的程序打交道，那么你完全可以忽略字节序的存在。但是，如果你的程序要跟别人的程序产生交互呢？在这里我想说说两种语言。C/C++语言编写的程序里数据存储顺序是跟编译平台所在的CPU相关的，而JAVA编写的程序则唯一采用big endian方式来存储数据。试想，如果你用C/C++语言在x86平台下编写的程序跟别人的JAVA程序互通时会产生什么结果？就拿上面的0x12345678来说，你的程序传递给别人的一个数据，将指向0x12345678的指针传给了JAVA程序，由于JAVA采取big endian方式存储数据，很自然的它会将你的数据翻译为0x78563412。什么？竟然变成另外一个数字了？是的，就是这种后果。因此，在你的C程序传给JAVA程序之前有必要进行字节序的转换工作。


无独有偶，所有网络协议也都是采用big endian的方式来传输数据的。所以有时我们也会把big endian方式称之为网络字节序。当两台采用不同字节序的主机通信时，在发送数据之前都必须经过字节序的转换成为网络字节序后再进行传输。

4 比特序

CPU存储一个字节的数据时其字节内的8个比特之间的顺序是否也有big endian和little endian之分？或者说是否有比特序的不同？ 实际上，这个比特序是同样存在的。下面以数字0xB4（10110100）用图加以说明。

Big Endian

msb lsb
———————————————->
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 1 | 1 | 0 | 1 | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Little Endian

lsb msb
———————————————->
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 | 0 | 1 | 1 | 0 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

实际上，由于CPU存储数据操作的最小单位是一个字节，其内部的比特序是什么样对我们的程序来说是一个黑盒子。也就是说，你给我一个指向0xB4这个数的指针，对于big endian方式的CPU来说，它是从左往右依次读取这个数的8个比特；而对于little endian方式的CPU来说，则正好相反，是从右往左依次读取这个数的8个比特。而我们的程序通过这个指针访问后得到的数就是0xB4，字节内部的比特序对于程序来说是不可见的，其实这点对于单机上的字节序来说也是一样的。 


那可能有人又会问，如果是网络传输呢？会不会出问题？是不是也要通过什么函数转换一下比特序？嗯，这个问题提得很好。假设little endian方式的CPU要传给big endian方式CPU一个字节的话，其本身在传输之前会在本地就读出这个8比特的数，然后再按照网络字节序的顺序来传输这8个比特，这样的话到了接收端不会出现任何问题。而假如要传输一个32比特的数的话，由于这个数在littel endian方存储时占了4个字节，而网络传输是以字节为单位进行的，little endian方的CPU读出第一个字节后发送，实际上这个字节是原数的LSB，到了接收方反倒成了MSB从而发生混乱。