Pragma once - 維基百科，自由的百科全書

Pragma once - 維基百科，自由的百科全書

Pragma once

維基百科，自由的百科全書

跳轉到: 導航, 搜尋

在 C 和 C++ 程式語言中，#pragma once 是一個非標準但是被廣泛支援的前置處理符號，會讓所在的檔案在一個單獨的編譯中被include防範一次。以此方式，#pragma once 提供類似include防範的目的，但是擁有較少的程式碼且能避免名稱的碰撞。
請參考include防範裡其中一種狀況的範例或其他的使用方法。如下：

檔案「grandfather.h」

#pragma once

struct foo {
int member;
};

檔案「father.h」

#include "grandfather.h"

檔案「child.c」

#include "grandfather.h"
#include "father.h"

[編輯] 優缺點

使用#pragma once 代替 include 防範將加快編譯速度，因為這是一種高階的機制；編譯器會自動比對檔案名稱或inode而不需要在標頭檔去判斷 #ifndef 和 #endif。
另一方面，部份編譯器，例如GCC，也包含特別的程式碼來識別和有效率的管理 include 防範。[1]
此外，因為編譯器自己必須承擔管理 #pragma once，它不必定義新的指令名稱，例如在 include防範文章範例的 H_GRANDFATHER。這能排除名稱碰撞的風險，意思就是包含一個以上相同的標頭檔不會再有錯誤。
然而，這種高階的管理有好也有壞；設計者必須依賴編譯器正確的管理 #pragma once。編譯器如果犯錯，例如沒有辨認出在相同檔案中的兩個不同符號連結名稱指標，此時編譯會錯誤。編譯器對於 #pragma once 可能包含相關的臭蟲 LCC-Win32 2004年 [2][3] 和 GCC 1998年。[4] 2005年，GCC 文件中將 #pragma once 列為「已淘汰」的特性。[5]

[編輯] 外部連結

• http://msdn.microsoft.com/library/en-us/vclang/html/_predir_pragma_directives.asp

取自"http://zh.wikipedia.org/zh-tw/Pragma_once"

2個分類: C語言 | C++

Include防範 - 維基百科，自由的百科全書

Include防範 - 維基百科，自由的百科全書

Include防範

維基百科，自由的百科全書

跳轉到: 導航, 搜尋

在 C 和 C++ 程式語言中，#include 防範，有時被稱作巨集防範，用於處理 #include 指令時，可避免重複引入的問題。在標頭檔加入 #include 防範是一種讓檔案等冪的方法。

目錄 [隱藏] 1 重複引入 2 使用 #include 防範 3 困難 4 外部連結

[編輯] 重複引入

以下的C語言程式展示了缺少 #include 防範時會出現的問題：

檔案「grandfather.h」

struct foo {
int member;
};

檔案「father.h」

#include "grandfather.h"

檔案「child.c」

#include "grandfather.h"
#include "father.h"

此處 child.c間接引入了兩份grandfather.h標頭檔中的內容。明顯可以看出， foo 結構被定義兩次，因此會造成編譯錯誤。

[編輯] 使用 #include 防範

檔案「grandfather.h」

#ifndef H_GRANDFATHER
#define H_GRANDFATHER

struct foo {
int member;
};

#endif

檔案「father.h」

#include "grandfather.h"

檔案「child.c」

#include "grandfather.h"
#include "father.h"

此處grandfather.h第一次被引入時會定義巨集H_GRANDFATHER。當child.h再次引入grandfather.h時，#ifndef測試失敗，編譯器會直接跳到#endif的部分，也避免了第二次定義foo結構。程式也就能夠正常編譯。

[編輯] 困難

為了讓#include 防範正確運作，每個防範都必須檢驗並且有條件地設定不同的前置處理巨集。因此，使用了 #include 防範的方案必須制訂一致性的命名方法，並確定這個方法不會和其他的標頭檔或任何可見的全域變數衝突。
為了解決這個問題，許多 C 和 C++ 程式開發工具提供非標準的指令 #pragma once。在標頭檔中加入這個指令，能夠保證這個檔案只會被引入一次。不過這個方法會被潛在性顯著的困難阻撓，無論 #include 指令是否在不同的地方，但實際上起源於相同的開頭（舉例，請參考 符號連結）。同樣的，因為 #pragma once 不是一個標準的指令，它的語意在不同的程式開發工具中也許會有微妙的不同。

[編輯] 外部連結

• 引入防範的最佳化
• 多餘的引入防範
• 引入防範生成器

取自"http://zh.wikipedia.org/zh-tw/Include%E9%98%B2%E7%AF%84"

1個分類: C語言

Stickies

Stickies
類似ATnotes，不過仍在開發，且有中文化。

Link Options - Using the GNU Compiler Collection (GCC)

Link Options - Using the GNU Compiler Collection (GCC)

3.13 Options for Linking

These options come into play when the compiler links object files into an executable output file. They are meaningless if the compiler is not doing a link step.

object-file-name

A file name that does not end in a special recognized suffix is considered to name an object file or library. (Object files are distinguished from libraries by the linker according to the file contents.) If linking is done, these object files are used as input to the linker.

-c

-S

-E

If any of these options is used, then the linker is not run, and object file names should not be used as arguments. See Overall Options.

-llibrary

-l library

Search the library named library when linking. (The second alternative with the library as a separate argument is only for POSIX compliance and is not recommended.)

It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus, `foo.o -lz bar.o' searches library `z' after file foo.o but before bar.o. If bar.o refers to functions in `z', those functions may not be loaded.

The linker searches a standard list of directories for the library, which is actually a file named liblibrary.a. The linker then uses this file as if it had been specified precisely by name.

The directories searched include several standard system directories plus any that you specify with -L.

Normally the files found this way are library files—archive files whose members are object files. The linker handles an archive file by scanning through it for members which define symbols that have so far been referenced but not defined. But if the file that is found is an ordinary object file, it is linked in the usual fashion. The only difference between using an -l option and specifying a file name is that -l surrounds library with `lib' and `.a' and searches several directories.

-lobjc

You need this special case of the -l option in order to link an Objective-C or Objective-C++ program.

-nostartfiles

Do not use the standard system startup files when linking. The standard system libraries are used normally, unless -nostdlib or -nodefaultlibs is used.

-nodefaultlibs

Do not use the standard system libraries when linking. Only the libraries you specify will be passed to the linker, options specifying linkage of the system libraries, such as -static-libgcc or -shared-libgcc, will be ignored. The standard startup files are used normally, unless -nostartfiles is used. The compiler may generate calls to memcmp, memset, memcpy and memmove. These entries are usually resolved by entries in libc. These entry points should be supplied through some other mechanism when this option is specified.

-nostdlib

Do not use the standard system startup files or libraries when linking. No startup files and only the libraries you specify will be passed to the linker, options specifying linkage of the system libraries, such as -static-libgcc or -shared-libgcc, will be ignored. The compiler may generate calls to memcmp, memset, memcpy and memmove. These entries are usually resolved by entries in libc. These entry points should be supplied through some other mechanism when this option is specified. One of the standard libraries bypassed by -nostdlib and -nodefaultlibs is libgcc.a, a library of internal subroutines that GCC uses to overcome shortcomings of particular machines, or special needs for some languages. (See Interfacing to GCC Output, for more discussion of libgcc.a.) In most cases, you need libgcc.a even when you want to avoid other standard libraries. In other words, when you specify -nostdlib or -nodefaultlibs you should usually specify -lgcc as well. This ensures that you have no unresolved references to internal GCC library subroutines. (For example, `__main', used to ensure C++ constructors will be called; see collect2.)

-pie

Produce a position independent executable on targets which support it. For predictable results, you must also specify the same set of options that were used to generate code (-fpie, -fPIE, or model suboptions) when you specify this option.

-rdynamic

Pass the flag -export-dynamic to the ELF linker, on targets that support it. This instructs the linker to add all symbols, not only used ones, to the dynamic symbol table. This option is needed for some uses of dlopen or to allow obtaining backtraces from within a program.

-s

Remove all symbol table and relocation information from the executable.

-static

On systems that support dynamic linking, this prevents linking with the shared libraries. On other systems, this option has no effect.

-shared

Produce a shared object which can then be linked with other objects to form an executable. Not all systems support this option. For predictable results, you must also specify the same set of options that were used to generate code (-fpic, -fPIC, or model suboptions) when you specify this option.¹

-shared-libgcc

-static-libgcc

On systems that provide libgcc as a shared library, these options force the use of either the shared or static version respectively. If no shared version of libgcc was built when the compiler was configured, these options have no effect. There are several situations in which an application should use the shared libgcc instead of the static version. The most common of these is when the application wishes to throw and catch exceptions across different shared libraries. In that case, each of the libraries as well as the application itself should use the shared libgcc. Therefore, the G++ and GCJ drivers automatically add -shared-libgcc whenever you build a shared library or a main executable, because C++ and Java programs typically use exceptions, so this is the right thing to do. If, instead, you use the GCC driver to create shared libraries, you may find that they will not always be linked with the shared libgcc. If GCC finds, at its configuration time, that you have a non-GNU linker or a GNU linker that does not support option --eh-frame-hdr, it will link the shared version of libgcc into shared libraries by default. Otherwise, it will take advantage of the linker and optimize away the linking with the shared version of libgcc, linking with the static version of libgcc by default. This allows exceptions to propagate through such shared libraries, without incurring relocation costs at library load time. However, if a library or main executable is supposed to throw or catch exceptions, you must link it using the G++ or GCJ driver, as appropriate for the languages used in the program, or using the option -shared-libgcc, such that it is linked with the shared libgcc.

-static-libstdc++

When the g++ program is used to link a C++ program, it will normally automatically link against libstdc++. If libstdc++ is available as a shared library, and the -static option is not used, then this will link against the shared version of libstdc++. That is normally fine. However, it is sometimes useful to freeze the version of libstdc++ used by the program without going all the way to a fully static link. The -static-libstdc++ option directs the g++ driver to link libstdc++ statically, without necessarily linking other libraries statically.

-symbolic

Bind references to global symbols when building a shared object. Warn about any unresolved references (unless overridden by the link editor option `-Xlinker -z -Xlinker defs'). Only a few systems support this option.

-T script

Use script as the linker script. This option is supported by most systems using the GNU linker. On some targets, such as bare-board targets without an operating system, the -T option may be required when linking to avoid references to undefined symbols.

-Xlinker option

Pass option as an option to the linker. You can use this to supply system-specific linker options which GCC does not know how to recognize. If you want to pass an option that takes a separate argument, you must use -Xlinker twice, once for the option and once for the argument. For example, to pass -assert definitions, you must write `-Xlinker -assert -Xlinker definitions'. It does not work to write -Xlinker "-assert definitions", because this passes the entire string as a single argument, which is not what the linker expects. When using the GNU linker, it is usually more convenient to pass arguments to linker options using the option=value syntax than as separate arguments. For example, you can specify `-Xlinker -Map=output.map' rather than `-Xlinker -Map -Xlinker output.map'. Other linkers may not support this syntax for command-line options.

-Wl,option

Pass option as an option to the linker. If option contains commas, it is split into multiple options at the commas. You can use this syntax to pass an argument to the option. For example, `-Wl,-Map,output.map' passes `-Map output.map' to the linker. When using the GNU linker, you can also get the same effect with `-Wl,-Map=output.map'.

-u symbol

Pretend the symbol symbol is undefined, to force linking of library modules to define it. You can use -u multiple times with different symbols to force loading of additional library modules.

---

Footnotes

[1] On some systems, `gcc -shared' needs to build supplementary stub code for constructors to work. On multi-libbed systems, `gcc -shared' must select the correct support libraries to link against. Failing to supply the correct flags may lead to subtle defects. Supplying them in cases where they are not necessary is innocuous.