小头编译
1、只要在程序开头加入#include “自定义头文件名”，在编译过程当中，头文件自动会被添加到源文件当中一起进行编译。
2、编译，编译程序读取源程序（字符流），对之进行词法和语法的分析，将高级语言指令转换为功能等效的汇编代码，再由汇编程序转换为机器语言，并且按照操作系统对可执行文件格式的要求链接生成可执行程序。C源程序头文件－－>预编译处理(cpp)－－>编译程序本身－－>优化程序－－>汇编程序－－>链接程序-->可执行文件。
❷ eclipse用来编译的小榔头不见了，怎么设置
首先，我们打开一下Eclipse，我这里由于用了结合Android sdk的 版本，界面可能不一样。
❸ Little-Endian的JAVA
JAVA字节序
BIG-ENDIAN、LITTLE-ENDIAN跟多字节类型的数据有关，比如int,short,long型，而对单字节数据byte却没有影响。BIG-ENDIAN就是低位字节排放在内存的高端，高位字节排放在内存的低端。而LITTLE-ENDIAN正好相反。
比如 int a = 0x05060708
在BIG-ENDIAN的情况下存放为：
字节号 0 1 2 3
数据 05 06 07 08
在LITTLE-ENDIAN的情况下存放为：
字节号 0 1 2 3
数据 08 07 06 05
BIG-ENDIAN、LITTLE-ENDIAN跟CPU有关，每一种CPU不是BIG-ENDIAN就是LITTLE-ENDIAN。IA架构的CPU中是Little-Endian，而PowerPC 、SPARC和Motorola处理器则是BIG-ENDIAN。这其实就是所谓的主机字节序。而网络字节序是指数据在网络上传输时是大头还是小头的，在Internet的网络字节序是BIG-ENDIAN。所谓的JAVA字节序指的是在JAVA虚拟机中多字节类型数据的存放顺序，JAVA字节序也是BIG-ENDIAN。
所以在用C/C++写通信程序时，在发送数据前务必用htonl和htons去把整型和短整型的数据进行从主机字节序到网络字节序的转换，而接收数据后对于整型和短整型数据则必须调用ntohl和ntohs实现从网络字节序到主机字节序的转换。如果通信的一方是JAVA程序、一方是C/C++程序时，则需要在C/C++一侧使用以上几个方法进行字节序的转换，而JAVA一侧，则不需要做任何处理，因为JAVA字节序与网络字节序都是BIG-ENDIAN，只要C/C++一侧能正确进行转换即可（发送前从主机序到网络序，接收时反变换）。如果通信的双方都是JAVA，则根本不用考虑字节序的问题了。
如果网络上全部是PowerPC,SPARC和Motorola CPU的主机那么不会出现任何问题，但由于实际存在大量的IA架构的CPU，所以经常出现数据传输错误。
文章开头所提出的问题，就是因为程序运行在X86架构的PC SERVER上，发送数据的一端是用C实现的，接收一端是用JAVA实现的，而发送端在发送数据前未进行从主机字节序到网络字节序的转换，这样接收端接收到的是LITTLE-ENDIAN的数据，数据解释自然出错。
具体数据如下，实际发送的数据为23578
发送端发送数据： 1A 5C
接收端接收到数据后，按BIG-ENDIAN进行解释具体数据是多少？你们自己去计算并比较吧！
===============================================================================================
Big Endian and Little Endian
谈到字节序的问题，必然牵涉到两大CPU派系。那就是Motorola的PowerPC系列CPU和Intel的x86系列CPU。PowerPC系列采用big endian方式存储数据，而x86系列则采用little endian方式存储数据
为什么要注意字节序的问题呢？你可能这么问。当然，如果你写的程序只在单机环境下面运行，并且不和别人的程序打交道，那么你完全可以忽略字节序的存在。但是，如果你的程序要跟别人的程序产生交互呢？尤其是当你把你在微机上运算的结果运用到计算机群上去的话。在这里我想说说两种语言。C/C++语言编写的程序里数据存储顺序是跟编译平台所在的CPU相关的，而JAVA编写的程序则唯一采用big endian方式来存储数据。试想，如果你用C/C++语言在x86平台下编写的程序跟别人的JAVA程序互通时会产生什么结果？就拿上面的 0x12345678来说，你的程序传递给别人的一个数据，将指向0x12345678的指针传给了JAVA程序，由于JAVA采取big endian方式存储数据，很自然的它会将你的数据翻译为0x8765431。什么？竟然变成另外一个数字了？是的，就是这种后果。因此，在你的C程序传给JAVA程序之前有必要进行字节序的转换工作。
Big-Endian和Little-Endian优缺点
Big-Endian优点：靠首先提取高位字节，你总是可以由看看在偏移位置为0的字节来确定这个数字是正数还是负数。你不必知道这个数值有多长，或者你也不必过一些字节来看这个数值是否含有符号位。这个数值是以它们被打印出来的顺序存放的，所以从二进制到十进制的函数特别有效。因而，对于不同要求的机器，在设计存取方式时就会不同。
Little-Endian优点：提取一个，两个，四个或者更长字节数据的汇编指令以与其他所有格式相同的方式进行：首先在偏移地址为0的地方提取最低位的字节，因为地址偏移和字节数是一对一的关系，多重精度的数学函数就相对地容易写了。
如果你增加数字的值，你可能在左边增加数字（高位非指数函数需要更多的数字）。因此，经常需要增加两位数字并移动存储器里所有Big-endian顺序的数字，把所有数向右移，这会增加计算机的工作量。不过，使用Little- Endian的存储器中不重要的字节可以存在它原来的位置，新的数可以存在它的右边的高位地址里。这就意味着计算机中的某些计算可以变得更加简单和快速。
❹ c语言问题求解！！！！！！！！！！！1
答案是不确定，
因为在PC中你的编译器int型是4个字节存储的，这个可以修改的，上网搜吧；所以输出是不确定的。
下面是我修改后的程序：
#include "stdio.h"
main()
{union{char i[4];
int k;
}r;
r.i[0]=2;r.i[1]=0;
r.i[2]=0;r.i[3]=0;
printf("%d",r.k);}
输出结果是2
我用的编译器是VC6.0
还有就是上面的回答，多字节存储时有大头和小头之分，就是数据的高位存储在高地址还是存储在低地址中。根据实验结果，数据的低字节存储在低地址位中，即小头
查资料C++中int型在Windows 98、NT、XP、Macintosh OS X、VAX和很多PC中都是32位
可以用sizeof（int）验证；
你也可以将原来的 int 更换为short，short型是两个字节。可以用sizeof（short）验证
❺ 关于在linux下用gcc编译头文件
首先，确定你的头文件都用宏隔开了，防止了重复定义。例如，在file.h 中的开头就是
#ifndef __FILE__HEAD___
#define __FILE__HEAD___
//头文件中的内容
#endif //__FILE__HEAD___
之后，
file.h中用到了list.h ，所以file.h中#include "list.h"//假设头文件都在同一目录下
list.h中用到了preapre.h 所以list.h中#include "prepare.h"
prepare.h中用到了node.h 所以prepare.h中#include "node.h"
在某些情况下，由于代码组织等的问题，还是会出现编译问题，这个就是代码组织技巧的问题了，要根据具体代码具体判断了。
另外，准确的说头文件只是在编译的第一步，预处理的时候使用了，真正被“编”的应该是源文件，这个是编译原理方面的问题了。
❻ c语言高手进
第一个问题：Union在内存中的样子是{2,0,0,0}，一共四个字节，前两个i与k公用，后两个由于没有赋值应该是0。然后输出的时候，把这四个字节一起作为一个int,注意了问题就在这里：Intel的芯片中，内存中的变量是按从低位到高位排列的，术语叫“小头在前”，这与人们数学上的习惯不一样！也就是k在内存中是{2,0,0,0}在逻辑上应该是{0,0,0,2}，这个反转操作是在CPU内部完成的，如果不像你这样刻意去查看是发现不了的。这是体系结构的问题造成的，如果在Mac机上就不会这样了。
第二个问题是C的问题：C中声明在函数形参中的数组会“褪化”成首位指针，就是说void fun(double b[10][22])与void fun(double (*)b[10])是没有区别的，编译器会忽略数组大小。正由于这个大小被忽略了，所以教科书上要求在后面的形参中显式地提供大小，就是void fun(double (*)[10],int m,int n) 这个样子了。如果函数有其他方法知道数组的大小，那么后面的形参就不是必要的。
❼ 求一个控制摄像头小程序的源码，要求VC下编译运行
VC-摄像头控制SDK源码
#include <windows.h>
#include <stdio.h>
#include <vfw.h>
#pragma comment(lib,"vfw32.lib")
HWND ghWndCap ; //捕获窗的句柄
CAPDRIVERCAPS gCapDriverCaps ; //视频驱动器的能力
CAPSTATUS gCapStatus ; //捕获窗的状态
char szCaptureFile[] = "MYCAP.AVI";
char gachBuffer[20];
LRESULT CALLBACK WndProc(HWND,UINT,WPARAM,LPARAM);
LRESULT CALLBACK StatusCallbackProc(HWND hWnd,int nID,LPSTR lpStatusText)
{
if(!ghWndCap)return FALSE;//获得捕获窗的状态
capGetStatus(ghWndCap,&gCapStatus,sizeof(CAPSTATUS));//更新捕获窗的大小
SetWindowPos(ghWndCap,NULL,0,0,gCapStatus.uiImageWidth,gCapStatus.uiImageHeight,SWP_NOZORDER|SWP_NOMOVE);
if(nID==0){//清除旧的状态信息
SetWindowText(ghWndCap,(LPSTR)"hello");
return (LRESULT)TRUE;
}//显示状态ID和状态文本
wsprintf(gachBuffer,"Status# %d: %s",nID,lpStatusText);
SetWindowText(ghWndCap,(LPSTR)gachBuffer);
return (LRESULT)TRUE;
}
LRESULT CALLBACK ErrorCallbackProc(HWND hWnd,int nErrID,LPSTR lpErrorText)
{
if(!ghWndCap)return FALSE;
if(nErrID==0)return TRUE;//清除旧的错误
wsprintf(gachBuffer,"Error# %d",nErrID);//显示错误标识和文本
MessageBox(hWnd, lpErrorText, gachBuffer,MB_OK | MB_ICONEXCLAMATION);
return (LRESULT) TRUE;
}
LRESULT CALLBACK FrameCallbackProc(HWND hWnd,LPVIDEOHDR lpVHdr)
{
FILE *fp;
fp=fopen("caram.dat","w");
if(!ghWndCap)return FALSE;//假设fp为一打开的.dat文件指针
fwrite(lpVHdr->lpData,1,lpVHdr->dwBufferLength,fp);
return (LRESULT)TRUE;
}
int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,PSTR szCmdLine,int iCmdShow)
{
static TCHAR szAppName[]=TEXT("HelloWin");
HWND hwnd;
MSG msg;
WNDCLASS wndclass;
wndclass.style=CS_HREDRAW|CS_VREDRAW;
wndclass.lpfnWndProc=WndProc;
wndclass.cbClsExtra=0;
wndclass.cbWndExtra=0;
wndclass.hInstance=hInstance;
wndclass.hIcon=LoadIcon(NULL,IDI_APPLICATION);
wndclass.hCursor=LoadCursor(NULL,IDC_ARROW);
wndclass.hbrBackground=(HBRUSH)GetStockObject(WHITE_BRUSH);
wndclass.lpszMenuName=NULL;
wndclass.lpszClassName=szAppName;
if(!RegisterClass(&wndclass))
{
MessageBox(NULL,TEXT("This program requires WindowsNT!"),szAppName,MB_ICONERROR);
return 0;
}
hwnd=CreateWindow(szAppName,TEXT("The Hello Program"),WS_OVERLAPPEDWINDOW,CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,NULL,NULL,hInstance,NULL);
ShowWindow(hwnd,iCmdShow);
UpdateWindow(hwnd);
while(GetMessage(&msg,NULL,0,0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return msg.wParam;
}
LRESULT CALLBACK WndProc(HWND hwnd,UINT message,WPARAM wParam,LPARAM lParam)
{
HDC hdc;
PAINTSTRUCT ps;
RECT rect;
switch(message)
{
case WM_CREATE:
{
ghWndCap=capCreateCaptureWindow((LPSTR)"Capture Window",WS_CHILD|WS_VISIBLE,0,0,300,240,(HWND)hwnd,(int)0);
capSetCallbackOnError(ghWndCap,(FARPROC)ErrorCallbackProc);
capSetCallbackOnStatus(ghWndCap,(FARPROC)StatusCallbackProc);
capSetCallbackOnFrame(ghWndCap,(FARPROC)FrameCallbackProc);
capDriverConnect(ghWndCap,0); // 将捕获窗同驱动器连接
//获得驱动器的能力,相关的信息放在结构变量gCapDriverCaps中
capDriverGetCaps(ghWndCap,&gCapDriverCaps,sizeof(CAPDRIVERCAPS));
capPreviewRate(ghWndCap, 66); // 设置Preview模式的显示速率
capPreview(ghWndCap, TRUE); //启动Preview模式
if(gCapDriverCaps.fHasOverlay) //检查驱动器是否有叠加能力
capOverlay(ghWndCap,TRUE); //启动Overlay模式
if(gCapDriverCaps.fHasDlgVideoSource)capDlgVideoSource(ghWndCap); //Video source 对话框
if(gCapDriverCaps.fHasDlgVideoFormat)capDlgVideoFormat(ghWndCap); // Video format 对话框
if(gCapDriverCaps.fHasDlgVideoDisplay)capDlgVideoDisplay(ghWndCap); // Video display 对话框
capFileSetCaptureFile( ghWndCap, szCaptureFile); //指定捕获文件名
capFileAlloc(ghWndCap, (1024L * 1024L * 5)); //为捕获文件分配存储空间
capCaptureSequence(ghWndCap); //开始捕获视频序列
capGrabFrame(ghWndCap); //捕获单帧图像
}
return 0;
case WM_PAINT:
hdc=BeginPaint(hwnd,&ps);
GetClientRect(hwnd,&rect);
DrawText(hdc,TEXT("Hello,Windows98!"),-1,&rect,DT_SINGLELINE|DT_CENTER|DT_VCENTER);
EndPaint(hwnd,&ps);
return 0;
case WM_DESTROY:
{
capSetCallbackOnStatus(ghWndCap,NULL);
capSetCallbackOnError(ghWndCap,NULL);
capSetCallbackOnFrame(ghWndCap,NULL);
capCaptureAbort(ghWndCap);//停止捕获
capDriverDisconnect(ghWndCap); //将捕获窗同驱动器断开
PostQuitMessage(0);
}
return 0;
}
return DefWindowProc(hwnd,message,wParam,lParam);
}