VS2019 16.9版引入的linux项目远程输出路径bug

这是一个Visual Studio 2019(博主发现时的版本是Community 16.9.4)的bug,之前在16.8版本的时候是没有问题的,并且影响的是VS原生的远程linux项目,Make CMake项目不受影响,发现这个问题时着实郁闷了一段时间,总结一句话就是这个选项:

红框内的两个dir,在16.9以前可以同时作用于本地windows项目路径,及同步到远端linux的项目路径,而到了16.9的时候无论怎么修改这两个路径都只有windows侧的路径会响应变化,而sync到linux的路径还会使用默认的这个路径(应该是bug或其它原因,比如,写死了?!),查了半天也没找到解决方法,对简单项目的话只好修改项目设置,都是用默认dir,或者想办法退回16.8版本,其中搜索过程中发现了有人提到这个问题:https://developercommunity.visualstudio.com/t/VS-For-Linux:-Output-files-on-remote-mac/1357691,其中提到已经修改等待发布,在此记录这个影响挺大的问题,后续有更新会同步过来…

给我13年的Mac Book Air换了个nvme硬盘

13年买的港版13寸MBA A1466一直用到21年现在,好在当时略有远见,在标配4G内存的时代选择了定制的8G内存版本,才算勉强支撑了这么多年,但当时的硬盘还是选的128G版本,用到现在已经捉襟见肘,而且随着Mac OSX系统不断更新,感觉系统、软件使用起来速度越来越慢,而且还容易发生卡顿。

其实20年初时考虑过换个10代酷睿的新版Mac Book,但选择困难症纠结配置一直纠结到了年底,结果苹果发布了ARM版的Mac CPU M1,一时间好评不断,号称各种完爆Intel版的Mac,好在当时没入10代Mac Book,但参考当年入初代锐龙时的被坑经验,决定还是先观望下M1,毕竟这个变化不小,很多软件都需要对ARM版Mac系统做出适配。

不过此时我的老MBA已经基本硬盘满到快无法使用了,看了下某宝上256G、512G的MBA原装硬盘,售价比普通m.2硬盘基本上要贵一倍,而且都是拆机二手盘,也不知道会不会有问题。幸运的是,在万能的某宝上发现了这个神器:

Continue reading…

关于typedef指针类型后的非主流const行为(misc-misplaced-const)

这是一个之前没怎么注意过的细节问题,首先,参加如下代码:

struct MyStruct
{
    int type;
    char name[40];
};

typedef MyStruct * PMyStruct;

int main(int argc, char * argv[])
{
    MyStruct my1{0}, my2{0};
    const MyStruct * pmy1 = &my1;
    pmy1 = &my2;
    const PMyStruct pmy2 = &my1;
    pmy2 = &my2;
}

很简单的一段代码,但是全引出了一个不寻常的问题:此段代码编译时,第二个pmy2结构体指针会导致编译器(gcc)报错:“error: assignment of read-only variable ‘pmy2’”,此时如果配合有clang-tidy之类的代码扫描工具,会发现pmy2声明赋值位置提示:“Clang-Tidy: ‘pmy2’ declared with a const-qualified typedef; results in the type being ‘MyStruct *const’ instead of ‘const MyStruct *’”(clang-tidy的misc-misplaced-const)!

Continue reading…

解决UE4在中文环境下Compile错误提示乱码问题

UE4 4.26.0,VS 2019 Community,中文Win10 20H2组合在一起出现了今天要讲的问题,Compile出错时的log信息中中文乱码

试过切换VS语言为英文,UE4语言为中文,均不起作用,想起之前的这个问题:Android Studio的Build Output中文输出乱码(菱形问号)问题的解决方法,以为是不是UE4也有类似的设置,查找半天无果,最后发现其实新版Win10(最早哪个版本加上的我也不清楚)里面的区域语言设置中有个UTF-8的选项,虽然到目前用的20H2时仍声称为beta状态,但确实可以解决这个问题:

Continue reading…

Unity中使用ExcelDataReader实现Excel文件读取功能的坑

首先,这次在Unity中实现读取Excel文件(.xls .xlsx)功能是通过这个开源.Net库:https://github.com/ExcelDataReader/ExcelDataReader,感谢ExcelDataReader的作者和contributors!写这篇脱坑文时的ExcelDataReader版本是3.6.0,使用的Unity版本是2019.4.12f1。可以看到,这个库的Github上Release中提供的是NuGet包和源码,当然,自行源码编译出dll使用也是可以的,或者解包nupkg,但其实在Unity中也是可以使用NuGet管理第三方库的,在Unity中通过NuGet安装ExcelDataReader的完整过程可以参考这里:https://qiita.com/tani-shi/items/b155858f07c7350d3e2d,用到的Unity NuGet插件是这个https://github.com/GlitchEnzo/NuGetForUnity/releases,同样感谢做和贡献者们!一切准备就绪后,开始码代码:

        FileStream stream = File.Open("d:\\test.xlsx", FileMode.Open, FileAccess.Read, FileShare.Read);
        IExcelDataReader excelReader = ExcelReaderFactory.CreateOpenXmlReader(stream);
        Debug.Log(excelReader.IsClosed);

        DataSet result = excelReader.AsDataSet();
        int columnNum = result.Tables[0].Columns.Count;
        int rowNum = result.Tables[0].Rows.Count;

很简单的一段代码,测试下功能,在Unity Editor中运行一切正常,顺利读取出了test.xlsx中的信息,结果在Build了下Standalone执行程序后,再试,神奇的事情发生了,ExcelReaderFactory.CreateOpenXmlReader返回了null!

Continue reading…

关于clang的-Wweak-vtables警告

首先,这个weak-vtables的完整警告信息大概长这样:

warning: ‘XXX’ has no out-of-line virtual method definitions; its vtable
will be emitted in every translation unit [-Wweak-vtables]

而这个警告信息的来源一般是这样:

// XXX.h中
class BaseData
{
public:
    virtual ~BaseData() = default;
    int _base_data = 0;
};

class DerivedDataA final : public BaseData
{
public:
    int _derived_data_a = 0;
};

class DerivedDataB final : public BaseData
{
public:
    int _derived_data_b = 0;
};
Continue reading…

VS Linux项目编译g++: fatal error: cannot specify -o with -c, -S or -E with multiple files问题

使用Visual Studio (2019)进行Linux项目开发时遇到项目编译时提示如标题所写的:

g++: fatal error: cannot specify -o with -c, -S or -E with multiple files

仔细检查了项目代码,并没有发现问题,也尝试了移除最近改动过的代码、增加过的源码文件,均不能正常编译…(同时,也确认过新建的项目可以正常编译,证明开发环境本身还是没问题的)

Continue reading…

一种通过C++模板方式识别无用户数据C回调函数的方法

今天记录一个个人觉得有点意思的问题:C++代码中调用C API时,对于C回调函数的处理问题,如何识别出调用API时的信息?

这个问题,大部分API都是通过调用时提供传递用户数据的方式实现的,如libcurl中的CURLOPT_WRITEDATA,CURLOPT_READDATA ,通过curl_easy_setopt方式将任意用户数据指针传递给CURL句柄,并在执行上传下载时的回调函数内透传给调用方,这样在例如多线程并发上传下载时就可以很方便的识别出是哪个上传下载任务的回调了。但是,如果API及回调函数内没有提供传递用户数据的接口和回调参数的话,是不是就一定无法完成识别调用上下文信息的功能呢?比如下列的C函数API:

// C-Style callback function without user context
typedef void (*c_api_callback_no_context)(int count);
// C-Style callback function with user context
typedef void (*c_api_callback_context)(int count, void * user_context);

// C API function that will trigger the callback function
void c_api_start_counting_no_context(c_api_callback_no_context callback, int max);
void c_api_start_counting_context(c_api_callback_context callback, int max, void * user_context);

c_api_start_counting_context及配套的c_api_callback_context回调为可以透传用户数据的版本,而c_api_start_counting_no_context及c_api_callback_no_context则只提供了逻辑用回调参数count,没有可用于识别context的用户数据指针,那么如何在不碰C源码的前提下(闭源C库或不想做侵入式修改)做到和带用户数据回调一样的效果呢?目前想到的一种方法是通过C++模板生成不同地址的回调函数配合上下文信息映射来实现:

Continue reading…

Android Studio使用override自动生成方法形参名错误问题

使用Android Studio写Java,Kotlin代码时,经常会用到Ctrl+O来实现接口的方法,今天偶然发现AS自动添加的代码变成了这样:

val textWatcher = object: TextWatcher {

    override fun afterTextChanged(p0: Editable?) {
    }

    override fun beforeTextChanged(p0: CharSequence?, p1: Int, p2: Int, p3: Int) {
    }

    override fun onTextChanged(p0: CharSequence?, p1: Int, p2: Int, p3: Int) {
    }
}

虽然不影响功能,但是看起来就很费劲了,形参名不具有自解释性了,记得之前一直是没问题的,简单查了下发现,原来是之前更新了platform sdk后,没有选择同时安装source,在SDK Manager中把当前正在用的target api版本对应的source安装上,再次执行同样操作就可以了:

Continue reading…

Android Studio带C++项目提示More than one file was found with OS independent path问题修正

近日,在将一个旧Android Studio项目(带native c/c++)升级了新版本gradle 4.0.1后(Android Studio版本4.0.1),发现重新clean再构建时,提示:

More than one file was found with OS independent path ‘lib/armeabi-v7a/xxx.so’. If you are using jniLibs and CMake IMPORTED targets, see https://developer.android.com/studio/preview/features#automatic_packaging_of_prebuilt_dependencies_used_by_cmake

虽然一开始也是一脸茫然,但既然提示信息里都提供了连接了,那就看一下吧,顺带一提,给出的链接我写这篇博文的时候并不是最终信息位置,最终链接在这里:https://developer.android.com/studio/releases/gradle-plugin#cmake-imported-targets ,仔细阅读了一下,发现实际上是从gradle 4.0开始就对jni的预编译依赖引用方式做出了修改:

Continue reading…