Friday, March 13, 2009
Friday, February 20, 2009
Sunday, February 15, 2009
Build DLL with Cygwin
[source]
[Building and Using DLLs]
> Could you please tell me where I might read more on
> __declspec(dllexport) and __declspec(dllimport)
>
> I do not understand how to use these....
That's a complicated question. Essentially, the MS engineers were on crack
when they designed Windows DLLs. When compiling code to become a DLL, you
must explicitly tell the compiler which symbols(1) will be exported(2) from
the DLL in the declarations(3) of the symbols. When compiling code that
will use a DLL, you must explicitly tell the compiler which symbols will be
imported from DLLs as opposed to statically linked into your program. At
first this doesn't sound so bad, but essentially it means you need three
different versions of all of your declarations for:
1. compiling code to become the DLL
2. compiling code to use the DLL
3. compiling code that will be statically linked
Consider the case of function "foo()" defined in "foo.c" that will be used
in the "main()" of a program "bar.exe" that is defined in "bar.c" . If foo()
is statically linked into bar.exe, your files might look like this:
--- foo.c ---
/* declaration (AKA prototype) of foo(), usually found in .h file */
int foo();
/* definition of foo() */
int foo() { return 1; }
-------------
Compile foo.c:
gcc -c foo.c -o foo.o
--- bar.c ---
/* declaration (AKA prototype) of foo(), usually found in .h file */
int foo();
int main() { return foo(); }
--------------
Compile bar.c and link foo.o into bar.exe statically:
gcc -c bar.c -o bar.o
gcc foo.o bar.o -o bar.exe
However, if foo() should go into a DLL, your files need to look like this:
--- foo.c ---
/* declaration (AKA prototype) of foo(), usually found in .h file */
__declspec(dllexport) int foo(); /* exporting foo() from this DLL */
/* definition of foo() */
int foo() { return 1; }
-------------
Make a DLL from foo.c:
gcc -c foo.c -o foo.o
gcc -Wl,--out-implib,libfoo.import.a -shared -o foo.dll foo.o
This will create the DLL (foo.dll) and the import library for the DLL
(libfoo.import.a).
--- bar.c ---
/* declaration (AKA prototype) of foo(), usually found in .h file */
__declspec(dllimport) int foo(); /* importing foo() from DLL */
int main() { return foo(); }
--------------
Compile and link bar.exe to use foo.dll (via its import library):
gcc -c bar.c -o bar.o
gcc bar.o libfoo.import.a -o bar.exe
bar.exe now uses foo.dll.
So we have three different possible declarations of the function foo():
1. int foo(); /* static linking */
2. __declspec(dllexport) int foo(); /* making DLL with foo() in it */
3. __declspec(dllimport) int foo(); /* importing foo() from DLL */
Which one we use depends on how we are using foo(). The real problem is
that most people don't want to deal with three sets of declarations but want
to just have one header file which is used in all cases. To solve this you
could do something like this:
--- foo.h ---
#if defined(MAKEDLL)
# define INTERFACE __declspec(dllexport)
#elif defined(USEDLL)
# define INTERFACE __declspec(dllimport)
#else
# define INTERFACE
#endif
INTERFACE int foo();
-------------
--- foo.c ---
#include "foo.h"
int foo() { return 1; }
-------------
--- bar.c ---
#include "foo.h"
int main() { return foo(); }
--------------
Now you are only maintaining the declaration of foo() in one place: foo.h.
To compile bar.exe to statically link in foo():
gcc -c foo.c -o foo.o
gcc -c bar.c -o bar.o
gcc foo.o bar.o -o bar.exe
To compile foo() into a DLL:
gcc -DMAKEDLL -c foo.c -o foo.o
gcc -Wl,--out-implib,libfoo.import.a -shared -o foo.dll foo.o
To compile bar.exe to use the DLL:
gcc -DUSEDLL -c bar.c -o bar.exe
gcc bar.o libfoo.import.a -o bar.exe
That's all there is to it.
(1)functions, methods and variables in structs / classes, external
variables
(2)available to programs that use the DLL
(3)function prototypes, class definitions, etc.-- the stuff found in
your header files
Hope this helps,
Carl Thompson
PS: for structs / classes instead of doing this:
class foo {
public:
INTERFACE int bar;
INTERFACE int baz;
}
You can do this:
class INTERFACE foo {
public:
int bar;
int baz;
}
They are both equivalent, but the second way is cleaner.
PPS: I've heard you can do the same thing using separate ".DEF" files,
but I don't know about that.
PPPS: None of this is necessary with reasonable operating systems, such
as Unix or Linux. The compiler and linker automatically export
and import all externally visible symbols when building or using
DLLs (shared libraries). You don't even need a separate import
library.
> ...
[Building and Using DLLs]
> Could you please tell me where I might read more on
> __declspec(dllexport) and __declspec(dllimport)
>
> I do not understand how to use these....
That's a complicated question. Essentially, the MS engineers were on crack
when they designed Windows DLLs. When compiling code to become a DLL, you
must explicitly tell the compiler which symbols(1) will be exported(2) from
the DLL in the declarations(3) of the symbols. When compiling code that
will use a DLL, you must explicitly tell the compiler which symbols will be
imported from DLLs as opposed to statically linked into your program. At
first this doesn't sound so bad, but essentially it means you need three
different versions of all of your declarations for:
1. compiling code to become the DLL
2. compiling code to use the DLL
3. compiling code that will be statically linked
Consider the case of function "foo()" defined in "foo.c" that will be used
in the "main()" of a program "bar.exe" that is defined in "bar.c" . If foo()
is statically linked into bar.exe, your files might look like this:
--- foo.c ---
/* declaration (AKA prototype) of foo(), usually found in .h file */
int foo();
/* definition of foo() */
int foo() { return 1; }
-------------
Compile foo.c:
gcc -c foo.c -o foo.o
--- bar.c ---
/* declaration (AKA prototype) of foo(), usually found in .h file */
int foo();
int main() { return foo(); }
--------------
Compile bar.c and link foo.o into bar.exe statically:
gcc -c bar.c -o bar.o
gcc foo.o bar.o -o bar.exe
However, if foo() should go into a DLL, your files need to look like this:
--- foo.c ---
/* declaration (AKA prototype) of foo(), usually found in .h file */
__declspec(dllexport) int foo(); /* exporting foo() from this DLL */
/* definition of foo() */
int foo() { return 1; }
-------------
Make a DLL from foo.c:
gcc -c foo.c -o foo.o
gcc -Wl,--out-implib,libfoo.import.a -shared -o foo.dll foo.o
This will create the DLL (foo.dll) and the import library for the DLL
(libfoo.import.a).
--- bar.c ---
/* declaration (AKA prototype) of foo(), usually found in .h file */
__declspec(dllimport) int foo(); /* importing foo() from DLL */
int main() { return foo(); }
--------------
Compile and link bar.exe to use foo.dll (via its import library):
gcc -c bar.c -o bar.o
gcc bar.o libfoo.import.a -o bar.exe
bar.exe now uses foo.dll.
So we have three different possible declarations of the function foo():
1. int foo(); /* static linking */
2. __declspec(dllexport) int foo(); /* making DLL with foo() in it */
3. __declspec(dllimport) int foo(); /* importing foo() from DLL */
Which one we use depends on how we are using foo(). The real problem is
that most people don't want to deal with three sets of declarations but want
to just have one header file which is used in all cases. To solve this you
could do something like this:
--- foo.h ---
#if defined(MAKEDLL)
# define INTERFACE __declspec(dllexport)
#elif defined(USEDLL)
# define INTERFACE __declspec(dllimport)
#else
# define INTERFACE
#endif
INTERFACE int foo();
-------------
--- foo.c ---
#include "foo.h"
int foo() { return 1; }
-------------
--- bar.c ---
#include "foo.h"
int main() { return foo(); }
--------------
Now you are only maintaining the declaration of foo() in one place: foo.h.
To compile bar.exe to statically link in foo():
gcc -c foo.c -o foo.o
gcc -c bar.c -o bar.o
gcc foo.o bar.o -o bar.exe
To compile foo() into a DLL:
gcc -DMAKEDLL -c foo.c -o foo.o
gcc -Wl,--out-implib,libfoo.import.a -shared -o foo.dll foo.o
To compile bar.exe to use the DLL:
gcc -DUSEDLL -c bar.c -o bar.exe
gcc bar.o libfoo.import.a -o bar.exe
That's all there is to it.
(1)functions, methods and variables in structs / classes, external
variables
(2)available to programs that use the DLL
(3)function prototypes, class definitions, etc.-- the stuff found in
your header files
Hope this helps,
Carl Thompson
PS: for structs / classes instead of doing this:
class foo {
public:
INTERFACE int bar;
INTERFACE int baz;
}
You can do this:
class INTERFACE foo {
public:
int bar;
int baz;
}
They are both equivalent, but the second way is cleaner.
PPS: I've heard you can do the same thing using separate ".DEF" files,
but I don't know about that.
PPPS: None of this is necessary with reasonable operating systems, such
as Unix or Linux. The compiler and linker automatically export
and import all externally visible symbols when building or using
DLLs (shared libraries). You don't even need a separate import
library.
> ...
Creating a shared and static library with GCC
[source]
Here's a summary on how to create a shared and a static library with gcc. The goal is to show the basic steps. I do not want to go into the hairy details. It should be possible to use this page as a reference.
These examples were tested and run on cygwin/Windows.
The code for the library
This is the code that goes into the library. It exhibits one single function that takes two doubles and calculates their mean value and returns it.
calc_mean.c
//#include
double mean(double a, double b) {
return (a+b) / 2;
}
The header file
Of course, we need a header file.
calc_mean.h
double mean(double, double);
Creating the static library
A static library is basically a set of object files that were copied into a single file. This single file is the static library. The static file is created with the archiver (ar).
First, calc_mean.c is turned into an object file:
gcc -c calc_mean.c -o calc_mean.o
Then, the archiver (ar) is invoked to produce a static library (named libmean.a) out of the object file calc_mean.o.
ar rcs libmean.a calc_mean.o
Note: the library must start with the three letters lib and have the suffix .a.
Creating the shared library
As with static libraries, an object file is created. The -fPIC option tells gcc to create position independant code which is necessary for shared libraries. Note also, that the object file created for the static library will be overwritten. That's not bad, however, because we have a static library that already contains the needed object file.
gcc -c -fPIC calc_mean.c -o calc_mean.o
For some reason, gcc says:
cc1: warning: -fPIC ignored for target (all code is position independent)
It looks like -fPIC is not necessary on x86, but all manuals say, it's needed, so I use it too.
Now, the shared library is created
gcc -shared -Wl,-soname,libmean.so.1 -o libmean.so.1.0.1 calc_mean.o
Note: the library must start with the three letter lib.
The programm using the library
This is the program that uses the calc_mean library. Once, we will link it against the static library and once against the shared library.
main.c
#include
#include "calc_mean.h"
int main(int argc, char* argv[]) {
double v1, v2, m;
v1 = 5.2;
v2 = 7.9;
m = mean(v1, v2);
printf("The mean of %3.2f and %3.2f is %3.2f\n", v1, v2, m);
return 0;
}
Linking against static library
gcc -static main.c -L. -lmean -o statically_linked
Note: the first three letters (the lib) must not be specified, as well as the suffix (.a)
Linking against shared library
gcc main.c -o dynamically_linked -L. -lmean
Note: the first three letters (the lib) must not be specified, as well as the suffix (.so)
Executing the dynamically linked programm
LD_LIBRARY_PATH=.
./dynamically_linked
Here's a summary on how to create a shared and a static library with gcc. The goal is to show the basic steps. I do not want to go into the hairy details. It should be possible to use this page as a reference.
These examples were tested and run on cygwin/Windows.
The code for the library
This is the code that goes into the library. It exhibits one single function that takes two doubles and calculates their mean value and returns it.
calc_mean.c
//#include
double mean(double a, double b) {
return (a+b) / 2;
}
The header file
Of course, we need a header file.
calc_mean.h
double mean(double, double);
Creating the static library
A static library is basically a set of object files that were copied into a single file. This single file is the static library. The static file is created with the archiver (ar).
First, calc_mean.c is turned into an object file:
gcc -c calc_mean.c -o calc_mean.o
Then, the archiver (ar) is invoked to produce a static library (named libmean.a) out of the object file calc_mean.o.
ar rcs libmean.a calc_mean.o
Note: the library must start with the three letters lib and have the suffix .a.
Creating the shared library
As with static libraries, an object file is created. The -fPIC option tells gcc to create position independant code which is necessary for shared libraries. Note also, that the object file created for the static library will be overwritten. That's not bad, however, because we have a static library that already contains the needed object file.
gcc -c -fPIC calc_mean.c -o calc_mean.o
For some reason, gcc says:
cc1: warning: -fPIC ignored for target (all code is position independent)
It looks like -fPIC is not necessary on x86, but all manuals say, it's needed, so I use it too.
Now, the shared library is created
gcc -shared -Wl,-soname,libmean.so.1 -o libmean.so.1.0.1 calc_mean.o
Note: the library must start with the three letter lib.
The programm using the library
This is the program that uses the calc_mean library. Once, we will link it against the static library and once against the shared library.
main.c
#include
#include "calc_mean.h"
int main(int argc, char* argv[]) {
double v1, v2, m;
v1 = 5.2;
v2 = 7.9;
m = mean(v1, v2);
printf("The mean of %3.2f and %3.2f is %3.2f\n", v1, v2, m);
return 0;
}
Linking against static library
gcc -static main.c -L. -lmean -o statically_linked
Note: the first three letters (the lib) must not be specified, as well as the suffix (.a)
Linking against shared library
gcc main.c -o dynamically_linked -L. -lmean
Note: the first three letters (the lib) must not be specified, as well as the suffix (.so)
Executing the dynamically linked programm
LD_LIBRARY_PATH=.
./dynamically_linked
Monday, January 26, 2009
Find Files in Linux
find -name 'mypage.htm'
In the above command the system would search for any file named mypage.htm in the current directory and any subdirectory.
find / -name 'mypage.htm'
In the above example the system would search for any file named mypage.htm on the root and all subdirectories from the root.
find -name 'file*'
In the above example the system would search for any file beginning with file in the current directory and any subdirectory.
find -name '*' -size +1000k
In the above example the system would search for any file that is larger then 1000k.
( expression )
True if expression is true.
! expression
Negation of a primary; the unary NOT operator.
expression [-a] expression
Conjunction of primaries; the AND operator is implied by the juxtaposition of two primaries or made explicit by the optional -a operator. The second expression shall not be evaluated if the first expression is false.
expression -o expression
Alternation of primaries; the OR operator. The second expression shall not be evaluated if the first expression is true.
find \( -name 'hello*' -a -name '*.sh' \)
find \( -name '*.sh' -o -name '*.txt' \)
對找到檔案做處理: -exec
有時我們會把找到的特定檔做特別的處理 ,像是刪除和移動就可以用 exec來處理
請看範例。請注意指令的後面要加 \; 來做結束
而此範例是把找到的檔案cp 到user的家目錄下的txt目錄裡面,在這裡的重點是 {}就是找到檔案的代號, 而exec 後面就是要操作的命令
find /tmp/ -type f -name "*.txt" -exec cp {} ~/txt \;
In the above command the system would search for any file named mypage.htm in the current directory and any subdirectory.
find / -name 'mypage.htm'
In the above example the system would search for any file named mypage.htm on the root and all subdirectories from the root.
find -name 'file*'
In the above example the system would search for any file beginning with file in the current directory and any subdirectory.
find -name '*' -size +1000k
In the above example the system would search for any file that is larger then 1000k.
( expression )
True if expression is true.
! expression
Negation of a primary; the unary NOT operator.
expression [-a] expression
Conjunction of primaries; the AND operator is implied by the juxtaposition of two primaries or made explicit by the optional -a operator. The second expression shall not be evaluated if the first expression is false.
expression -o expression
Alternation of primaries; the OR operator. The second expression shall not be evaluated if the first expression is true.
find \( -name 'hello*' -a -name '*.sh' \)
find \( -name '*.sh' -o -name '*.txt' \)
對找到檔案做處理: -exec
有時我們會把找到的特定檔做特別的處理 ,像是刪除和移動就可以用 exec來處理
請看範例。請注意指令的後面要加 \; 來做結束
而此範例是把找到的檔案cp 到user的家目錄下的txt目錄裡面,在這裡的重點是 {}就是找到檔案的代號, 而exec 後面就是要操作的命令
find /tmp/ -type f -name "*.txt" -exec cp {} ~/txt \;
My First Makefile
[Makefile]
# Makefile Test
include FileList
CC = gcc
CFG = release
OBJS = $(addsuffix .o, $(basename $(SOURCE)))
EXE = hello
# release
CFLAGS_RELEASE = -O2
DFLAGS_RELEASE = LINUX OS_POSIX
# debug
CFLAGS_DEBUG =
DFLAGS_DEBUG = _DEBUG LINUX OS_POSIX
# switch CFG
ifeq ($(CFG), release)
CFLAGS = $(CFLAGS_RELEASE)
DFLAGS = $(addprefix -D, $(DFLAGS_RELEASE))
else
CFLAGS = $(CFLAGS_DEBUG)
DFLAGS = $(addprefix -D, $(DFLAGS_DEBUG))
endif
# make rules
all: $(EXE)
$(EXE): $(OBJS)
$(CC) $(CFLAGS) -o $@ $^
%.o: %.c
$(CC) $(CFLAGS) $(DFLAGS) -c $<
clean:
rm -f $(EXE) $(OBJS)
[filelist.sh]
#!/bin/sh
FileList=`find -name '*.c'`
echo "SOURCE =" '\'
for i in $FileList; do
echo $i '\'
done
echo
# Makefile Test
include FileList
CC = gcc
CFG = release
OBJS = $(addsuffix .o, $(basename $(SOURCE)))
EXE = hello
# release
CFLAGS_RELEASE = -O2
DFLAGS_RELEASE = LINUX OS_POSIX
# debug
CFLAGS_DEBUG =
DFLAGS_DEBUG = _DEBUG LINUX OS_POSIX
# switch CFG
ifeq ($(CFG), release)
CFLAGS = $(CFLAGS_RELEASE)
DFLAGS = $(addprefix -D, $(DFLAGS_RELEASE))
else
CFLAGS = $(CFLAGS_DEBUG)
DFLAGS = $(addprefix -D, $(DFLAGS_DEBUG))
endif
# make rules
all: $(EXE)
$(EXE): $(OBJS)
$(CC) $(CFLAGS) -o $@ $^
%.o: %.c
$(CC) $(CFLAGS) $(DFLAGS) -c $<
clean:
rm -f $(EXE) $(OBJS)
[filelist.sh]
#!/bin/sh
FileList=`find -name '*.c'`
echo "SOURCE =" '\'
for i in $FileList; do
echo $i '\'
done
echo
Tuesday, December 30, 2008
Unicode and RichEditCtrl
[source]
Unicode and RichEditCtrl
Unicode Strings in MFC
The easiest way to deal with Unicode strings is to use CStringW class. As it is, CStringW can edit Unicode strings. Another option is to use char* equivalent wide-byte type in MFC called LPWSTR.
Writing and reading Unicode strings to and from controls in MFC is not exactly as straight forward. GetDlgItemText and SetDlgItemText only take single byte character strings. This page explains how to send messages to set and retrieve Unicode strings to the controls without the use of those functions.
Take a look at the following functions. Those functions read and write Unicode strings from and to MFC controls (RichEditCtrl). Sending messages requires several steps. First is to specify the type of the message. The type of the message, the codepage, and other optional settings are set to a structure called GETTEXTEX and SETTEXTEX. Then calculate and prepare space to store the results.
LPWSTR GetUnicodeString(UINT id)
{
CRichEditCtrl* edit=(CRichEditCtrl*)GetDlgItem(id);
int nLength = edit->GetTextLengthEx(GTL_DEFAULT,1200);
LPWSTR lpszWChar = new WCHAR[nLength+1];
GETTEXTEX getTextEx;
getTextEx.cb=(nLength+1)*sizeof(WCHAR);
getTextEx.codepage=1200;
getTextEx.flags=GT_DEFAULT;
getTextEx.lpDefaultChar=NULL;
getTextEx.lpUsedDefChar=NULL;
edit->SendMessage(EM_GETTEXTEX, (WPARAM)&getTextEx, (LPARAM)lpszWChar);
return lpszWChar;
}
void SetUnicodeString(UINT id, LPWSTR str)
{
SETTEXTEX setTextEx;
setTextEx.codepage=1200;
setTextEx.flags=ST_DEFAULT;
CRichEditCtrl *caption=(CRichEditCtrl*)GetDlgItem(id);
if(caption!=NULL)
caption->SendMessage(EM_SETTEXTEX, (WPARAM)&setTextEx, (LPARAM)str);
}
The usage of GetUnicodeString above is shown below. Specify the ID of the RichEditCtrl control.
CStringW str=GetUnicodeString(IDC_RICHEDITCTRL);
Likewise, the usage of SetUnicodeString above is shown below. Specify the ID of the RichEditCtrl control, and the Unicode string to be set to the control.
SetUnicodeString(IDC_RICHEDITCTRL,str);
Unicode and RichEditCtrl
Unicode Strings in MFC
The easiest way to deal with Unicode strings is to use CStringW class. As it is, CStringW can edit Unicode strings. Another option is to use char* equivalent wide-byte type in MFC called LPWSTR.
Writing and reading Unicode strings to and from controls in MFC is not exactly as straight forward. GetDlgItemText and SetDlgItemText only take single byte character strings. This page explains how to send messages to set and retrieve Unicode strings to the controls without the use of those functions.
Take a look at the following functions. Those functions read and write Unicode strings from and to MFC controls (RichEditCtrl). Sending messages requires several steps. First is to specify the type of the message. The type of the message, the codepage, and other optional settings are set to a structure called GETTEXTEX and SETTEXTEX. Then calculate and prepare space to store the results.
LPWSTR GetUnicodeString(UINT id)
{
CRichEditCtrl* edit=(CRichEditCtrl*)GetDlgItem(id);
int nLength = edit->GetTextLengthEx(GTL_DEFAULT,1200);
LPWSTR lpszWChar = new WCHAR[nLength+1];
GETTEXTEX getTextEx;
getTextEx.cb=(nLength+1)*sizeof(WCHAR);
getTextEx.codepage=1200;
getTextEx.flags=GT_DEFAULT;
getTextEx.lpDefaultChar=NULL;
getTextEx.lpUsedDefChar=NULL;
edit->SendMessage(EM_GETTEXTEX, (WPARAM)&getTextEx, (LPARAM)lpszWChar);
return lpszWChar;
}
void SetUnicodeString(UINT id, LPWSTR str)
{
SETTEXTEX setTextEx;
setTextEx.codepage=1200;
setTextEx.flags=ST_DEFAULT;
CRichEditCtrl *caption=(CRichEditCtrl*)GetDlgItem(id);
if(caption!=NULL)
caption->SendMessage(EM_SETTEXTEX, (WPARAM)&setTextEx, (LPARAM)str);
}
The usage of GetUnicodeString above is shown below. Specify the ID of the RichEditCtrl control.
CStringW str=GetUnicodeString(IDC_RICHEDITCTRL);
Likewise, the usage of SetUnicodeString above is shown below. Specify the ID of the RichEditCtrl control, and the Unicode string to be set to the control.
SetUnicodeString(IDC_RICHEDITCTRL,str);
Friday, December 19, 2008
Visual Studio 2005 SP1
From Microsoft Download Center
Visual Studio® 2005 Team Suite SP1
Visual C++ 2005 SP1 Redistributable Package (x86)
Visual Studio 2005 Service Pack 1 GDIPLUS.DLL Security Update
Integrate VS 2005 & SP1:
[HowTo]整合Visual Studio 2005與Service Pack 1
Visual Studio® 2005 Team Suite SP1
Visual C++ 2005 SP1 Redistributable Package (x86)
Visual Studio 2005 Service Pack 1 GDIPLUS.DLL Security Update
Integrate VS 2005 & SP1:
[HowTo]整合Visual Studio 2005與Service Pack 1
Monday, December 15, 2008
C Restrict Pointers
[Source]
One of the new features in the recently approved C standard C99, is the restrict pointer qualifier. This qualifier can be applied to a data pointer to indicate that, during the scope of that pointer declaration, all data accessed through it will be accessed only through that pointer but not through any other pointer. The 'restrict' keyword thus enables the compiler to perform certain optimizations based on the premise that a given object cannot be changed through another pointer. Now you're probably asking yourself, "doesn't const already guarantee that?" No, it doesn't. The qualifier const ensures that a variable cannot be changed through a particular pointer. However, it's still possible to change the variable through a different pointer. For example:
void f (const int* pci, int *pi;); // is *pci immutable?
{
(*pi)+=1; // not necessarily: n is incremented by 1
*pi = (*pci) + 2; // n is incremented by 2
}
int n;
f( &n, &n);
In this example, both pci and pi point to the same variable, n. You can't change n's value through pci but you can change it using pi. Therefore, the compiler isn't allowed to optimize memory access for *pci by preloading n's value. In this example, the compiler indeed shouldn't preload n because its value changes three times during the execution of f(). However, there are situations in which a variable is accessed only through a single pointer. For example:
FILE *fopen(const char * filename, const char * mode);
The name of the file and its open mode are accessed through unique pointers in fopen(). Therefore, it's possible to preload the values to which the pointers are bound. Indeed, the C99 standard revised the prototype of the function fopen() to the following:
/* new declaration of fopen() in */
FILE *fopen(const char * restrict filename,
const char * restrict mode);
Similar changes were applied to the entire standard C library: printf(), strcpy() and many other functions now take restrict pointers:
int printf(const char * restrict format, ...);
char *strcpy(char * restrict s1, const char * restrict s2);
C++ doesn't support restrict yet. However, since many C++ compilers are also C compilers, it's likely that this feature will be added to most C++ compilers too.
Danny Kalev
One of the new features in the recently approved C standard C99, is the restrict pointer qualifier. This qualifier can be applied to a data pointer to indicate that, during the scope of that pointer declaration, all data accessed through it will be accessed only through that pointer but not through any other pointer. The 'restrict' keyword thus enables the compiler to perform certain optimizations based on the premise that a given object cannot be changed through another pointer. Now you're probably asking yourself, "doesn't const already guarantee that?" No, it doesn't. The qualifier const ensures that a variable cannot be changed through a particular pointer. However, it's still possible to change the variable through a different pointer. For example:
void f (const int* pci, int *pi;); // is *pci immutable?
{
(*pi)+=1; // not necessarily: n is incremented by 1
*pi = (*pci) + 2; // n is incremented by 2
}
int n;
f( &n, &n);
In this example, both pci and pi point to the same variable, n. You can't change n's value through pci but you can change it using pi. Therefore, the compiler isn't allowed to optimize memory access for *pci by preloading n's value. In this example, the compiler indeed shouldn't preload n because its value changes three times during the execution of f(). However, there are situations in which a variable is accessed only through a single pointer. For example:
FILE *fopen(const char * filename, const char * mode);
The name of the file and its open mode are accessed through unique pointers in fopen(). Therefore, it's possible to preload the values to which the pointers are bound. Indeed, the C99 standard revised the prototype of the function fopen() to the following:
/* new declaration of fopen() in
FILE *fopen(const char * restrict filename,
const char * restrict mode);
Similar changes were applied to the entire standard C library: printf(), strcpy() and many other functions now take restrict pointers:
int printf(const char * restrict format, ...);
char *strcpy(char * restrict s1, const char * restrict s2);
C++ doesn't support restrict yet. However, since many C++ compilers are also C compilers, it's likely that this feature will be added to most C++ compilers too.
Danny Kalev
Friday, December 05, 2008
WinXP FAT32 與 NTFS 之間的轉換
[FAT32 -> NTFS]
保留資料
1) > convert D:/FS:NTFS /V
2) Partition Magic
不保留資料
> format D:/FS:NTFS
[NTFS -> FAT32]
保留資料
Partition Magic
不保留資料
> format D:/FS:FAT32
保留資料
1) > convert D:/FS:NTFS /V
2) Partition Magic
不保留資料
> format D:/FS:NTFS
[NTFS -> FAT32]
保留資料
Partition Magic
不保留資料
> format D:/FS:FAT32
Wednesday, December 03, 2008
POSIX Threads Programming
https://computing.llnl.gov/tutorials/pthreads/
Books:
- Programming with POSIX Threads
- Multithreading Programming Techniques
- Getting Started With POSIX Threads
Books:
- Programming with POSIX Threads
- Multithreading Programming Techniques
- Getting Started With POSIX Threads
Saturday, July 05, 2008
Set Environment Variables for VC
If we install more than 1 version of VC compilers, it's better to set environment variable to the version that we'd like to use for compiling programs under command mode (e.g. use nmake with makefile):
VC6:
$(VS_Path)\VC98\Bin\vcvars32.bat
VC7 (2003) / VC8 (2005) / VC9 (2008):
$(VS_Path)\Common7\Tools\vsvars32.bat
VC6:
$(VS_Path)\VC98\Bin\vcvars32.bat
VC7 (2003) / VC8 (2005) / VC9 (2008):
$(VS_Path)\Common7\Tools\vsvars32.bat
Sunday, March 02, 2008
精通 vi - Chap 3 快速移動位置
1. 移動
往下捲動一個螢幕 ^F
往上捲動一個螢幕 ^B
往下捲動半個螢幕 ^D
往上捲動半個螢幕 ^U
往下捲動一行 ^E
往上捲動一行 ^Y
將本行移到螢幕頂端 z [Enter]
將本行移到螢幕中間 z.
將本行移到螢幕最後 z-
移到螢幕頂端 H
移到螢幕中間 M
移到螢幕最後 L
移到下一行首 + 或 [Enter]
移到上一行首 -
移到句子開頭 (
移到下一句子開頭 )
移到段落開頭 {
移到下一段落開頭 }
到第 n 行 nG
到最後一行 G
2. 搜尋
向下找 /pattern
向上找 ?pattern
同一方向重複找 n
相反方向重複找 N
重複上一搜尋命令，方向相同 ;
重複上一搜尋命令，方向相反 ,
3. 其它
估計目前所在位置的百分比 ^G
往下捲動一個螢幕 ^F
往上捲動一個螢幕 ^B
往下捲動半個螢幕 ^D
往上捲動半個螢幕 ^U
往下捲動一行 ^E
往上捲動一行 ^Y
將本行移到螢幕頂端 z [Enter]
將本行移到螢幕中間 z.
將本行移到螢幕最後 z-
移到螢幕頂端 H
移到螢幕中間 M
移到螢幕最後 L
移到下一行首 + 或 [Enter]
移到上一行首 -
移到句子開頭 (
移到下一句子開頭 )
移到段落開頭 {
移到下一段落開頭 }
到第 n 行 nG
到最後一行 G
2. 搜尋
向下找 /pattern
向上找 ?pattern
同一方向重複找 n
相反方向重複找 N
重複上一搜尋命令，方向相同 ;
重複上一搜尋命令，方向相反 ,
3. 其它
估計目前所在位置的百分比 ^G
精通 vi - Chap 2 簡單的文字編輯
1. 編輯命令
文字物件 更改 刪除 複製
一個單字 cw dw yw
兩個單字，不含標點 2cW 2dW 2yW
往回三個單字 3cb 3db 3yb
一整行 cc dd yy
到一行末 c$ d$ y$
到一行首 c0 d0 y0
單一字元 r x y1
五個字元 5s 5x 5y1
貼上 p 或 P
2. 游標移動
左下上右 h, j, k, l
到下一行首 +
到上一行首 -
到單字結尾 e
往後一個單字 w
往前一個單字 b
到本行末 $
到本行首 0
3. 建立與處理文字
在游標所在位置插入文字 i
在行首插入文字 I
在游標所在位置附加文字 a
在行尾附加文字 A
在游標下一行開啟新行 o
在游標上一行開啟新行 O
刪除一行並代換文字 S
用新文字覆蓋現存的文字 R
合併此行與下一行 J
切換大小寫 ~
重複上一動作 .
還原上一動作 u
還原一整行的編輯 U
文字物件 更改 刪除 複製
一個單字 cw dw yw
兩個單字，不含標點 2cW 2dW 2yW
往回三個單字 3cb 3db 3yb
一整行 cc dd yy
到一行末 c$ d$ y$
到一行首 c0 d0 y0
單一字元 r x y1
五個字元 5s 5x 5y1
貼上 p 或 P
2. 游標移動
左下上右 h, j, k, l
到下一行首 +
到上一行首 -
到單字結尾 e
往後一個單字 w
往前一個單字 b
到本行末 $
到本行首 0
3. 建立與處理文字
在游標所在位置插入文字 i
在行首插入文字 I
在游標所在位置附加文字 a
在行尾附加文字 A
在游標下一行開啟新行 o
在游標上一行開啟新行 O
刪除一行並代換文字 S
用新文字覆蓋現存的文字 R
合併此行與下一行 J
切換大小寫 ~
重複上一動作 .
還原上一動作 u
還原一整行的編輯 U
精通 vi - Chap 1 vi 文字編輯器
開檔
> vi [filename]
儲存
:w
:w [new filename] (另存新檔)
:w! (強迫寫入)
:w! [filename] (強迫寫入或蓋掉另一檔案)
結束並儲存
ZZ
消除編輯結果，回到原檔案
:e!
結束但不儲存
:q!
> vi [filename]
儲存
:w
:w [new filename] (另存新檔)
:w! (強迫寫入)
:w! [filename] (強迫寫入或蓋掉另一檔案)
結束並儲存
ZZ
消除編輯結果，回到原檔案
:e!
結束但不儲存
:q!
Thursday, February 21, 2008
INIT: Id "co" respawning too fast: disabled for 5 minutes
Solve the problem, or disable it in /etc/inittab.
ADSL on Linux
1) Prepare your ISP login name and password.
2) Setup the rpm of PPPOE if it's necessary.
3) Setup configuration.
> adsl-setup
4) To start ADSL:
> /sbin/ifup ppp0
5) To stop ADSL:
> /sbin/ifdown ppp0
2) Setup the rpm of PPPOE if it's necessary.
3) Setup configuration.
> adsl-setup
4) To start ADSL:
> /sbin/ifup ppp0
5) To stop ADSL:
> /sbin/ifdown ppp0
Saturday, August 11, 2007
CVS Server How-To
http://www.xfocus.net/articles/200112/314.html
http://greenisland.csie.nctu.edu.tw/wp/2005/06/16/26/
1. Install CVS
2. vi /etc/services
should have these two lines:
cvspserver 2401/tcp # cvs client/server operations
cvspserver 2401/udp # cvs client/server operations
3. Add group and user
> groupadd cvs
> adduser cvsroot
> passwd cvsroot
4. Change permission of /home/cvsroot
> chown cvsroot.cvs /home/cvsroot
> chmod 755 /home/cvsroot
5. xinetd settings
> cd /etc/xinetd.d
> vi cvspserver
service cvspserver
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/bin/cvs
server_args = --allow-root=/home/cvsroot pserver
log_on_failure += USERID
}
6. Initialize CVS repository
> cvs -d /home/cvsroot init
7. Restart xinetd
> /etc/init.d/xinetd restart
8. That's all. Now we can login to CVS.
> cvs -d :pserver:cvsroot@localhost:/home/cvsroot login
http://greenisland.csie.nctu.edu.tw/wp/2005/06/16/26/
1. Install CVS
2. vi /etc/services
should have these two lines:
cvspserver 2401/tcp # cvs client/server operations
cvspserver 2401/udp # cvs client/server operations
3. Add group and user
> groupadd cvs
> adduser cvsroot
> passwd cvsroot
4. Change permission of /home/cvsroot
> chown cvsroot.cvs /home/cvsroot
> chmod 755 /home/cvsroot
5. xinetd settings
> cd /etc/xinetd.d
> vi cvspserver
service cvspserver
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/bin/cvs
server_args = --allow-root=/home/cvsroot pserver
log_on_failure += USERID
}
6. Initialize CVS repository
> cvs -d /home/cvsroot init
7. Restart xinetd
> /etc/init.d/xinetd restart
8. That's all. Now we can login to CVS.
> cvs -d :pserver:cvsroot@localhost:/home/cvsroot login
Saturday, May 19, 2007
Subscribe to:
Posts (Atom)