StrayWarrior – StrayWarrior's Blog

A bug Caused by Implicit Construction of std::string

Recently I met a bug when I was using google protobuf to serialize and deserialize messages.I have a code segment like this:

class MyMessage; // A message class generated by protobuf</code>
void process() {
    MyMessage msg;
    std::string msg_buffer = some_other_func(); // receive binary format "string"
    msg.ParseFromString(msg_buffer.data());
}

class MyMessage; // A message class generated by protobuf</code>

void process() {

MyMessage msg;

std::string msg_buffer = some_other_func(); // receive binary format "string"

msg.ParseFromString(msg_buffer.data());

}

In the code, there is a weird usage of std::string::data() and MyMessage::ParseFromString() API. It’s a mistake due

Be careful with return-value optimization of C++ compilers

Side Effect of Return-value Optimization This “bug” is caused by return-value optimization and affects both GCC and Microsoft C/C++ Compiler. Assume that we have codes like following:

#include <cstdio>
class Complex {
public:
    Complex() : Complex(0.0, 0.0) {}
    Complex(double a, double b) : a(a), b(b) {}
    Complex(const Complex & x) : a(x.a), b(x.b) {
        dummy = 1.f;
    }
    Complex operator * (const Complex & x) {
        return Complex(a * x.a, b * x.b);
    }

    double a, b;
    double dummy;
};

int main() {
    Complex z1(-1, 2);
    Complex z2(3, 5);
    Complex z3 = z1 * z2;
    Complex z4 = z3;
    printf("%f %f %f\n", z3.a, z3.b, z3.dummy);
    printf("%f %f %f\n", z4.a, z4.b, z4.dummy);
    return 0;
}

#include <cstdio>

class Complex {

public:

Complex() : Complex(0.0, 0.0) {}

Complex(double a, double b) : a(a), b(b) {}

Complex(const Complex & x) : a(x.a), b(x.b) {

dummy = 1.f;

}

Complex operator * (const Complex & x) {

return Complex(a * x.a, b * x.b);

}

double a, b;

double dummy;

};

int main() {

Complex z1(-1, 2);

Complex z2(3, 5);

Complex z3 = z1 * z2;

Complex z4 = z3;

printf("%f %f %f\n", z3.a, z3.b, z3.dummy);

printf("%f %f %f\n", z4.a, z4.b, z4.dummy);

return 0;

}

Compile the code with g++ main.cpp -O0 -g -std=c++11. Run the program and the output result is

“Module Not Found” when using VBA in Office

English Version Both Windows and Office support multiple languages and someone like me may use different language settings for them. However, this can cause some strange problems. My operation system is Windows 8.1 Pro and it is set to display

Compile and Install Basemap in Windows (Using MSVC)

Basemap is a Python package, which never releases new update after 2014. It’s easy to use in Linux or OS X but not easy to install on Windows. It doesn’t supply setup-package for Python 3.4 or 3.5 or newer version.

Link Error When Compiling and Installing Python Package in Windows

It’s usually easy to install a Python package in Windows with pip or other pre-built binaries. However, sometimes we must build the binary from source by ourselves, such as Basemap module, a part of matplotlib-toolkit.Then we may meet some error

使用批处理解决OS X系统修改文件后在Windows中无法访问的问题

由于NTFS文件系统权限管理的原因，OS X系统下新建或修改的文件一般在Windows中会因没有权限而无法访问，使用批处理可以较为快速地获得对某一文件或文件夹的控制权限。使用以下代码新建一个批处理文件，保存为takeown.bat

@echo off
setlocal enabledelayedexpansion

:start
set /p dir="Input the directory you want to take own: "
echo, "%dir%"
takeown /F %dir% /R
ICACLS %dir% /inheritance:e
ICACLS %dir% /reset /T

goto start

pause

@echo off

setlocal enabledelayedexpansion

:start

set /p dir="Input the directory you want to take own: "

echo, "%dir%"

takeown /F %dir% /R

ICACLS %dir% /inheritance:e

ICACLS %dir% /reset /T

goto start

pause

使用管理员身份运行后，将需要处理的文件路径粘贴入程序即可。 takeown和ICACLS均为Windows自带的权限管理命令。由于ICACLS并不强制夺取所有者权限，因此使用takeown命令完成夺取所有者权限的操作后，再使用ICACLS将上层目录的访问权限继承至目标目录。

Python 3使用Basemap导入ESRI信息的问题

Basemap使用自带的shapefile.py处理ESRI的shapefile，但是Basemap自带的shapefile版本过低(1.1.x)，其中存在一个bug导致使用Python 3.x版本时无法正确处理Windows-1252编码的二进制文件。典型错误：

File "D:\Python34\lib\site-packages\mpl_toolkits\basemap\shapefile.py", line 58, in u
    return v.decode('utf-8')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xed in position 2: invalid continuation byte

File "D:\Python34\lib\site-packages\mpl_toolkits\basemap\shapefile.py", line 58, in u

return v.decode('utf-8')

UnicodeDecodeError: 'utf-8' codec can't decode byte 0xed in position 2: invalid continuation byte

解决方法一：使用pip安装pyshp ( pip install pyshp )，或者手动下载最新版本的pyshp，并且将shapefile.py拷贝到Basemap的目录中( <python-install-prefix>\lib\site-packages\mpl_toolkits\basemap )。解决方法二：按照一的方式使用pip安装pyshp，并且修改Basemap的源代码，将__init__.py中shapefile模块的import语句略作修改，不再使用相对路径的导入方式并删除Basemap目录中的shapefile.py。修改之前为

from . import shapefile as shp
from .shapefile import Reader

1 2	from . import shapefile as shp from .shapefile import Reader

修改之后为

import shapefile as shp
from shapefile import Reader

1 2	import shapefile as shp from shapefile import Reader

使用方法二的一个好处是，使用pip更新pyshp后不需要再更新Basemap中的shapefile.py

解决Premiere文件预览音频流混乱/前后颠倒的问题

系统环境：Windows 8.1 Pro x64 软件版本：Premiere Pro CS6 (version 6.0.0) 今日使用Premiere发现一个奇怪的现象，某一个视频在预览窗口里预览以及放入序列之后都会有音频流混乱的现象，而该视频使用一般播放器均能正常播放，因此基本可以排除解码的问题。考虑到Premiere为了加快预览速度总是会在临时文件夹中缓存大量的源素材，猜想可能是某个缓存文件出现了问题。本机的Premiere缓存目录地址被设置为在X:\TEMP\Adobe\Media Cache Files\，在其中找到了出问题的视频文件名字开头的一些文件，全部删除之后再次预览视频，Premiere重建了缓存并且恢复正常。另附： Premiere缓存目录的设置方式为：Edit->Preferences->Media，选择Media Cache Files 和Media Cache Database即可更改缓存的存储位置以及索引位置。

Win8.1 音量自动变化

系统环境：Windows 8.1 Pro Update 1 自从用了Windows 8 系统之后，听音乐时会感到有明显的音量变化，一直不明白是怎么回事。声卡驱动已经正确安装，音量设置也保持不变。实际上这是Windows 8系统的一个特性，当系统检测到有通信活动时自动降低了系统音量，只是这个对通信活动的检测似乎有一点逻辑上的不足，导致了实际使用体验中的奇怪现象。要关掉这个特性，只要右击通知栏里的音量图标，选择”播放设备”，把自动降低音量的设置禁用即可。 —- English Version —- Actually, I use English language setting and I don’t know the exact Chinese translation of “Playback devices”. Here is the English version of this blog.

OS X系统读写NTFS文件系统

Mac OS X系统原生支持NTFS文件系统的读写，但是默认情况下只能使用“Read Only”模式，无法进行写操作。 OS X系统中，NTFS文件系统的磁盘是通过一个专用的mount_ntfs命令挂载的，该命令存在于/sbin/目录下。该命令可以使用-o rw参数打开NTFS磁盘的写权限，因此可以使用一个Wrapper来自动挂载NTFS磁盘并打开写入权限。打开终端，首先备份原来的mount_ntfs命令，新建并打开一个新的文件。

sudo mv /sbin/mount_ntfs /sbin/mount_ntfs.orig
sudo vim /sbin/mount_ntfs

1 2	sudo mv /sbin/mount_ntfs /sbin/mount_ntfs.orig sudo vim /sbin/mount_ntfs

然后在该文件中输入以下内容，保存并退出。

#!/bin/bash
/sbin/mount_ntfs.orig -o rw,nobrowse "$@"

1 2	#!/bin/bash /sbin/mount_ntfs.orig -o rw,nobrowse "$@"

然后给该文件赋予执行权限：

sudo chmod 755 mount_ntfs

1	sudo chmod 755 mount_ntfs

特别注意：命令中的“nobrowse”参数是必须的（如果省去了这个参数，OS X 10.10下实测不可行），否则NTFS磁盘挂载之后依然处于只读的模式。然而加上了“nobrowse”参数意味着磁盘不会自动出现在桌面上，也不会在Finder的侧边栏中出现。要访问这个磁盘，一个简便的方法是在终端中输入

open /Volumes

1	open /Volumes

这时会打开一个新的Finder窗口，列出了所有磁盘，找到所挂载的NTFS磁盘就可以像一般的磁盘那样使用了。 ———————- 2015-12-31更新： OS X系统默认不开启NTFS的写入权限，大概一是因为NTFS属于微软的商业机密，二是因为OS X的文件系统和NTFS差别较大，兼容性和稳定性都有问题。在OS X和Windows上同时使用同一个NTFS磁盘最容易遇到的问题大概就是文件的安全权限不稳定，比如该日志提到的问题。因此，我现在不太使用OS X写NTFS磁盘，对于一些经常需要在两个系统之间交换的数据使用一个FAT32格式的磁盘进行同步。

« Previous