分类 编程语言 下的文章

在看操作系统的时候看到的,好骚啊。直接暴力使用结构体的地址进行推断,其间还巧妙地利用了编译器的优化原理。据说该方法广泛用于Linux内核。

使用宏定义,代码分三行,定义三层操作:

注意:由于在#define操作中使用空格符号作为定义与替换内容的分隔符,所以在定义时不要加入空格。替换内容中似乎可以包含空格,因为该宏指令没有第三个参数

第一行:对外提供功能的函数名

#define member2parent(member_ptr,member_name) \
          to_struct(member_ptr, struct Parent, member_name)

其中这里的member_ptr是需要用来寻找结构体首部地址的成员变量地址,member_name不是变量,而是该成员变量在结构体中定义的名称。这里巧妙地利用了宏定义的替换原理,能够传递非变量的元素。在这里将结构体的定义加进去,能够减少使用时的代码量(避免重复输入结构体名)。

第二行:实际上进行由成员地址计算出结构体首地址操作的部分

#define to_struct(member_ptr,type,member_name) \
          ((type*)(char*)(member_ptr) - offset_of(member_name, type))

这里做的事情不但将结构体的首地址计算出来,还将格式转换为了type类型的指针。又调用了一个新的宏offset_of

第三行:获取成员变量相对结构体首部的偏移

#define offset_of(type,member) ((size_t)(&(((type*)0)->member)))

https://blog.csdn.net/changqing1990/article/details/85256717 这里获取偏移的方法就很巧妙了。所使用的思路是,假设一个结构体的实体从0地址开始,那么只要取得成员变量的地址,就相当于取得了该成员变量相对于结构体首部的偏移。但是仔细观察的话,会发现一个问题:((type*)0)->member这么一个操作,所做的事情是取得一个指针对应的成员变量的值,对C语言稍有了解的话,会知道其实NULL和0是一个东西。对空指针取成员变量值,不会出错吗?实际上外面还有一层操作:取地址符&。如同上文链接所述,实际上很容易理解,对一个地址取值再取地址,可以直接简化为地址的变换操作。由于编译器发现这个值在过程中并未使用,于是就进行了这种优化,实际上0地址的数据并未被真实访问过,而我们也按照预期取得了偏移量的数值。

本篇采用倒叙法,将废话放在片尾

原因:JavaScript在浏览器中顺序而异步地执行,导致某些需要有前后顺序要求的操作失效。比如先要通过XHR获得token,再用token访问新网页,异步执行会导致访问新网页的时候用的token可能还是undefined,即此时XHR请求还没完成。

解决方案:Promise对象

参考了廖雪峰老师的博客:https://www.liaoxuefeng.com/wiki/1022910821149312/1023024413276544

Promise的使用,在下将其归类为两种操作,创建和运行。一种创建Promise对象,另一种对Promise对象进行操作:进入下一状态或者得出结果。

Promise对象的创建:两种方法,一个是直接new,另一个利用Promise.resolve()或者Promise.reject()是创建有状态的Promise。后者两者分别对应一个Promise对象在执行成功和出错时的返回结果。从语法上允许直接向上述两个Promise方法传递一个Object,作为一个新Promise的返回结果,但是从使用上一般都是作为管道,即将结果从一个Promise传递到另一个Promise,不会用于一个全新Promise的生成。

将操作写入到Promise对象的函数中,然后就可以“运行”该Promise对象。Promise对象有一个then()方法,该方法接受一个函数作为参数,执行的工作是将传入Promise的函数体执行后,将(如果存在的)resolve的参数值作为then()方法内传入的函数的第一个参数,然后执行。结合代码解释如下:

function addBy1(a) {
  return new Promise((resolv, reject) => {
    resolv(a + 1);
  })
}

var p = addBy1(0);

首先在此创建了一个函数,命名为addBy1,接受一个参数,结合函数体可以大致猜出,该函数的功能是将传入a的值加1。

Promise对象有两种自用的返回值的方法:resolve()reject(),可以分别理解为带成功和失败状态的返回结果。在直接使用new关键字生成一个新的Promise对象时,这两个函数以参数的形式传入函数体,供不同条件下的返回使用。

实际上,可以直接将addBy1的return语句中的部分用于变量p的赋值。但是为何在这里分开呢?下面自有用处。(突然跑题)

显然,若是将addBy1函数就视作一个将传入数字加1的功能的话,应该得到相应的结果。如何得到呢?答案是使用Promise对象的运行功能。(对=>运算符略作解释:该符号用于简化匿名函数的表达,(参数列表)=>{函数体}

p.then(
  (a) => {
    console.log(a);
  }
);

然后就可以获得梦寐以求的1了。但是,显然功能不会就这么简单。Promise的妙处就在于这个then(),简要来说,它提供了在异步执行的JavaScript中执行一系列的同步操作的能力。正是有了这个功能,使得需要依赖前一个操作完成后再执行下一个操作的逻辑流程能够按照正确的时序图执行。直观地感受一下:

var p = addBy1(0);
p.then(addBy1).then(addBy1).then(addBy1).then(addBy1).then(
  (a) => {
    console.log(a);
  }
);

在执行了这一段代码后,会发现输出的结果是5:从创建变量开始,一共执行了5次addBy1函数,而初始值为0。

但是若是再使用上面的一段代码输出p中的返回值,会发现其仍然是1。理解为then()方法不会改变原始Promise对象的状态吧。

then()函数接收的参数若是返回Promise对象,就可以在后面继续接.then(),从而可以定义无限长的.then()序列。而这些then()方法又必须串行执行。这就达到了一开始的目的:串行地执行JavaScript代码。

这么一说,操作都是n+1,怎么看得出来到底是不是1+1,2+1一直到4+1呢?虽然从逻辑上似乎也找不出其他的可行执行方法,但是可以通过在第一段代码的resolv()函数之前加一句console.log(a);来验证,显然输出结果会是01234。因而拓展一下,将简单的1+1操作换为需要较长时间的,比如XHR请求一类的操作的话,就可以方便地实现时序的可控化了。

最后,上文不是有提到为什么要将addBy1操作单独提出作为一个函数吗。原因有二,其一就是上文已经用到了的,为了重复进行Promise的操作,其二就是,这是一个极好的函数式编程的入门范例。函数式编程的思想之一就是使用尽可能少的参数。比如传统的1+1会表示为var result = plus(1, 1),而函数式编程会这么想:

class Number {
  constructor(x) {this.number = x;}
  addBy1() {
    return this.number + 1;
  }
}

即在正常使用时,会这么用:

var a = new Number(1);
var result = a.addBy1();

从而得到2。在使用过程中,除开对象的声明之外,没有用到一个有参数的方法。


最近处于各种原因,开始了前端编程。。然后上手就是微信(诶,好像不对)丁丁(也不对)钉钉(啊对,就是这个了)小程序。不出所料,工作就是生物代码粘合器(2077警告)。这里即兴赋歌一段:

我有个appId 我有个appSecret (双手做插合状,并摆出夸张的面部表情) access_token

我有个access_token 我有个authCode (双手做插合状,并摆出夸张的面部表情) userId

(大雾)

虽然对于很多干这行的人来说,可能认为在下这是对工作本身的不尊重,但是这确实反映了在下在看文档的时候,看到为了获取一个userId而不得不从appIdappSecret开始一路以token换token最终拿到所需要的数据的过程中,哭笑不得的感觉。我当时不选择做前端,大概就有一部分原因在这。虽然知道出于安全角度考虑,这是较为稳妥的一种方式,但是如果深陷其中,并以其为日常的工作,显然就太有些小看程序员的能力了。(咳咳,但是砖总得要有人去搬啊)

一个单文件的C语言源程序也是一个C项目。


在之前用C语言编程的时候,往往都是随意地新建一个.c.cpp文件,把代码往里面一写,gcc命令一敲,然后就在命令行里运行自己的程序,开始快乐苦B的debug之旅了。直到最近学习编译原理,了解了一些程序解析的原理之后,才开始把这个曾经思考过,却又未曾放在心上的问题拿出来解决。

在看了这篇文章之后,有了一定的新认识,决定也自己写点东西来加深一下理解。(看起来是位高中物竞,大学计科的dalao啊)

首先提出一个问题:C语言中的.c.h读者有见到过吗?在使用时,有注意到自己是在何种情况下使用两者的吗?

显然,一个接触过C语言的人,是一定见到过这两者的。因为,即使是一个编程界最基础的程序Hello World,在使用C语言编写时也必须同时用到这两种类型的文件。

回忆一下,步骤如下:

  1. 建立helloworld.c
  2. 使用任意文本编辑器(如记事本)打开,在内部输入如下内容:

    #include <stdio.h>
    int main()
    {
    printf("Hello world!\n");
    return 0;
    }
  3. Ctrl+S,关闭;
  4. 使用编译器编译(如GCC):gcc -o helloworld.exe helloworld.c
  5. 运行:helloworld.exe,或者./helloworld.exe

于是我们就见到了helloworld.cstdio.h两个文件。至少到这里,一般人都会有的想法:编写自己的程序用.c后缀,使用系统预定义的函数用.h后缀。为什么不能反过来呢?理论上可以。不过由于这已经形成了约定俗成的习惯,随意地违反规则,可能造成意料之外的结果。

接下来,按照大众称呼,将.c文件称呼为源文件source file.h文件称呼为头文件header file。何为源文件呢?程序是由代码编译生成的,代码是程序之源,因而代码又叫做程序的源代码;源代码中的文件自然而然地便可以称为源文件了。那何为头文件呢?浅显易懂的理解方法是,.h文件作为include预处理指令的操作对象,一般都是随预处理指令放在文件头部位置的。(C语言中代码功能与书写位置是有关的;作用域为定义位置开始向后,所以需要的功能最好在一开始就引用。

在上文所提到的文章中,作者表示,由于include预编译指令的实际作用是将目标文件直接复制到当前文件的同一位置,所以文件到底叫啥,有什么后缀名都无关紧要,因为文件名在include预编译指令中必须明确指定。一开始我还在这踩了个坑,以为头文件中函数的实现只能在名称对应的源文件中查找,直到我试了一下。。。发现实际上至少在Visual Studio中,只要是在解决方案资源管理器中添加了的文件,都算是源文件,即使名字不对应,后缀奇怪,也不会影响函数实现的搜索,平时常见的头文件和源文件命名对应的目的只是为了方便开发人员寻找函数的实现代码。换个说法,就是MSVC会在编译时把添加到项目资源管理器的文件都扫描一遍,生成对应的目标文件(符号表)。即使后缀改成exe,只要没从解决方案中排除,照样编译给你看

寻找的两种不同的库文件(Windows下的.dll,Linux下的.so;Windows下的.lib,Linux下的.a),依次对应的是动态编译和静态编译两种各有优劣的编译方法。在此不做展开,关于这个内容的博客在搜索引擎上还是很好找的。由于了解尚不够深入,目前还不清楚源文件的有无是否影响动态编译——反正静态是肯定不影响的:编译器往往提供了其C标准实现(有多种,如GCC的glibc,BSD的BSD libc,Windows平台下的MSVC Runtime等等)的静态编译库,而不提供其实现源码。(从某种程度上来讲实现了对源码的保护)

但是在最简单的Hello World例子中,我们是无法找到stdio.c这个文件的。因为往往编译器都提供的是静态库,如上一段所说,原因为何我也不清楚。。

由于Windows下的MinGW采用的C标准实现是MSVC的,因而在编译程序时,所需要的函数实现都是从MSVC对应的静态库里提取的。这个静态库一般是libmsvcrt.a,使用strings工具可以看出其中存在printf字符串,可以间接地表明其中含有printf的实现。顺便了解到Windows下与grep对应的命令是findstr

由include的原理所牵扯到的是,“所include的文件一定要是头文件,而不能是源文件吗?”这样一个问题。这个想法很好:把源文件复制到待引用文件的头部的话,相当于是只是把函数的定义换了个位置写,然后用编译器命令复制过去,在理论上是行得通的。然而若是亲自实践的话,会发现编译器报出符号多重定义的错误,即实际上并不可行。

这个思考方式忽视了一个问题:打开任何一个现有项目的的头文件查看,里面都是只有函数的原型声明的,没有任何实现代码。上面也有提到,编译器会自动到所有指定为源文件的文件中寻找函数的实现,来试图在链接过程使这个函数具体化。那么如何实现寻找呢?在对源码直接进行搜索的基础上进行改进,把对源文件的词法和语法分析的中间结果记录下来,也就是可能会听说过的.obj文件,里面就有编译器可以识别格式的文件信息,包括定义的变量、函数等。再把函数名字相同的函数寻找出来(由于C语言是面向过程型的语言,没有重载特性,故没有函数签名一说),作为函数声明的实现。也就是说,可以理解为,编译期先将源文件解析为一一对应的一系列“符号集合”,然后在“符号集合”的并集里寻找匹配的函数实现。那么,上面的问题就好解决了:如果include了一个源文件的话,声明引用的文件中会出现被引用文件的代码,这些函数被定义了一遍,放进该文件的符号表里;同时由于被引用的文件被视为了源文件,该文件自身也会有一个对应的符号表,把文件里的函数定义一遍。由于这个“并集”并不会、且出于严谨的目的也不能自动合并命名重复的函数实现,因而在链接阶段,链接器将不知道该采用哪个实现,直接报出多重定义的错误。

如果我不把被include的文件添加至项目呢?

这个更好回答,你告诉编译器这个不是源代码文件,编译器就会直接在词法分析预处理的阶段报错。需要的文件“不存在”(因为你告诉编译器不是这个文件,而它又找不到其他满足条件的文件),词法分析无法进行。

而函数的声明和定义就不一样了,声明是针对编译的过程而言的,为的是向语法分析器确认该函数的用法。至于该函数到底有啥用,语法分析器不管,因为它不需要关心自己所处理的句子的内在含义的问题,只要句子“读得通”(符合文法)就行。所以,函数的声明是不需要写入到符号表的,相同的声明可以在不同的源文件中同时出现。这个时候,头文件的作用就显现出来了:能够规范简洁而统一地对需要引用的同一(批)函数进行声明。这个功能还可以扩展至所有声明性的工作,包括宏定义#define、C++的类定义、结构体以及枚举类型的定义,等等。但凡涉及到实体化的工作,即使是变量声明,也不能放在头文件中,因为只要有实体的对象都会被添加至符号表,造成重定义的错误。

总结如下: .c文件里写代码(放实体),.h文件里放声明(说空话)。因为口说无凭,立字为据嘛

https://blog.csdn.net/weixin_30685047/article/details/94999645

客户端传来UTF-8的表单,服务器的asp用的是GBK,因而服务器端会按照GBK编码读取表单,因而就会乱码 实际上这个时候在服务器里拿到的表单已经是被GBK处理过了的,而要显示出正确的文字,需要把GBK编解码过的文字重新编码,然后用对应的UTF-8再次解码,所以实际上对二进制做的是UTF-8解码从而得到GB2312环境下的正确显示。

原因是,在GB2312里面,汉字两字节一编码,UTF-8三字节一编码,GBK会替换一些不支持的编码为?,ASCII值为63,相当于修改了UTF-8的二进制数据,偶数个汉字运气好,奇数个汉字显然结尾的数据会被破坏,嗯,这就是原因。

解决思路显然是想办法不要让服务器先用GBK进行表单解码了,因而方法有二:

  1. 想办法拿到二进制的表单,然后直接使用正确的代码页解码;
  2. 看能不能把asp换到UTF-8的环境下吧。

在一开始接触Mathematica的时候,对它的理解可能更加接近解释型语言,比如Python一类的,输入和输出是确定对应的。 Mathematica里的赋值运算符有两种,=:=。前者就是传统的赋值,后者叫做“延时赋值”,即在使用到被赋值变量时才计算其对应的值。一开始并没有仔细看文档,只是发现两者的区别是在句尾不加分号的时候,前者会输出计算值,后者不会,以为区别在这里。。但是这是错误用法 而后在进行高级运用,涉及到了带有循环编程的时候,程序就开始报错了,说递归超过最大深度。在简单的尝试后,发现将:=替换成=问题就解决了,这才意识到自己之前对这两个操作符的理解可能有误。

简要总结: =赋值符用于立即赋值,适合最为广泛的面向过程编程; :=用于延时赋值,对于函数的定义需要使用这个符号(显然传入了自变量值才能计算出结果来嘛),可能更多用于函数式编程,一般的数值计算不要轻易用这个符号; ;加在句尾,可用于在一行做多条语句的分隔符,同时在句尾添加了分号的语句将不会产生输出,与Matlab的分号抑制输出功能相同。