Mar 31, 2015 This will clear your basic idea how to create c program if you are new in OS X environment. Specially if you are in School or college and never used your MAC for programming. Learn C which is very. You have three options for writing Mac GUI applications in C. First, you can use Cocoa, writing your user interface code in Objective C and the rest of your code in C. You must give your Objective C files the extension.mm, which tells Xcode to treat them as Objective C files. MacOS doesn't support touch screens, so it is only available on a laptop or desktop. The Mac has a connected relationship with the iPhone and the iPad. Not only can the Mac share files with the iPhone or iPad wirelessly using AirDrop, or iCloud, it can also open documents that are open on the iPhone or iPad and receive phone calls routed.
- Climate For Mac Os C Lion
- Cmake For Osx
- Climate For Mac Os C Compiler
- Climate For Mac Os C ++ Ide
- Cmake Objective C++
Specify rules to run at install time.
Introduction¶
This command generates installation rules for a project. Install rulesspecified by calls to the
install()
command within a source directoryare executed in order during installation. Install rules in subdirectoriesadded by calls to the add_subdirectory()
command are interleavedwith those in the parent directory to run in the order declared (seepolicy CMP0082
).There are multiple signatures for this command. Some of them defineinstallation options for files and targets. Options common tomultiple signatures are covered here but they are valid only forsignatures that specify them. The common options are:
DESTINATION
Specify the directory on disk to which a file will be installed.Arguments can be relative or absolute paths.
If a relative path is given it is interpreted relative to the valueof the
CMAKE_INSTALL_PREFIX
variable.The prefix can be relocated at install time using the DESTDIR
mechanism explained in the CMAKE_INSTALL_PREFIX
variabledocumentation.If an absolute path (with a leading slash or drive letter) is givenit is used verbatim.
![Climate for mac os c ++ ide Climate for mac os c ++ ide](/uploads/1/2/6/6/126614590/490417069.png)
As absolute paths are not supported by
cpack
installergenerators, it is preferable to use relative paths throughout.PERMISSIONS
Specify permissions for installed files. Valid permissions are
OWNER_READ
, OWNER_WRITE
, OWNER_EXECUTE
, GROUP_READ
,GROUP_WRITE
, GROUP_EXECUTE
, WORLD_READ
, WORLD_WRITE
,WORLD_EXECUTE
, SETUID
, and SETGID
. Permissions that donot make sense on certain platforms are ignored on those platforms.CONFIGURATIONS
Specify a list of build configurations for which the install ruleapplies (Debug, Release, etc.). Note that the values specified forthis option only apply to options listed AFTER the
CONFIGURATIONS
option. For example, to set separate install paths for the Debug andRelease configurations, do the following:Note that
CONFIGURATIONS
appears BEFORE RUNTIMEDESTINATION
.COMPONENT
Specify an installation component name with which the install ruleis associated, such as “runtime” or “development”. Duringcomponent-specific installation only install rules associated withthe given component name will be executed. During a full installationall components are installed unless marked with
EXCLUDE_FROM_ALL
.If COMPONENT
is not provided a default component “Unspecified” iscreated. The default component name may be controlled with theCMAKE_INSTALL_DEFAULT_COMPONENT_NAME
variable.EXCLUDE_FROM_ALL
Specify that the file is excluded from a full installation and onlyinstalled as part of a component-specific installation
RENAME
Specify a name for an installed file that may be different from theoriginal file. Renaming is allowed only when a single file isinstalled by the command.
OPTIONAL
Specify that it is not an error if the file to be installed doesnot exist.
Command signatures that install files may print messages duringinstallation. Use the
CMAKE_INSTALL_MESSAGE
variableto control which messages are printed.Many of the
install()
variants implicitly create the directoriescontaining the installed files. IfCMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS
is set, thesedirectories will be created with the permissions specified. Otherwise,they will be created according to the uname rules on Unix-like platforms.Windows platforms are unaffected.Installing Targets¶
The
TARGETS
form specifies rules for installing targets from aproject. There are several kinds of target Output Artifactsthat may be installed:ARCHIVE
Target artifacts of this kind include:
- Static libraries(except on macOS when marked as
FRAMEWORK
, see below); - DLL import libraries(on all Windows-based systems including Cygwin; they have extension
.lib
, in contrast to the.dll
libraries that go toRUNTIME
); - On AIX, the linker import file created for executables with
ENABLE_EXPORTS
enabled.
LIBRARY
Target artifacts of this kind include:
- Shared libraries, except
- DLLs (these go to
RUNTIME
, see below), - on macOS when marked as
FRAMEWORK
(see below).
RUNTIME
Target artifacts of this kind include:
- Executables(except on macOS when marked as
MACOSX_BUNDLE
, seeBUNDLE
below); - DLLs (on all Windows-based systems including Cygwin; note that theaccompanying import libraries are of kind
ARCHIVE
).
OBJECTS
Object files associated with object libraries.
FRAMEWORK
Both static and shared libraries marked with the
FRAMEWORK
property are treated as FRAMEWORK
targets on macOS.BUNDLE
Executables marked with the
MACOSX_BUNDLE
property are treated asBUNDLE
targets on macOS.PUBLIC_HEADER
Any
PUBLIC_HEADER
files associated with a library are installed inthe destination specified by the PUBLIC_HEADER
argument on non-Appleplatforms. Rules defined by this argument are ignored for FRAMEWORK
libraries on Apple platforms because the associated files are installedinto the appropriate locations inside the framework folder. SeePUBLIC_HEADER
for details.PRIVATE_HEADER
Similar to
PUBLIC_HEADER
, but for PRIVATE_HEADER
files. SeePRIVATE_HEADER
for details.RESOURCE
Similar to
PUBLIC_HEADER
and PRIVATE_HEADER
, but forRESOURCE
files. See RESOURCE
for details.For each of these arguments given, the arguments following them only applyto the target or file type specified in the argument. If none is given, theinstallation properties apply to all target types. If only one is given thenonly targets of that type will be installed (which can be used to installjust a DLL or just an import library.)
For regular executables, static libraries and shared libraries, the
DESTINATION
argument is not required. For these target types, whenDESTINATION
is omitted, a default destination will be taken from theappropriate variable from GNUInstallDirs
, or set to a built-indefault value if that variable is not defined. The same is true for thepublic and private headers associated with the installed targets through thePUBLIC_HEADER
and PRIVATE_HEADER
target properties.A destination must always be provided for module libraries, Apple bundles andframeworks. A destination can be omitted for interface and object libraries,but they are handled differently (see the discussion of this topic toward theend of this section).The following table shows the target types with their associated variables andbuilt-in defaults that apply when no destination is given:
Target Type | GNUInstallDirs Variable | Built-In Default |
---|---|---|
RUNTIME | ${CMAKE_INSTALL_BINDIR} | bin |
LIBRARY | ${CMAKE_INSTALL_LIBDIR} | lib |
ARCHIVE | ${CMAKE_INSTALL_LIBDIR} | lib |
PRIVATE_HEADER | ${CMAKE_INSTALL_INCLUDEDIR} | include |
PUBLIC_HEADER | Power photos for el capitan free. ${CMAKE_INSTALL_INCLUDEDIR} | include |
Projects wishing to follow the common practice of installing headers into aproject-specific subdirectory will need to provide a destination rather thanrely on the above.
To make packages compliant with distribution filesystem layout policies, ifprojects must specify a
DESTINATION
, it is recommended that they use apath that begins with the appropriate GNUInstallDirs
variable.This allows package maintainers to control the install destination by settingthe appropriate cache variables. The following example shows a static librarybeing installed to the default destination provided byGNUInstallDirs
, but with its headers installed to a project-specificsubdirectory that follows the above recommendation:In addition to the common options listed above, each target can acceptthe following additional arguments:
NAMELINK_COMPONENT
On some platforms a versioned shared library has a symbolic link suchas:
where
lib<name>.so.1
is the soname of the library and lib<name>.so
is a “namelink” allowing linkers to find the library when given-l<name>
. The NAMELINK_COMPONENT
option is similar to theCOMPONENT
option, but it changes the installation component of a sharedlibrary namelink if one is generated. If not specified, this defaults to thevalue of COMPONENT
. It is an error to use this parameter outside of aLIBRARY
block.Consider the following example:
In this scenario, if you choose to install only the
Development
component, both the headers and namelink will be installed without thelibrary. (If you don’t also install the Libraries
component, thenamelink will be a dangling symlink, and projects that link to the librarywill have build errors.) If you install only the Libraries
component,only the library will be installed, without the headers and namelink.This option is typically used for package managers that have separateruntime and development packages. For example, on Debian systems, thelibrary is expected to be in the runtime package, and the headers andnamelink are expected to be in the development package.
See the
VERSION
and SOVERSION
target properties fordetails on creating versioned shared libraries.NAMELINK_ONLY
This option causes the installation of only the namelink when a librarytarget is installed. On platforms where versioned shared libraries do nothave namelinks or when a library is not versioned, the
NAMELINK_ONLY
option installs nothing. It is an error to use this parameter outside of aLIBRARY
block.When
NAMELINK_ONLY
is given, either NAMELINK_COMPONENT
orCOMPONENT
may be used to specify the installation component of thenamelink, but COMPONENT
should generally be preferred.NAMELINK_SKIP
Similar to
NAMELINK_ONLY
, but it has the opposite effect: it causes theinstallation of library files other than the namelink when a library targetis installed. When neither NAMELINK_ONLY
or NAMELINK_SKIP
are given,both portions are installed. On platforms where versioned shared librariesdo not have symlinks or when a library is not versioned, NAMELINK_SKIP
installs the library. It is an error to use this parameter outside of aLIBRARY
Vlc library mac. block.If
NAMELINK_SKIP
is specified, NAMELINK_COMPONENT
has no effect. Itis not recommended to use NAMELINK_SKIP
in conjunction withNAMELINK_COMPONENT
.The install(TARGETS) command can also accept the following options at thetop level:
EXPORT
This option associates the installed target files with an export called
<export-name>
. It must appear before any target options. To actuallyinstall the export file itself, call install(EXPORT), documented below.See documentation of the EXPORT_NAME
target property to changethe name of the exported target.INCLUDESDESTINATION
This option specifies a list of directories which will be added to the
INTERFACE_INCLUDE_DIRECTORIES
target property of the<targets>
when exported by the install(EXPORT) command. If arelative path is specified, it is treated as relative to the$<INSTALL_PREFIX>
.One or more groups of properties may be specified in a single call tothe
TARGETS
form of this command. A target may be installed more thanonce to different locations. Consider hypothetical targets myExe
,mySharedLib
, and myStaticLib
. The code:will install
myExe
to <prefix>/bin
and myStaticLib
to<prefix>/lib/static
. On non-DLL platforms mySharedLib
will beinstalled to <prefix>/lib
and /some/full/path
. On DLL platformsthe mySharedLib
DLL will be installed to <prefix>/bin
and/some/full/path
and its import library will be installed to<prefix>/lib/static
and /some/full/path
.Interface Libraries may be listed among the targets to install.They install no artifacts but will be included in an associated
EXPORT
.If Object Libraries are listed but given no destination for theirobject files, they will be exported as Interface Libraries.This is sufficient to satisfy transitive usage requirements of othertargets that link to the object libraries in their implementation.Installing a target with the
EXCLUDE_FROM_ALL
target propertyset to TRUE
has undefined behavior.install(TARGETS) can install targets that were created inother directories. When using such cross-directory install rules, running
makeinstall
(or similar) from a subdirectory will not guarantee thattargets from other directories are up-to-date. You can usetarget_link_libraries()
or add_dependencies()
to ensure that such out-of-directory targets are built before thesubdirectory-specific install rules are run.https://qrheavy.weebly.com/teamviewer-for-mac-catalina.html. An install destination given as a
DESTINATION
argument mayuse “generator expressions” with the syntax $<.>
. See thecmake-generator-expressions(7)
manual for available expressions.Installing Files¶
The
FILES
form specifies rules for installing files for a project.File names given as relative paths are interpreted with respect to thecurrent source directory. Files installed by this form are by defaultgiven permissions OWNER_WRITE
, OWNER_READ
, GROUP_READ
, andWORLD_READ
if no PERMISSIONS
argument is given.The
PROGRAMS
form is identical to the FILES
form except that thedefault permissions for the installed file also include OWNER_EXECUTE
,GROUP_EXECUTE
, and WORLD_EXECUTE
. This form is intended to installprograms that are not targets, such as shell scripts. Use the TARGETS
form to install targets built within the project.The list of
files.
given to FILES
or PROGRAMS
may use“generator expressions” with the syntax $<.>
. See thecmake-generator-expressions(7)
manual for available expressions.However, if any item begins in a generator expression it must evaluateto a full path.Either a
TYPE
or a DESTINATION
must be provided, but not both.A TYPE
argument specifies the generic file type of the files beinginstalled. A destination will then be set automatically by taking thecorresponding variable from GNUInstallDirs
, or by using abuilt-in default if that variable is not defined. See the table below forthe supported file types and their corresponding variables and built-indefaults. Projects can provide a DESTINATION
argument instead of afile type if they wish to explicitly define the install destination.TYPE Argument | GNUInstallDirs Variable | Built-In Default |
---|---|---|
BIN | ${CMAKE_INSTALL_BINDIR} | bin |
SBIN | ${CMAKE_INSTALL_SBINDIR} | sbin |
LIB | ${CMAKE_INSTALL_LIBDIR} | lib |
INCLUDE | ${CMAKE_INSTALL_INCLUDEDIR} | include |
SYSCONF | ${CMAKE_INSTALL_SYSCONFDIR} | etc |
SHAREDSTATE | ${CMAKE_INSTALL_SHARESTATEDIR} | com |
LOCALSTATE | ${CMAKE_INSTALL_LOCALSTATEDIR} | var |
RUNSTATE | https://hoffcities.weebly.com/xonar-d2-driver-download.html. ${CMAKE_INSTALL_RUNSTATEDIR} | <LOCALSTATEdir>/run |
DATA | ${CMAKE_INSTALL_DATADIR} | <DATAROOTdir> |
INFO | ${CMAKE_INSTALL_INFODIR} | <DATAROOTdir>/info |
LOCALE | ${CMAKE_INSTALL_LOCALEDIR} | <DATAROOTdir>/locale |
MAN | ${CMAKE_INSTALL_MANDIR} | <DATAROOTdir>/man |
DOC | ${CMAKE_INSTALL_DOCDIR} | <DATAROOTdir>/doc |
Projects wishing to follow the common practice of installing headers into aproject-specific subdirectory will need to provide a destination rather thanrely on the above.
Note that some of the types’ built-in defaults use the
DATAROOT
directory asa prefix. The DATAROOT
prefix is calculated similarly to the types, withCMAKE_INSTALL_DATAROOTDIR
as the variable and share
as the built-indefault. You cannot use DATAROOT
as a TYPE
parameter; please useDATA
instead.To make packages compliant with distribution filesystem layout policies, ifprojects must specify a
DESTINATION
, it is recommended that they use apath that begins with the appropriate GNUInstallDirs
variable.This allows package maintainers to control the install destination by settingthe appropriate cache variables. The following example shows how to followthis advice while installing headers to a project-specific subdirectory:An install destination given as a
DESTINATION
argument mayuse “generator expressions” with the syntax $<.>
. See thecmake-generator-expressions(7)
manual for available expressions.Installing Directories¶
The
DIRECTORY
form installs contents of one or more directories to agiven destination. The directory structure is copied verbatim to thedestination. The last component of each directory name is appended tothe destination directory but a trailing slash may be used to avoidthis because it leaves the last component empty. Directory namesgiven as relative paths are interpreted with respect to the currentsource directory. If no input directory names are given thedestination directory will be created but nothing will be installedinto it. The FILE_PERMISSIONS
and DIRECTORY_PERMISSIONS
optionsspecify permissions given to files and directories in the destination.If USE_SOURCE_PERMISSIONS
is specified and FILE_PERMISSIONS
is not,file permissions will be copied from the source directory structure.If no permissions are specified files will be given the defaultpermissions specified in the FILES
form of the command, and thedirectories will be given the default permissions specified in thePROGRAMS
form of the command.The
MESSAGE_NEVER
option disables file installation status output.Installation of directories may be controlled with fine granularityusing the
PATTERN
or REGEX
options. These “match” options specify aglobbing pattern or regular expression to match directories or filesencountered within input directories. They may be used to applycertain options (see below) to a subset of the files and directoriesencountered. The full path to each input file or directory (withforward slashes) is matched against the expression. A PATTERN
willmatch only complete file names: the portion of the full path matchingthe pattern must occur at the end of the file name and be preceded bya slash. A REGEX
will match any portion of the full path but it mayuse /
and $
to simulate the PATTERN
behavior. By default allfiles and directories are installed whether or not they are matched.The FILES_MATCHING
option may be given before the first match optionto disable installation of files (but not directories) not matched byany expression. For example, the codehttps://ameblo.jp/redabestmo1973/entry-12640171612.html. will extract and install header files from a source tree.
Some options may follow a
PATTERN
or REGEX
expression and are appliedonly to files or directories matching them. The EXCLUDE
option willskip the matched file or directory. The PERMISSIONS
option overridesthe permissions setting for the matched file or directory. Forexample the codewill install the
icons
directory to share/myproj/icons
and thescripts
directory to share/myproj
. The icons will get defaultfile permissions, the scripts will be given specific permissions, and anyCVS
directories will be excluded.Either a
TYPE
or a DESTINATION
must be provided, but not both.A TYPE
argument specifies the generic file type of the files within thelisted directories being installed. A destination will then be setautomatically by taking the corresponding variable fromGNUInstallDirs
, or by using a built-in default if that variableis not defined. See the table below for the supported file types and theircorresponding variables and built-in defaults. Projects can provide aDESTINATION
argument instead of a file type if they wish to explicitlydefine the install destination.TYPE Argument | GNUInstallDirs Variable | Built-In Default |
---|---|---|
BIN | ${CMAKE_INSTALL_BINDIR} | bin |
SBIN | ${CMAKE_INSTALL_SBINDIR} | sbin |
LIB | ${CMAKE_INSTALL_LIBDIR} | lib |
INCLUDE | ${CMAKE_INSTALL_INCLUDEDIR} | include |
SYSCONF | ${CMAKE_INSTALL_SYSCONFDIR} | etc |
SHAREDSTATE | ${CMAKE_INSTALL_SHARESTATEDIR} | com |
LOCALSTATE | ${CMAKE_INSTALL_LOCALSTATEDIR} | var |
RUNSTATE | ${CMAKE_INSTALL_RUNSTATEDIR} | <LOCALSTATEdir>/run |
DATA | ${CMAKE_INSTALL_DATADIR} | <DATAROOTdir> |
INFO | ${CMAKE_INSTALL_INFODIR} | <DATAROOTdir>/info |
LOCALE | ${CMAKE_INSTALL_LOCALEDIR} https://motorcyclehigh-power793.weebly.com/free-chess-games-for-windows-10.html. | <DATAROOTdir>/locale |
${CMAKE_INSTALL_MANDIR} | <DATAROOTdir>/man | |
DOC | ${CMAKE_INSTALL_DOCDIR} | <DATAROOTdir>/doc |
Note that some of the types’ built-in defaults use the
DATAROOT
directory asa prefix. The DATAROOT
prefix is calculated similarly to the types, withCMAKE_INSTALL_DATAROOTDIR
as the variable and share
as the built-indefault. You cannot use DATAROOT
as a TYPE
parameter; please useDATA
instead.To make packages compliant with distribution filesystem layout policies, ifprojects must specify a
DESTINATION
, it is recommended that they use apath that begins with the appropriate GNUInstallDirs
variable.This allows package maintainers to control the install destination by settingthe appropriate cache variables.Climate For Mac Os C Lion
The list of
dirs.
given to DIRECTORY
and an install destinationgiven as a DESTINATION
argument may use “generator expressions”with the syntax $<.>
. See the cmake-generator-expressions(7)
manual for available expressions.Custom Installation Logic¶
The
SCRIPT
form will invoke the given CMake script files duringinstallation. If the script file name is a relative path it will beinterpreted with respect to the current source directory. The CODE
form will invoke the given CMake code during installation. Code isspecified as a single argument inside a double-quoted string. Forexample, the codewill print a message during installation.
<file>
or <code>
may use “generator expressions” with the syntax$<.>
(in the case of <file>
, this refers to their use in the filename, not the file’s contents). See thecmake-generator-expressions(7)
manual for available expressions.Installing Exports¶
The
EXPORT
form generates and installs a CMake file containing code toimport targets from the installation tree into another project.Target installations are associated with the export <export-name>
using the EXPORT
option of the install(TARGETS) signaturedocumented above. The NAMESPACE
option will prepend <namespace>
tothe target names as they are written to the import file. By defaultthe generated file will be called <export-name>.cmake
but the FILE
option may be used to specify a different name. The value given tothe FILE
option must be a file name with the .cmake
extension.If a CONFIGURATIONS
option is given then the file will only be installedwhen one of the named configurations is installed. Additionally, thegenerated import file will reference only the matching targetconfigurations. The EXPORT_LINK_INTERFACE_LIBRARIES
keyword, ifpresent, causes the contents of the properties matching(IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?
to be exported, whenpolicy CMP0022
is NEW
.Note
Cmake For Osx
The installed
<export-name>.cmake
file may come with additionalper-configuration <export-name>-*.cmake
files to be loaded byglobbing. Do not use an export name that is the same as the packagename in combination with installing a <package-name>-config.cmake
file or the latter may be incorrectly matched by the glob and loaded.When a
COMPONENT
option is given, the listed <component>
implicitlydepends on all components mentioned in the export set. The exported<name>.cmake
file will require each of the exported components to bepresent in order for dependent projects to build properly. For example, aproject may define components Runtime
and Development
, with sharedlibraries going into the Runtime
component and static libraries andheaders going into the Development
component. The export set would alsotypically be part of the Development
component, but it would exporttargets from both the Runtime
and Development
components. Therefore,the Runtime
component would need to be installed if the Development
component was installed, but not vice versa. If the Development
componentwas installed without the Runtime
component, dependent projects that tryto link against it would have build errors. Package managers, such as APT andRPM, typically handle this by listing the Runtime
component as a dependencyof the Development
component in the package metadata, ensuring that thelibrary is always installed if the headers and CMake export file are present.In addition to cmake language files, the
EXPORT_ANDROID_MK
mode maybeused to specify an export to the android ndk build system. This modeaccepts the same options as the normal export mode. The AndroidNDK supports the use of prebuilt libraries, both static and shared. Thisallows cmake to build the libraries of a project and make them availableto an ndk build system complete with transitive dependencies, include flagsand defines required to use the libraries.The
EXPORT
form is useful to help outside projects use targets builtand installed by the current project. For example, the codewill install the executable
myexe
to <prefix>/bin
and code to importit in the file <prefix>/lib/myproj/myproj.cmake
and<prefix>/share/ndk-modules/Android.mk
. An outside projectmay load this file with the include command and reference the myexe
executable from the installation tree using the imported target namemp_myexe
as if the target were built in its own tree.Note
This command supercedes the
install_targets()
command andthe PRE_INSTALL_SCRIPT
and POST_INSTALL_SCRIPT
target properties. It also replaces the FILES
forms of theinstall_files()
and install_programs()
commands.The processing order of these install rules relative tothose generated by install_targets()
,install_files()
, and install_programs()
commandsis not defined.Climate For Mac Os C Compiler
Generated Installation Script¶
Note
Use of this feature is not recommended. Please consider using the
--install
argument of cmake(1)
instead.The
install()
command generates a file, cmake_install.cmake
, insidethe build directory, which is used internally by the generated install targetand by CPack. You can also invoke this script manually with cmake-P
. Thisscript accepts several variables:COMPONENT
Set this variable to install only a single CPack component as opposed to allof them. For example, if you only want to install the
Development
component, run cmake-DCOMPONENT=Development-Pcmake_install.cmake
.BUILD_TYPE
Set this variable to change the build type if you are using a multi-configgenerator. For example, to install with the
Debug
configuration, runcmake-DBUILD_TYPE=Debug-Pcmake_install.cmake
.DESTDIR
This is an environment variable rather than a CMake variable. It allows youto change the installation prefix on UNIX systems. See
-->DESTDIR
fordetails.Climate For Mac Os C ++ Ide
The preprocessor expands macros in all lines except preprocessor directives, lines that have a # as the first non-white-space character. It expands macros in parts of some directives that aren't skipped as part of a conditional compilation. Conditional compilation directives allow you to suppress compilation of parts of a source file. They test a constant expression or identifier to determine which text blocks to pass on to the compiler, and which ones to remove from the source file during preprocessing.
The
#define
directive is typically used to associate meaningful identifiers with constants, keywords, and commonly used statements or expressions. Identifiers that represent constants are sometimes called symbolic constants or manifest constants. Identifiers that represent statements or expressions are called macros. In this preprocessor documentation, only the term 'macro' is used.When the name of a macro is recognized in the program source text, or in the arguments of certain other preprocessor commands, it's treated as a call to that macro. The macro name is replaced by a copy of the macro body. If the macro accepts arguments, the actual arguments following the macro name are substituted for formal parameters in the macro body. The process of replacing a macro call with the processed copy of the body is called expansion of the macro call.
In practical terms, there are two types of macros. Object-like macros take no arguments. Function-like macros can be defined to accept arguments, so that they look and act like function calls. Because macros don't generate actual function calls, you can sometimes make programs run faster by replacing function calls with macros. (In C++, inline functions are often a preferred method.) However, macros can create problems if you don't define and use them with care. You may have to use parentheses in macro definitions with arguments to preserve the proper precedence in an expression. Also, macros may not correctly handle expressions with side effects. For more information, see the
getrandom
example in The #define directive.Once you've defined a macro, you can't redefine it to a different value without first removing the original definition. However, you can redefine the macro with exactly the same definition. Thus, the same definition may appear more than once in a program.
The
#undef
directive removes the definition of a macro. Once you've removed the definition, you can redefine the macro to a different value. The #define directive and The #undef directive discuss the #define
and #undef
directives, respectively.For more information, see,