关于恋爱模式的一点思考

最近和妹子闹了一点小矛盾,不过已经problem solved.

大概是因为,我聊到了妹子很不喜欢的话题,导致妹子情绪变得负面而我还没意识到…

我是感觉…就像写代码一样,代码没有bug(初始时)是不太现实的,关键是要debug?

所以人际关系,更具体的说是和妹子相处….也不可能没有矛盾吧…

尤其是两个人成长环境如果相差得比较多的情况下…接触的时间越长,暴露的矛盾应该就越多…

一个好的coder会惧怕代码中有bug吗?当然不会…

所以矛盾似乎也没什么可怕的…

不过一个熟练的coder大概可能写出的bug会越来越少吧。

所以我觉得,找到一种合适的机制,去解决矛盾是非常必要的….

这种机制不是说解决矛盾的方法本身,而是更通用的为解决矛盾提供的环境?

 

另外,其实有矛盾也不是什么坏事….如果矛盾是客观存在的,大概越早暴露越好…

越早暴露应该越好解决吧orz

所以大概….下次遇到,至少是这一类的问题,我们应该能解决的更好了吧…

 

用coding的思维考虑恋爱关系想想其实也没有那么奇怪啊…

我一直觉得,每一对情侣之间都有他们自己相处的模式吧….

所以其实使用这一类方法(不过不代表全部套用…就好像觉得某种语言的某个特性好不代表以后就只使用这种语言一样2333)

对于我们来说应该是种挺高效的模式吧。。。

其实这也可以归结成“见什么人说什么话”?

就想起那次和室友们打《优势物种》…解释规则的时候,“资源的实例”的说法软院的学生都会明白而又不会显得冗杂..

就好像某次和妹子去光谷浪,看到很多家烤串店纠结去哪一家的时候….“遍历一下”也比能想到的其他说法更加准确高效….

 

 

 

安装win10后导致grub 引导缺失的解决办法

我之前是单系统manjaro,装了win10以后,grub menu直接消失不见…

ubuntu 的live cd进去,用神器boot-repair也没作用…

最后的解决办法是:

 

1. 用随便一个什么linux的live cd,进入live模式

2. 使用某种方法(fdisk?gparted?自己记得?)确认linux安装在哪个分区(如果有安装了多个,应该以最后一个为准)我的linux安装在了sda5

3. 挂载linux分区:

4.挂载其他必要的文件夹

5:chroot进你的系统

6.重装并更新grub引导

 

完美解决!

archlinux安装记

实在不忍心x1c吃灰。。。

打算装个arch玩。。。

第一次失败了,原因是忘记配置引导相关…

第二次就成功了…

教程满大街都是就不再写了….

似乎装好以后,和manjaro区别不大?

有空来更新下配置吧。。。

(越来越觉得折腾linux的时间还不如用来陪妹子…

所以不一定什么时候会更了2333

qt 5.x初探 (3)

update3:

终于知道了正确的学习姿势…

用百度把要用的东西大概描述出来,然后总能找到一个是你要的。。。

然后再去搜关键词。。。

嗯。。百度还是很有用的啊2333

qt5.8_doc_Line Edits Example

所以现在要把之前写成dialog的几个改回Line edit

 

update2:

老师说要把输入框中的东西随时选中复制出来check…

QLabel默认好像不具有这种属性啊?

稍微查了下。。。

查到了一个叫setTextInteractionFlags的属性

以及连根拔出了。。

qt5.8 QGraphicsTextItem Class

 

找到了解决办法。。。

记得要

 

update1:

扶起。。。QFile读中文路径文件毫无问题。。。

换成了cpp的 ifstream就一直报错。。。

由于我还改了其他部分。。。所以。。。

查了好久才发现是ifstream的锅。。。。

 

 

 

把des放了进去。。。

本来加密和解密想就用一个函数用参数调节的。。。

不过看了半天也没太懂。。。这种connnet怎么写。。。

不过对connect的理解更深了一些。。。

信号和槽果然是qt的精髓。。。看起来还算不那么无聊。。。

放一些关于信号和槽的资料好了。。。

信号与槽机制

ibm_qt的信号与槽机制

qt的信号槽

 

然后目前的进度是。。。

des放了进去。。。加密基本没啥问题。。。

但是有个小问题。。。

对于加密过程。。。我是用了一个全局的QString QTextSt来传递信息。。。

对于打开文件。。。过程是file->QString

加密后得到密文文件。。过程是QString -> file

但是解密过程。。。。完全反过来了啊。。。?

在思考怎么写在一起能够不违和。。。。。

 

 

 

archlinux bug ncurses: 文件系统中已存在 /usr/share/terminfo/f/fbterm

今天滚的时候遇到这个问题…

提示:ncurses: 文件系统中已存在 /usr/share/terminfo/f/fbterm

查了下,由于这bug比较新….没找到什么有用的信息…

于是尝试了一下比较一般的解决冲突的办法:

 

 

问题解决。。。

 

C++中头文件(.h)和源文件(.cpp)都应该写些什么(转载)

感觉其实。。。更像是一种规范。。。?而不是一种具体要求吧。。。

转自

 

 

头文件(.h):

写类的声明(包括类里面的成员和方法的声明)、函数原型、#define常数等,但一般来说不写出具体的实现。

在写头文件时需要注意,在开头和结尾处必须按照如下样式加上预编译语句(如下):

 

#ifndef CIRCLE_H
#define CIRCLE_H

//你的代码写在这里

#endif

 

这样做是为了防止重复编译,不这样做就有可能出错。

至于CIRCLE_H这个名字实际上是无所谓的,你叫什么都行,只要符合规范都行。原则上来说,非常建议把它写成这种形式,因为比较容易和头文件的名字对应。

源文件(.cpp):

源文件主要写实现头文件中已经声明的那些函数的具体代码。需要注意的是,开头必须#include一下实现的头文件,以及要用到的头文件。那么当你需要用到自己写的头文件中的类时,只需要#include进来就行了。

下面举个最简单的例子来描述一下,咱就求个圆面积。

第1步,建立一个空工程(以在VS2003环境下为例)。

第2步,在头文件的文件夹里新建一个名为Circle.h的头文件,它的内容如下:

 

#ifndef CIRCLE_H
#define CIRCLE_H

class Circle
{
private:
    double r;//半径
public:
    Circle();//构造函数
    Circle(double R);//构造函数
    double Area();//求面积函数
};

#endif

注意到开头结尾的预编译语句。在头文件里,并不写出函数的具体实现。

第3步,要给出Circle类的具体实现,因此,在源文件夹里新建一个Circle.cpp的文件,它的内容如下:

 

#include “Circle.h”

Circle::Circle()
{
    this->r=5.0;
}

Circle::Circle(double R)
{
    this->r=R;
}

double Circle:: Area()
{
    return 3.14*r*r;
}

需要注意的是:开头处包含了Circle.h,事实上,只要此cpp文件用到的文件,都要包含进来!这个文件的名字其实不一定要叫Circle.cpp,但非常建议cpp文件与头文件相对应。

最后,我们建一个main.cpp来测试我们写的Circle类,它的内容如下:

 

#include <iostream>
#include “Circle.h”
using namespace std;

int main()
{
    Circle c(3);
    cout<<“Area=”<<c.Area()<<endl;
    return 1;
}

注意到开头时有#include “Circle.h”的声明,证明我们使用到了我们刚才写的Circle类。

至此,我们工程的结构为:

运行一下,输出结果为:

说明我们写的Circle类确实可以用了。

1..h叫做头文件,它是不能被编译的。“#include”叫做编译预处理指令,可以简单理解成,在1.cpp中的#include”1.h”指令把1.h中的代码在编译前添加到了1.cpp的头部。每个.cpp文件会被编译,生成一个.obj文件,然后所有的.obj文件链接起来你的可执行程序就算生成了。

发现了没有,你要在.h文件中严格区分声明语句和定义语句。好的习惯是,头文件中应只处理常量、变量、函数以及类等等等等的声明,变量的定义和函数的实现等等等等都应该在源文件.cpp中进行。

至于.h和.cpp具有同样的主文件名的情况呢,对编译器来讲是没有什么意义的,编译器不会去匹配二者的主文件名,相反它很傻,只认#include等语句。但是这样写是一种约定俗成的编程风格,一个类的名字作为其头文件和源文件的主文件名比如Class1.h和Class1.cpp,这个类的声明在Class1.h中,实现在Class1.cpp中,我们人类看起来比较整齐,读起来方便,也很有利于模块化和源代码的重用。

为什么这个风格会约定俗成?有一句著名的话,叫“程序是为程序员写的”。

2.h文件和cpp文件也就是说,在h文件中声明Declare,而在cpp文件中定义Define。 “声明”向计算机介绍名字,它说,“这个名字是什么意思”。而“定义”为这个名字分配存储空间。无论涉及到变量时还是函数时含义都一样。无论在哪种情况下,编译器都在“定义”处分配存储空间。对于变量,编译器确定这个变量占多少存储单元,并在内存中产生存放它们的空间。对于函数,编译器产生代码,并为之分配存储空间。函数的存储空间中有一个由使用不带参数表或带地址操作符的函数名产生的指针。定义也可以是声明。如果该编译器还没有看到过名字A,程序员定义int A,则编译器马上为这个名字分配存储地址。声明常常使用于extern关键字。如果我们只是声明变量而不是定义它,则要求使用extern。对于函数声明, extern是可选的,不带函数体的函数名连同参数表或返回值,自动地作为一个声明。

另篇:

在C++编程过程中,随着项目的越来越大,代码也会越来越多,并且难以管理和分析。于是,在C++中就要分出了头(.h)文件和实现(.cpp)文件,并且也有了Package的概念。

对于以C起步,C#作为“母语”的我刚开始跟着导师学习C++对这方面还是感到很模糊。虽然我可以以C的知识面对C++的语法规范,用C#的思想领悟C++中类的使用。但是C#中定义和实现是都在一个文件中(其实都是在类里面),而使用C的时候也只是编程的刚刚起步,所写的程序也只要一个文件就够了。因此对于C++的Package理解以及.h文件和.cpp文件的总是心存纠结。

幸好导师有详细的PPT让我了解,一次对于Package的认识就明白多了。简单讲,一个Package就是由同名的.h和.cpp文件组成。当然可以少其中任意一个文件:只有.h文件的Package可以是接口或模板(template)的定义;只有.cpp文件的Package可以是一个程序的入口。

当然更具体详细的讲解,欢迎下载导师的教学PPT-Package来了解更多。

不过我在这里想讲的还是关于.h文件和.cpp文件

知道Package只是相对比较宏观的理解:我们在项目中以Package为编辑对象来扩展和修正我们的程序。编写代码时具体到应该把什么放到.h文件,又该什么放在.cpp文件中,我又迷惑了。

虽然Google给了我很多的链接,但是大部分的解释都太笼统了:申明写在.h文件,定义实现写在.cpp文件。这个解释没有差错,但是真正下手起来,又会发现不知道该把代码往哪里打。

于是我又把这个问题抛给了导师,他很耐心地给我详详细细地表述了如何在C++中进行代码分离。很可惜,第一次我听下了,但是没有听太懂,而且本来对C++就了解不深,所以也没有深刻的印象。

经过几个项目的试炼和体验之后,我又拿出这个问题问导师,他又一次耐心地给我讲解了一遍(我发誓他绝对不是忘记了我曾经问过同样的问题),这次我把它记录了下来。

为了不再忘记,我将它们总结在这里。

概览

非模板类型(none-template) 模板类型(template)
头文件(.h)
  • 全局变量申明(带extern限定符)
  • 全局函数的申明
  • inline限定符的全局函数的定义
  • 类的定义
  • 类函数成员和数据成员的申明(在类内部)
  • 类定义内的函数定义(相当于inline)
  • static const限定符的数据成员在类内部的初始化
  • inline限定符的类定义外的函数定义
  • 模板类的定义
  • 模板类成员的申明和定义(定义可以放在类内或者类外,类外不需要写inline)
实现文件(.cpp)
  • 全局变量的定义(及初始化)
  • 全局函数的定义
(无)
  • 类函数成员的定义
  • 类带static限定符的数据成员的初始化

*申明:declaration
*定义:definition

头文件

头文件的所有内容,都必须包含在

#ifndef {Filename}
#define {Filename}//{Content of head file}

#endif

这样才能保证头文件被多个其他文件引用(include)时,内部的数据不会被多次定义而造成错误

inline限定符

在头文件中,可以对函数用inline限定符来告知编译器,这段函数非常的简单,可以直接嵌入到调用定义之处。

当然inline的函数并不一定会被编译器作为inline来实现,如果函数过于复杂,编译器也会拒绝inline。

因此简单说来,代码最好短到只有3-5行的才作为inline。有循环,分支,递归的函数都不要用做inline。

对于在类定义内定义实现的函数,编译器自动当做有inline请求(也是不一定inline的)。因此在下边,我把带有inline限定符的函数成员和写在类定义体内的函数成员统称为“要inline的函数成员”

非模板类型

全局类型

就像前面笼统的话讲的:申明写在.h文件。

对于函数来讲,没有实现体的函数,就相当于是申明;而对于数据类型(包括基本类型和自定义类型)来说,其申明就需要用extern来修饰。

然后在.cpp文件里定义、实现或初始化这些全局函数和全局变量。

不过导师一直反复强调:不许使用全局函数和全局变量。用了之后造成的后果,目前就是交上去的作业项目会扣分。当然不能用自有不能用的理由以及解决方案,不过不在目前的讨论范围内。

自定义类型

对于自定义类型,包括类(class)和结构体(struct),它们的定义都是放在.h文件中。其成员的申明和定义就比较复杂了,不过看上边的表格,还是比较清晰的。

函数成员

函数成员无论是否带有static限定符,其申明都放在.h文件的类定义内部。

对于要inline的函数成员其定义放在.h文件;其他函数的实现都放在.cpp文件中。

数据成员

数据成员的申明与定义都是放在.h文件的类定义内部。对于数据类型,关键问题是其初始化要放在什么地方进行。

对于只含有static限定符的数据成员,它的初始化要放在.cpp文件中。因为它是所有类对象共有的,因此必须对它做合适的初始化。

对于只含有const限定符的数据成员,它的初始化只能在构造函数的初始化列表中完成。因为它是一经初始化就不能重新赋值,因此它也必须进行合适的初始化。

对于既含有static限定符,又含有const限定符的数据成员,它的初始化和定义同时进行。它也是必须进行合适的初始化

对于既没有static限定符,又没有const限定符的数据成员,它的值只针对本对象可以随意修改,因此我们并不在意它的初始化什么时候进行。

模板类型

C++中,模板是一把开发利器,它与C#,Java的泛型很相似,却又不尽相同。以前,我一直只觉得像泛型,模板这种东西我可能一辈子也不可能需要使用到。但是在导师的强制逼迫使用下,我才真正体会到模板的强大,也真正知道要如何去使用模板,更进一步是如何去设计模板。不过这不是三言两语可以讲完的,就不多说了。

对于模板,最重要的一点,就是在定义它的时候,编译器并不会对它进行编译,因为它没有一个实体可用。

只有模板被具体化(specialization)之后(用在特定的类型上),编译器才会根据具体的类型对模板进行编译。

所以才定义模板的时候,会发现编译器基本不会报错(我当时还很开心的:我写代码尽然会没有错误,一气呵成),也做不出智能提示。但是当它被具体用在一个类上之后,错误就会大片大片的出现,却往往无法准确定位。

因此设计模板就有设计模板的一套思路和方式,但是这跟本文的主题也有偏。

因为模板的这种特殊性,它并没有自己的准确定义,因此我们不能把它放在.cpp文件中,而要把他们全部放在.h文件中进行书写。这也是为了在模板具体化的时候,能够让编译器可以找到模板的所有定义在哪里,以便真正的定义方法。

至于模板类函数成员的定义放在哪里,导师的意见是放在类定义之外,因为这样当你看类的时候,一目了然地知道有那些方法和数据;我在用Visual Studio的时候查看到其标准库的实现,都是放在类内部的。

可能是我习惯了C#的风格,我比较喜欢把它们都写在类内部,也因为在开发过程中,所使用的编辑器都有一个强大的功能:代码折叠。

当然还有其他原因就是写在类外部,对于每一个函数成员的实现都需要把模板类型作为限定符写一遍,把类名限定符也要写一遍。

g++ 编译多个源文件(转载)

参考资料

一. 常用编译命令选项
假设源程序文件名为test.c。

1. 无选项编译链接
用法:#gcc test.c
作用:将test.c预处理、汇编、编译并链接形成可执行文件。这里未指定输出文件,默认输出为a.out。

2. 选项 -o
用法:#gcc test.c -o test
作用:将test.c预处理、汇编、编译并链接形成可执行文件test。-o选项用来指定输出文件的文件名。

3. 选项 -E
用法:#gcc -E test.c -o test.i
作用:将test.c预处理输出test.i文件。

4. 选项 -S
用法:#gcc -S test.i
作用:将预处理输出文件test.i汇编成test.s文件。

5. 选项 -c
用法:#gcc -c test.s
作用:将汇编输出文件test.s编译输出test.o文件。

6. 无选项链接
用法:#gcc test.o -o test
作用:将编译输出文件test.o链接成最终可执行文件test。

7. 选项-O
用法:#gcc -O1 test.c -o test
作用:使用编译优化级别1编译程序。级别为1~3,级别越大优化效果越好,但编译时间越长。

二. 多源文件的编译方法

如果有多个源文件,基本上有两种编译方法:
[假设有两个源文件为test.c和testfun.c]

1. 多个文件一起编译
用法:#gcc testfun.c test.c -o test
作用:将testfun.c和test.c分别编译后链接成test可执行文件。

2. 分别编译各个源文件,之后对编译后输出的目标文件链接。
用法:
#gcc -c testfun.c //将testfun.c编译成testfun.o
#gcc -c test.c //将test.c编译成test.o
#gcc -o testfun.o test.o -o test //将testfun.o和test.o链接成test

以上两种方法相比较,第一中方法编译时需要所有文件重新编译,而第二种方法可以只重新编译修改的文件,未修改的文件不用重新编译。

3. 如果要编译的文件都在同一个目录下,可以用通配符gcc *.c -o 来进行编译。

你是否会问,如果是一个项目的话,可能会有上百个文件,这样的编译法,人不是要累死在电脑前吗,或者等到你编译成功了,岂不是头发都白了,呵呵,所以我们要把上述的编译过程写进以下一个文本文件中:
Linux下称之为makefile
#这里可以写一些文件的说明
MyFirst: MyFirst.o hello.o
g++ MyFirst.o hello.o -o MyFirst
Hello.o:Hello.cpp
g++ -c Hello.cpp -o Hello.o
MyFirst.o:MyFirst.cpp
g++ -c MyFirst.cpp -o MyFirst.o
makefile 编写规则:
(1)以“#”开始的行为注释
(2)文件依赖关系为:
target:components
rule
存盘为MyFirst,在终端输入:make MyFist,程序出现了错误可是所有程序员共同的敌人,在编写程序时我们应该尽量的去避免错误的出现,不过编写的时候再怎么都不可避免的出现这样那样的错误,对程序 进行必要的调试是一个好主意,那我们怎么来调试程序呢,看下面:
gdb ./文件名 ////////////////在这里我修改下要想下面可以调试,在上面编译的 时候必须加上参数g,g++ -g hello.cpp -o hello
以下为调试状态下的可以用到的命令(可以仅输入单词的输入,如break可简为b),尖括号中为说明
list <显示源代码>
break 行号 <设置断点>
run <运行程序>
continue <继续从断点处执行>
print 变量 <调试时查看变量的值>
del 行号 <删除断点>
step <单步执行,可跟踪到函数内部>
next <单步执行,不可跟踪到函数内部>
quit <退出>
makefile 的编写不是件容易的事情,因为自己写的makefile可能不能在所有的unix/linux类操作系统下通用。因此在很多项目中都用automake.autoconf或者是Cmake等工具。

qt 5.x 学习笔记 (2)

先来放一波过程中用到的资料和官方文档好了。

basic layout_qt5.8

QBoxLayout Class_qt5.8

QString Class 5.8

QChar Class qt 5.8

Standard Dialogs Example qt 5.8

更新的部分还是放在最前面好了。。。

convert from QString to char *的时候有个坑。。。

In order to convert a QString to a char*, then you first need to get a latin1 representation of the string by calling toLatin1() on it which will return a QByteArray. Then call data() on the QByteArray to get a pointer to the data stored in the byte array. See the documentation:
See the following example for a demonstration:

举个栗子。。。。

Note that it is necessary to store the bytearray before you call data() on it, a call like the following
const char *c_str2 = str2.toLatin1().data();
will make the application crash as the QByteArray has not been stored and hence no longer exists.

 

 

 

 

继续阅读“qt 5.x 学习笔记 (2)”

qt 5.x 初探(1)

嘛。。为了系统安全课来学一波qt…

现在算是写出了一个可以打开文件,保存文件的记事本。。。

接下来要搞定的事情是。。。如何写一个自定义的事件。。。比如计算个开方之类的。。。

放一波代码好了。。。

 

大概看了一下午。。。这东西看起来虽然说完全没难度。。。但是还是很麻烦啊。。。

代码

 

 

codeforces #413 C. Fountains (BIT维护前缀max)

题目链接

题意:有2种货币,分别为C和D.给出n种资源的代价和美丽度,每种资源只能用其中一种资源购买。现在拥有货币C的数量是c,拥有货币D的数量是d.然后恰好买2个资源,问最大美丽度,不能的话输出0.

思路:首先显然三种情况。。。CC,CD,DD.

CD直接扫一遍。。重点是CC和DD

一开始思路错掉了。。全程写two pointer wa4…一直调。。

最后恍然大悟。。发现two pointer非常错啊。。。

其实正解也很简单?

先去跑步了orz

只要想办法维护每个代价的最大美丽度就好了(更准确得说,是维护小于等于某代价的最大美丽度)

直接BIT搞。维护一个前缀max…好像很稳啊?

不过我竟然对于BIT能维护前缀max吃了一惊?

以往都是用线段树来做这个操作的…想想大概是。。我把BIT的函数起名叫”Sum”的锅。。。

看起来就只能求Sum。。。。233333

 

codeforces #413 B T-shirt buying (贪心)

题目链接

题意:有n个T恤,每个价格都不同,有三种颜色,分别用1,2,3表示,每件T恤给出前xiong和后背的颜色。现在有m个顾客排成一队,对于每个顾客,给出他喜欢的颜色,只要一个T恤的前xiong或者后背的颜色之一满足该颜色即可。顾客总希望买符合他喜欢颜色的T恤中价格最低的。现在问每个顾客买到的T恤的价格,如果某个顾客没有买T恤,输出-1

思路:贪一下?

对于每个颜色,找到价格最低的。记录的时候顺便记录id,以标记某件有2个颜色的衣服是否卖出去了。

1A美滋滋

 

codeforces #413 A. Carrot Cakes (模拟)

题目链接

题意:初始有一个锅,每t分钟可以做好k个饼,现在需要N个饼。还可以另外建一个锅,花费d时间,建好以后两个锅可以并行烙饼。问是否应该建锅?(以期减少烙饼时间)

思路:求出两种情况下的总时间,比较一下。

只有一个锅的情况很好求。

两个锅的情况比较麻烦,不如模拟时间流逝?

反正最多也就1E6的时间。。。模拟一下。。。稳。。

 

 

20170504近况

啊。。在准备考试QAQ

明天约了鹅厂面试。。。然而从四月就开始一直考试考试考试….感觉药丸啊?

MS的结果貌似明天也要出了orz…

之前没收到positive以为是跪了,结果听说有人没收到positive也拿到了offer啊?

以及,被之前拿到的某厂追加了类似sp之类的东西….

虽然说实习工资什么的的确不是很重要,不过比初始的offer 多了60%的工资还是美滋滋的啊?

而且貌似是我们组的boss帮我争取到的T T

好感动啊。。。。

 

哦还有。。后半学期有门叫大数据与云计算的课。。。

大概是做一些,和hadoop,spark,caffe有关的实验orz

我本以为我虽然菜了一点。。。但是毕竟一直在linux环境下。。。

这些东西还是能应付的。。。

结果关键步骤几乎全靠妹子carry啊orz….我好菜.jpg

所以虽然我们因为课程太多没办法像其他情侣一样出去玩。。。

一起在写代码,一起debug也算是另一种浪漫吧(强行自我安慰

增强了专业水平又促进了感情orz

 

哦还有校赛。。。

虽然是菜鸡。。。不过校赛帮忙出题我觉得是老年选手的义务吧。。。。

但是听说dp和数学题已经够多了。。。马丹这两个最好出了吧orz…

尤其我半年没写过题。。。。我当时的idea…早就过时了吧orz…

而且还是校赛…武汉高校都会来吧。。。

万一因为我出的题太差影响了hust的形象那可就。。。。太糟糕了啊。。。