once

#pragma once与 #ifndef的区别

房东的猫 提交于 2019-11-30 14:37:49
为了避免同一个文件被include多次可以用以下两种方法: 1 #ifndef方式 2 #pragma once方式 在能够支持这两种方式的编译器上,虽然二者并没有太大的区别,但是两者仍然还是有一些细微的区别。 方式一: #ifndef __SOMEFILE_H__ //文件名 #define __SOMEFILE_H__ ... ... // 声明语句 #endif 方式二: #pragma once ... ... // 声明语句 #ifndef 的方式依赖于宏名字不能冲突,这不光可以保证同一个文件不会被包含多次,也能保证内容完全相同的两个文件不会被不小心同时包含。当然,缺点就是如果不同头文件的宏名不小心"撞车",可能就会导致头文件明明存在,编译器却硬说找不到声明的状况。 #pragma once 则由编译器提供保证:同一个文件不会被包含多次。注意这里所说的"同一个文件"是指物理上的一个文件,而不是指内容相同的两个文件。带来的好处 是,你不必再费劲想个宏名了,当然也就不会出现宏名碰撞引发的奇怪问题。对应的缺点就是如果某个头文件有多份拷贝,本方法不能保证他们不被重复包含。当然,相比宏名碰撞引发的"找不到声明"的问题,重复包含更容易被发现并修正。 方式一由语言支持所以移植性好,方式二 可以避免名字冲突 来源: CSDN 作者: the_sea1 链接: https://blog

Kafka的个人总结一

笑着哭i 提交于 2019-11-29 19:24:16
Kafka个人解读前篇 Kafka的概述 消息队列的回顾 消息队列 消息队列的好处 消息队列的两种模式 Kafka的基础架构 Kafka架构深入 Kafka工作流程及文件存储机制 Kafka生产者 分区策略 数据可靠性保证 acks参数配置: 故障处理细节 Exactly Once语义(精确一次) Kafka消费者 消费模式 分区分配策略 offset维护 消费者组测试 Kafka的概述 kafka是一个分布式的消息队列,基于发布/订阅模式,主要用于大数据的实时处理领域. 消息队列的回顾 消息队列 传统的消息队列有两种处理方式: 同步处理: 任务提交给队列后,等待完成再进行其他操作 异步处理: 任务提交给队列后,不用等待完成,即可进行其他操作 消息队列的好处 1.解耦: 允许你独立的扩展或修改两边的处理过程,只要确保他们遵守同样的接口约束 2.可恢复性: 系统的一部分组件失效时,不会影响到整个系统。消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理 3.缓冲: 有助于控制和优化数据流经过系统的速度,解决生产消息和消费消息的处理速度不一致的情况 4.灵活性&峰值处理能力: 在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费

关于#pragma once和#ifndef

吃可爱长大的小学妹 提交于 2019-11-29 17:56:11
【1】#pragma once这个宏有什么作用? 为了避免同一个头文件被包含(include)多次,C/C++中有两种宏实现方式:一种是#ifndef方式;另一种是#pragma once方式。 在能够支持这两种方式的编译器上,二者并没有太大的区别。但两者仍然有一些细微的区别。 //方式一: #ifndef __SOMEFILE_H__ #define __SOMEFILE_H__ ... ... // 声明、定义语句 #endif //方式二: #pragma once ... ... // 声明、定义语句 【3】两者各有何特点? (1)#ifndef #ifndef的方式受C/C++语言标准支持。它不仅可以保证同一个文件不会被包含多次,也能保证内容完全相同的两个文件(或者代码片段)不会被不小心同时包含。 当然,缺点就是如果不同头文件中的宏名不小心“撞车”,可能就会导致你看到头文件明明存在,但编译器却硬说找不到声明的状况——这种情况有时非常让人郁闷。 由于编译器每次都需要打开头文件才能判定是否有重复定义,因此在编译大型项目时,ifndef会使得编译时间相对较长,因此一些编译器逐渐开始支持#pragma once的方式。 (2)#pragma once #pragma once 一般由编译器提供保证:同一个文件不会被包含多次。注意这里所说的“同一个文件”是指物理上的一个文件

jQuery:-$.Callbacks 实现原理

落爺英雄遲暮 提交于 2019-11-29 10:31:26
$.Callbacks 用于管理函数队列,通过 add 添加处理函数到队列中,通过 fire 去执行这些处理函数。 本节向大家介绍 $.Callbacks 的实现的原理,并简单实现一个自己的 callbacks。 $.Callbacks 用于管理函数队列,通过 add 添加处理函数到队列中,通过 fire 去执行这些处理函数。 本节向大家介绍$.Callbacks 的实现的原理,并简单实现一个自己的 callbacks。 概念解读 从事件函数了解 Callbacks,事件通常与函数配合使用,这样就可以通过触发事件来驱动函数的执行。 原则上,一个事件对应一个事件函数。在一个事件对应多个事件函数的情况下,后者会覆盖前者。 ele.onclick = function(){ console.log("code")}ele.onclick = function(){ console.log("code1")} 上边这个 Demo 中后面绑定的这个事件函数会覆盖前边的,事件触发时会打印"code1"。 事件驱动改造 如果想让触发事件时执行多个函数,是否可行呢? 当然可以,我们可以把需要执行的多个函数放在一个数组里,事件触发时循环执行这个数组里的函数。下面看一下伪代码: var callbacks = [function a(){}, function b(){}, function c(){

jQuery.Callbacks之源码解读

浪子不回头ぞ 提交于 2019-11-29 05:15:13
  在上一篇 jQuery.Callbacks之demo 主要说了Callbacks对象初始化常见的选项,这一篇主要分析下Callbacks对象的源代码,对给出两个较为繁琐的demo 1 // String to Object options format cache 2 var optionsCache = {}; 3 4 // Convert String-formatted options into Object-formatted ones and store in cache 5 /* 6 这个函数主要将传入的options字符串封装成对象 7 比如将传入的'once memory'封装成 8 optionsCache['once memory'] = { 9 once : true, 10 memory : true 11 } 12 这样方便下次同样的options复用和判断 13 */ 14 function createOptions( options ) { 15 var object = optionsCache[ options ] = {}; 16 jQuery.each( options.split( core_rspace ), function( _, flag ) { 17 object[ flag ] = true; 18 }); 19

phpexcel导入

坚强是说给别人听的谎言 提交于 2019-11-29 02:45:01
首先需要去官网下载PHPExcel,下载后只需要Classes目录下的文件即可。 我这个是一个单独的脚本,如需放入 框架只需要改一改文件引入路径即可 1、PHPExcel导入方法实现过程 (我已省略文件导入的过程) 1 <?php 2 3 //引入提前已经下载好的phpexcel 4 require_once './Classes/PHPExcel.php'; 5 require_once './Classes/PHPExcel/IOFactory.php'; 6 require_once './Classes/PHPExcel/Reader/Excel2007.php'; 7 $uploadfile = "./customer.xlsx"; 8 9 $objReader = PHPExcel_IOFactory::createReader('Excel2007');//use excel2007 for 2007 format 10 11 $objPHPExcel = $objReader->load($uploadfile); //$filename可以是上传的文件,或者是指定的文件 12 $sheet = $objPHPExcel->getSheet(0);       // 获取sheet 默认从0开始 13 $highestRow = $sheet-

pthread_once函数

早过忘川 提交于 2019-11-28 18:08:21
http://blog.csdn.net/lmh12506/article/details/8452659 pthread_once()函数详解 在多线程环境中,有些事仅需要执行一次。通常当初始化应用程序时,可以比较容易地将其放在main函数中。但当你写一个库时,就不能在main里面初始化了,你可以用静态初始化,但使用一次初始化(pthread_once)会比较容易些。 int pthread_once(pthread_once_t *once_control, void (*init_routine) (void)); 功能:本函数使用初值为PTHREAD_ONCE_INIT的once_control变量保证init_routine()函数在本进程执行序列中仅执行一次。 在多线程编程环境下,尽管pthread_once()调用会出现在多个线程中,init_routine()函数仅执行一次,究竟在哪个线程中执行是不定的,是由内核调度来决定。 Linux Threads使用互斥锁和条件变量保证由pthread_once()指定的函数执行且仅执行一次,而once_control表示是否执行过。如果once_control的初值不是PTHREAD_ONCE_INIT(Linux Threads定义为0),pthread_once() 的行为就会不正常。在LinuxThreads中,实际

#pragma once用法总结

痞子三分冷 提交于 2019-11-28 12:34:34
1.#pragmaonce这个宏有什么作用? 为了避免同一个头文件被包含(include)多次,C/C++中有两种宏实现方式:一种是#ifndef方式;另一种是#pragma once方式。 在能够支持这两种方式的编译器上,二者并没有太大的区别。但两者仍然有一些细微的区别。 2.两者的使用方式有何区别? 示例代码如下: 方式一: #ifndef __SOMEFILE_H__ #define __SOMEFILE_H__ ... ... // 声明、定义语句 #endif 方式二: #pragmaonce ... ... // 声明、定义语句 3.两者各有何特点? (1)#ifndef #ifndef的方式受C/C++语言标准支持。它不仅可以保证同一个文件不会被包含多次,也能保证内容完全相同的两个文件(或者代码片段)不会被不小心同时包含。 当然,缺点就是如果不同头文件中的宏名不小心“撞车”,可能就会导致你看到头文件明明存在,但编译器却硬说找不到声明的状况——这种情况有时非常让人郁闷。 由于编译器每次都需要打开头文件才能判定是否有重复定义,因此在编译大型项目时,ifndef会使得编译时间相对较长,因此一些编译器逐渐开始支持#pragma once的方式。 (2)#pragma once #pragma once 一般由编译器提供保证:同一个文件不会被包含多次。注意这里所说的“同一个文件

Kafka学习笔记 --- 如何实现Kafka消息的Exactly-Once

ぐ巨炮叔叔 提交于 2019-11-27 05:58:57
对于这个问题我们先来看一下一个笑话: 可以这样的实现 kafka设计思想: Kafka 0.11.0 版本之前并不能保证Exactly-once的语义,只能保证 at-least-once or at-most-once。实际运用中我们并不希望数据丢失,当网络出现问题的时候,我们都会选择重试,所以一般会保证at-least-once。 下面从三个点来讲解: idempotent Producer 设计 Transactional Messaging in Kafka 设计 Message format 改变 1.Idempotent Producer 我们要保证 Producer 发送数据幂等性,可以给每条数据分配一个UUID,Server 端存储所有的id。接收到数据的时候进行检测,如果重复就拒绝。这样的设计有一个问题就是算法复杂度的问题,我们需要匹配所有的消息的UUID。所以我们需要一个对空间资源要求低且查询速度快的设计思路。 我们可以给 Producer 分配一个PID,message分配一个自增的sequence number, sequence number如果是一个全局的id,分配到不同的partition,出现问题的时候回滚会比较麻烦,所以我们可以针对partition的message分配一个PID,message分配一个自增的sequence number

kafka学习笔记:知识点整理

心已入冬 提交于 2019-11-27 03:43:54
一 为什么需要消息系统 1.解耦 允许你独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束。 2.冗余 消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中,在把一个消息从队列中删除之前,需要你的处理系统明确的指出该消息已经被处理完毕,从而确保你的数据被安全的保存直到你使用完毕。 3.扩展性 因为消息队列解耦了你的处理过程,所以增大消息入队和处理的频率是很容易的,只要另外增加处理过程即可。 4.灵活性 & 峰值处理能力 在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力,而不会因为突发的超负荷的请求而完全崩溃。 5.可恢复性 系统的一部分组件失效时,不会影响到整个系统。消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理。 6.顺序保证 在大多使用场景下,数据处理的顺序都很重要。大部分消息队列本来就是排序的,并且能保证数据会按照特定的顺序来处理。(Kafka 保证一个 Partition 内的消息的有序性) 7.缓冲 有助于控制和优化数据流经过系统的速度,解决生产消息和消费消息的处理速度不一致的情况。 8