分类 编程语言 下的文章

好了，又到了快乐的C++快速上手时间 之前在这里讲过实际中.cpp和.h的一种用法，然后这次涉及到了模板函数template。模板函数与传统函数不同，并无法直接使用，需要先传入所给定的参数类型，C++才能根据类型推断出该函数体实际所需要执行的指令。所以，应该将模板函数的函数体在头文件中实现。不然的话，比如说在Visual Studio中，若是还是傻傻地（像我一样）在头文件定义模板函数，然后跑到源文件中定义函数体的话，就会报出LNK2019，也就是常见的找不到函数引用的错误。

拓展阅读 -> https://stackoverflow.com/questions/495021/why-can-templates-only-be-implemented-in-the-header-file

最近在做视频帧处理（前景提取），显然这个要求视频帧按照顺序输出。帧的处理顺序没有关系，因为没有使用推测功能。（要是开了帧预测的话，显然就只能顺序处理了，由于帧之间有依赖关系，所以最多只能做单帧内部的处理优化）

所以本次的思路基本是，寻找一个可以乱序执行，但是一定要能够按照任务的加入顺序获取执行结果的模型。看了一下，直接用threading.Thread，没有看到简洁地获取执行结果的方法；而用multithreading.pool.Pool，使用map函数的callback参数注册回调，在之前的尝试中没有成功过。然后在StackOverflow上看到有人推荐concurrent.futures.ThreadPoolExecutor。在Python里看到future这个词往往都是有惊喜的，这次也不例外。大致流程如下：

使用pool = ThreadPoolExecutor(maxThreadCount)注册一个全新的线程池 -> 使用pool.submit(function, args...)提交一个任务，并获得类似于线程句柄一类的返回对象，可以用来控制线程，包括在运行之前取消该任务、获取运行状态（是否完成）以及获取完成的返回值等。这几乎满足了之前提出的需求：只需要再自建一个满足先进先出的队列，就可以实现按帧的顺序读取了。

框架大致如下：

import multiprocessing as mp
from threading import Thread
from concurrent.futures import ProcessPoolExecutor

processPool = ProcessPoolExecutor(max(mp.cpu_count(), 1))
procList = []
maxQueueLength = 10

def produce(...):
    # 用来执行具体工作，比如处理单帧视频
    ...

def producer_func(...):
    # 用来控制多线程生成和执行情况的“主线程”，调用produce函数
    <condition-loop>
        ....
        # 确保队列不会过长，节省资源，时间换空间
        while len(procList) > maxQueueLength:
            continue
        procList.append(processPool.submit(produce, (...)))

if __name__ == '__main__':
    # 不阻塞主线程，将后续的任务还要放在这里执行，比如图像的显示
    Thread(target=producer_func, ...).start()

    while True:
        if len(procList) <= 0:
            continue
        elif not procList[0].done():
            continue
        res = procList[0].result()
        ...
        if <condition>:
            break

需求：一条语句从(0,1,2,3,4,5,6,7,8,9,10)中取出(7,5,3)。

分析：可以使用Python的切片功能。

完整用法：iteratableObj[startIndex:endIndex:step]

其中iteratableObj可以是list, tuple，其他的我就不清楚了。（没去查官方文档= =）

然后startIndex为包含性的从0开始的元素编号，表示切片的开始位置；endIndex为非包含性的从0开始的元素编号，表示切片的结束位置；step表示步进，即每次前进多少个元素，默认为1。

这些数字如果是负数的话，也是有特定含义的，会被Python解释器认为是反向编址的序号，即常说的倒数第几个。相应地，step处的负号会让整个列表翻转。然后这里就涉及了一个很有意思的问题：同时进行切片和翻转，到底谁先谁后？也就是说，startIndex和endIndex到底应该是填顺序的还是反序的？

经过实践，发现顺序如下：

  1. 先检查step的符号，如果为负，翻转列表（也可能是将读取顺序标记为反序）
  2. 按照startIndex和step开始选取元素，以endIndex为界限（不包含）。这里的两个index都还是顺序的！

于是上文的题目解答如下：

arr = (0,1,2,3,4,5,6,7,8,9,10)
print(arr[7:2:-2]) # or print(arr[-4:-9:-2])

千万要记住这里的第二个地址还是不包含的，所以一定要多顺着方向将地址+1！

在初步接触Java Servlet之后，会发现一个HTTPServlet有这么两个附属对象：ServletConfig和ServletContext，两者长得很像，又有着不少相同的方法(getAttribute(), getInitParameter(), getServletName()/getServletNames())，在网上搜了一下，发现有讲述两者之间的区别的博客，但是我是在理解之后才看懂的。。

在此简述一下使用Tomcat运行Web服务的三大主要层次，我依次将其命名为Server, Application和Servlet。其中Server指的是Tomcat本身，可以理解为一台服务器上一般只会跑一个Tomcat，所有需要借助Tomcat实现的Web服务都会依赖于这一个Tomcat实例。其次就是Application了，这就是上面所说，需要借助Tomcat实现的服务。一个Web服务就是一个Web项目，内部可以有复杂的Java逻辑代码，可以包括与数据库交互，等等。一个Servlet指的是提供单一Web功能的程序单位。

Application举例说明的话就是登陆系统，从登陆到连接后台，查看数据，修改用户信息、密码等，算是一个完整的后台管理系统服务，仅靠单一的URL是很难（但是是可以）实现整个功能的，起码作为一个便于维护和扩展的项目来说，都会需要多个URL来实现不同的功能，因为这样至少光靠URL地址就能有效地组织整合不同的功能了。这是Application。而Servlet实现的是原子操作，比如说后台管理系统中的登陆，或是获取用户信息，或是修改密码这种单一而清晰的任务。

然后就可以说明了：ServletConfig是Servlet层面的，每个Servlet都有自己独立的ServletConfig；而ServletContext是Application层面的，同一服务/项目下的所有Servlet可以通过ServletContext共享数据。那为什么ServletContext不是Server层面呢？ServletContext中可以存放应用的重要数据，出于安全考虑，一是防止数据窃取，二是防止篡改，不论是无意还是有意。

再仔细看看ServletContext的方法的话，会发现有一个方法名为getServletNames()，返回的是一个Enumeration，也就是说具有多个Servlet名称。相对地，ServletConfig的方法名为getServletName()，返回一个String。这下就更加清晰了，显然一个Servlet只应该有一个名字，那么ServletContext肯定就是Servlet层面之上的了。

此外有一个小坑：声明Application级别的初始变量是在web-app建立context-param子节点，使用ServletContext的getInitParameter()方法获取；Servlet级别的初始变量则需要在web-app节点下先新建servlet子节点，再在servlet子节点下新建init-param节点定义，使用ServletConfig的getInitParameter()方法获取。其中两个param的定义结构相同，使用param-name子节点定义变量名，param-value子节点定义变量值，而显然这个值只能定义为String类型。

例如：

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd" id="WebApp_ID" version="4.0">

  ...

  <context-param>
    <param-name>contextInitParam</param-name>
    <param-value>someValue</param-value>
  </context-param>

  <servlet>
    <servlet-name>demoServlet</servlet-name>
    <servlet-class>tk.esperz.demoServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
    <init-param>
      <param-name>servletInitParam</param-name>
      <param-value>otherServletsCannotSeeMe</param-value>
    </init-param>
  </servlet>
  <servlet-mapping>
     <servlet-name>demoServlet</servlet-name>
     <url-pattern>/demo.do</url-pattern>
  </servlet-mapping>
</web-app>

其中为该Web项目定义了一个名为contextInitParam的上下文初始化变量，值为someValue，所有该项目中的Servlet都可以通过ServletContext.getInitParameter("contextInitParam")获取；为名为demoServlet的Servlet定义了一个名为servletInitParam的初始化变量，值为otherServletsCannotSeeMe，仅在该Servlet内可以通过ServletConfig.getInitParameter("servletInitParam")获取。凡是用错了方法的都会返回null哦

按照常规操作，在定义完变量之后应该对其进行初始化，然后再使用。于是就有了这么一段代码：

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // TODO Auto-generated method stub
        PrintWriter out = response.getWriter();
        response.setCharacterEncoding("UTF-8");
        response.setContentType("text/html; charset=UTF-8");
        out.write("喵喵喵？");
    }

然而在编译并由Tomcat发布后，访问获得的结果却是????。 你是????，我也是？？？？啊？？比特流编码和传输给浏览器的MIME信息都已经声明了，为啥还是不对？

直到看了这个 https://blog.csdn.net/tlms_/article/details/78749980

才发现

要先设置好response的属性，然后再获得由这些属性生成的PrintWriter。很是奇怪的逻辑。。 将getWriter()操作放到几个set操作之后，问题顺利解决。

  1. 1
  2. ...
  3. 4
  4. 5
  5. 6
  6. 7
  7. 8
  8. 9
  9. 10
  10. 11