itarticl.cc-IT技术类文章记录&分享

01mysql获取库的所有表名和字段名

mysql获取某个数据库的所有表名

select TABLE_NAME from information_schema.tables where TABLE_SCHEMA="your database name"

mysql获取某个表的所有字段名

select COLUMN_NAME from information_schema.COLUMNS where table_name = 'your_table_name';

02mysql的latin1字符集支持所有字符集

Latin1是ISO-8859-1的别名，如果数据库内表的字符集是latin1，那么默认情况下中文也可被支持！

· latin1覆盖了所有单字节的值，任何其他的码流都可以被看做latin1

· 把一个gbk编码的串写入latin1的表，不会有任何问题，保存的是原封不动的字节流

· 从表中读取已写入的串也不会有任何问题，且读出的字节流就和当初写入的完全一致

03报错svn: E200014: Checksum mismatch for

今天svn update 时报错：

svn: E200014: Checksum mismatch for 'bala/bala/bala目录+文件': expected: ede36171fde5dfa11504b90690fb5ce6

actual: 9e9a1fa06031710331951a1078f1aaf0

意思就是本地文件的标识与远程不一致，解决方法入下：

先在错误文件所在目录执行：

svn update --set-depth empty

注意：此方法会删除此目录中的所有文件，避免万一，请主动备份、备份、备份，然后。。。。文件没了，

再执行：

svn update --set-depth infinity

ok，解决问题

04mysql SUM聚合运算的返回值为MYSQL_TYPE_NEWDECIMAL

mysql SUM聚合运算的返回值为MYSQL_TYPE_NEWDECIMAL，如果是C++处理返回值时，可能对类型会有影响，使用SUM函数时需要使用 CAST函数对结果类型作下转义，转义为Int或者doule，然后C++就可以处理了

05一个低级Illegal instruction错误的定位--忽略编译期警告就得加倍偿还

INFO_LOG("id[%s] ...", packet->strid, ...);

当packet->strid为string类型，不是char*类型时

会报编译警告

ProcessHeartbeat.cpp:408: warning: cannot pass objects of non-POD type âstruct std::stringâ through â...â; call will abort at runtime

但不会报error，但会在运行时崩溃，Program terminated with signal 4,Illegal instruction.

NAT技术的原理并不复杂，如图1所示，三个带有内部地址的数据报文到达NAT设备，其中报文1和报文2来自同一个内部地址但有不同的源端口号，报文1和报文3来自不同的内部地址但具有相同的源端口号。通过NAT映射，三个数据报的源IP地址都被转换到同一个外部地址，但每个数据报都被赋予了不同的源端口号，因而仍保留了报文之间的区别。当各报文的回应报文到达时，NAT设备仍能够根据回应报文的目的IP地址和目的端口号来区别该报文应转发到的内部主机。

from clipboard

NAT设备通过建立五元组（源地址、源端口号、协议类型、目的地址、目的端口号）表项为依据进行地址分配和报文过滤。即，对于来自相同源地址和源端口号的报文，若其目的地址和目的端口号不同，通过映射后，相同的源地址和源端口号将被转换为不同的外部地址和端口号，并且NAT设备只允许这些目的地址对应的外部网络的主机才可以通过该转换后的地址和端口来访问这些内部网络的主机。

07那些永不消逝的进程(nohup的原理)

一个忽略了 SIGHUP 信号的进程（nohup xxx），在它所属的会话的控制进程被终结之后依旧可以继续运行；但此时由于原有控制终端已经不再存在了，它便不再有终端输入或输出的能力；此外，原有的会话依旧存在，只不过会话先导(session leader，由于此时的会话中已没有任何终端，因此不能称之为控制进程了)变为该进程。

08如何加快C++代码的编译速度

C++代码一直以其运行时的高性能高调面对世人，但是说起编译速度，却只有低调的份了。比如我现在工作的源代码，哪怕使用Incredibuild调动近百台机子，一个完整的build也需要四个小时，恐怖！！！虽然平时开发一般不需要在本地做完整的build，但编译几个相关的工程就够你等上好一段时间的了（老外管这个叫monkey around，相当形象）。想想若干年在一台单核2.8GHZ上工作时的场景 - 面前放本书，一点build按钮，就低头读一会书~~~往事不堪回首。

09C++中复制构造函数可以调取其他对象中的私有变量

封装是编译期的概念，是针对类型而非对象的，在类的成员函数中可以访问同类型实例对象的私有成员变量．

10为什么多线程读写 shared_ptr 要加锁？

（shared_ptr）的引用计数本身是安全且无锁的，但对象的读写则不是，因为 shared_ptr 有两个数据成员，读写操作不能原子化。根据文档（http://www.boost.org/doc/libs/release/libs/smart_ptr/shared_ptr.htm#ThreadSafety）， shared_ptr 的线程安全级别和内建类型、标准库容器、std::string 一样，即：

• 一个 shared_ptr 对象实体可被多个线程同时读取（文档例1）；

• 两个 shared_ptr 对象实体可以被两个线程同时写入（例2），“析构”算写操作；

• 如果要从多个线程读写同一个 shared_ptr 对象，那么需要加锁（例3~5）。

请注意，以上是 shared_ptr 对象本身的线程安全级别，不是它管理的对象的线程安全级别。

后文（p.18）则介绍如何高效地加锁解锁。本文则具体分析一下为什么“因为 shared_ptr 有两个数据成员，读写操作不能原子化”使得多线程读写同一个 shared_ptr 对象需要加锁。这个在我看来显而易见的结论似乎也有人抱有疑问，那将导致灾难性的后果，值得我写这篇文章。本文以 boost::shared_ptr 为例，与 std::shared_ptr 可能略有区别。

shared_ptr 的数据结构

shared_ptr 是引用计数型（reference counting）智能指针，几乎所有的实现都采用在堆（heap）上放个计数值（count）的办法（除此之外理论上还有用循环链表的办法，不过没有实例）。具体来说，shared_ptr<Foo> 包含两个成员，一个是指向 Foo 的指针 ptr，另一个是 ref_count 指针（其类型不一定是原始指针，有可能是 class 类型，但不影响这里的讨论），指向堆上的 ref_count 对象。ref_count 对象有多个成员，具体的数据结构如图 1 所示，其中 deleter 和 allocator 是可选的。