C语言与Python的奇妙玩法-优快云博客

在C语言中可以插入一行代码不影响程序

#include<stdio.h>
main(){
	printf("hi,hi,hi!!!!!%%%d",101);
	char* x;
	https://blog.csdn.net/PIPE111/article/details/105406271
	return 0;
}

谁说#define后面不能有分号？我就能用它偷懒

#include<stdio.h>
#define A(x) x;x;x;x;
main(){
	int x=0;
	A(A(printf("sidgf%d",++x)));
	return 0;
}

什么？你不信？来来来，给你看看.i文件：

#include<stdio.h>
main(){
	int x=0;
	printf("sidgf%d",++x);
	printf("sidgf%d",++x);
	printf("sidgf%d",++x);
	printf("sidgf%d",++x);
	printf("sidgf%d",++x);
	printf("sidgf%d",++x);
	printf("sidgf%d",++x);
	printf("sidgf%d",++x);
	printf("sidgf%d",++x);
	printf("sidgf%d",++x);
	printf("sidgf%d",++x);
	printf("sidgf%d",++x);
	printf("sidgf%d",++x);
	printf("sidgf%d",++x);
	printf("sidgf%d",++x);
	printf("sidgf%d",++x);;
}

谁说执行语句必须是函数名称(函数参数)格式？

#define asdfghjkl printf("%d",1)
main(){
	asdfghjkl;
	return 0;
}

谁规定每条语句后面必须有分号？

#define a(x,y) printf("%d%d",x,y);
main(){
	a(1208,183070)
	return 0;
}

谁说swap函数必须用中间值？

#define swap(x,y) {a=a^b;b=a^b;a=a^b;}

谁说双斜杠注释只有一行？

//第一行\
第二行

C++有了这一句，你什么class都用不了

#define public protected

有了这一句，保证你的程序运行不了

#define main mianmianmianmianmianimah

Windows下用控制台画雨伞

#include<io.h>
#include<fcntl.h>
#include<iostream>
void pu(wchar_t a){
	_setmode(_fileno(stdout),_O_U16TEXT);
	wcout<<L"\u2602";
	_setmode(_fileno(stdout),_O_TEXT);
}

Python3中可以这么干

我=2380
你=230740
我=你
def 猪(s):
	print(s,"是猪")
猪(我)

Python中的惊喜

import this

Python语句后面可以有分号

print(23);

Javascript的漏洞

在这里插入图片描述

文件可以没有名

在这里插入图片是否v恢复骨结核的虽然他的同意让特大型踩踩踩踩踩踩踩踩踩踩踩踩踩踩踩佛山人突然描述
我得声明一下，我没有插入不可见Unicode字符。
不信？看！
在这里插入图片描述

谁说biang打不出来？

在这里插入图片描述

cmd中cd的秘密

Microsoft Windows [版本 10.0.18362.720]
(c) 2019 Microsoft Corporation。保留所有 权利。

C:\Users\M S I>cd ..

C:\Users>cd C:\Users\M S I\

C:\Users\M S I>cd ..\..

C:\>

结束所有进程（蓝屏）

taskkill /f /im *.*

我不知道这是什么

C:\>^
More?
More?
C:\>

python的this

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
>>>