Sophie

Sophie

distrib > Mageia > 4 > x86_64 > by-pkgid > f800694edefe91adea2624f711a41a2d > files > 8440

php-manual-en-5.5.7-1.mga4.noarch.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
 <head>
  <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  <title>Basic constructs</title>

 </head>
 <body><div class="manualnavbar" style="text-align: center;">
 <div class="prev" style="text-align: left; float: left;"><a href="internals2.structure.files.html">Files which make up an extension</a></div>
 <div class="next" style="text-align: right; float: right;"><a href="internals2.structure.modstruct.html">The zend_module structure</a></div>
 <div class="up"><a href="internals2.structure.html">Extension structure</a></div>
 <div class="home"><a href="index.html">PHP Manual</a></div>
</div><hr /><div id="internals2.structure.basics" class="sect1">
  <h2 class="title">Basic constructs</h2>
  
  <p class="simpara">
   C is a very low-level language by modern definitions. This means that it has
   no built-in support for many features that PHP takes for granted, such as
   reflection, dynamic module loading, bounds checking, threadsafe data
   management and various useful data structures including linked lists and
   hash tables. At the same time, C is a common denominator of language support
   and functionality. Given enough work, none of these concepts are impossible;
   the Zend Engine uses them all.
  </p>

  <p class="simpara">
   A lot of effort has gone into making the Zend API both extensible and
   understandable, but C forces certain necessary declarations upon any
   extension that to an inexperienced eye seem redundant or plain unnecessary.
   All of those constructs, detailed in this section, are &quot;write once and
   forget&quot; in Zend Engine 2 and 3. Here are some excerpts from the pre-generated
   <var class="filename">php_counter.h</var> and <var class="filename">counter.c</var> files
   created by PHP 5.3&#039;s <strong class="command">ext_skel</strong>, showing the pre-generated
   declarations:
  </p>

  <blockquote class="note"><p><strong class="note">Note</strong>: 
   <span class="simpara">
    The astute reader will notice that there are several declarations in the
    real files that aren&#039;t shown here. Those declarations are specific to
    various Zend subsystems and are discussed elsewhere as appropriate.
   </span>
  </p></blockquote>

  <div class="example-contents screen">
<div class="cdata"><pre>
extern zend_module_entry counter_module_entry;
#define phpext_counter_ptr &amp;counter_module_entry

#ifdef PHP_WIN32
#    define PHP_COUNTER_API __declspec(dllexport)
#elif defined(__GNUC__) &amp;&amp; __GNUC__ &gt;= 4
#    define PHP_COUNTER_API __attribute__ ((visibility(&quot;default&quot;)))
#else
#    define PHP_COUNTER_API
#endif

#ifdef ZTS
#include &quot;TSRM.h&quot;
#endif
</pre></div></div>
  <div class="example-contents screen">
<div class="cdata"><pre>
#ifdef HAVE_CONFIG_H
#include &quot;config.h&quot;
#endif

#include &quot;php.h&quot;
#include &quot;php_ini.h&quot;
#include &quot;ext/standard/info.h&quot;
#include &quot;php_counter.h&quot;

/* ... */

#ifdef COMPILE_DL_COUNTER
ZEND_GET_MODULE(counter)
#endif
</pre></div></div>
  
  <ul class="itemizedlist">
   <li class="listitem">
    <span class="simpara">
     The lines concerning <em>counter_module_entry</em> declare a
     global variable, and a macroed pointer to it, which contains the
     <em>zend_module_entry</em> for the extension. Despite the later
     discussion regarding the drawbacks of &quot;true&quot; globals, this usage is
     intentional; Zend takes precautions to avoid misusing this variable.
    </span>
   </li>
   <li class="listitem">
    <span class="simpara">
     <strong><code>PHP_COUNTER_API</code></strong> is declared for use by non-PHP
     functions the module intends to export for the use of other modules. The
     counter extension doesn&#039;t declare any of these, and in the final version of
     the header file, this macro has been removed. The
     <strong><code>PHPAPI</code></strong> macro is declared identically elsewhere and is
     used by the standard extension to make the  <span class="function"><a href="function.phpinfo.html" class="function">phpinfo()</a></span>
     utility functions available to other extensions.
    </span>
   </li>
   <li class="listitem">
    <span class="simpara">
     The include of <var class="filename">TSRM.h</var> is skipped if PHP, or the
     extension, isn&#039;t being compiled with thread-safety, since in that case TSRM
     isn&#039;t used.
    </span>
   </li>
   <li class="listitem">
    <span class="simpara">
     A standard list of includes, especially the extension&#039;s own
     <var class="filename">php_counter.h</var>, is given. <var class="filename">config.h</var>
     gives the extension access to determinations made by
     <strong class="command">configure</strong>. <var class="filename">php.h</var> is the gateway to
     the entire PHP and Zend APIs. <var class="filename">php_ini.h</var> adds the APIs
     for runtime configuration (INI) entries. Not all extensions will use this.
     Finally, <var class="filename">ext/standard/info.h</var> imports the
     aforementioned  <span class="function"><a href="function.phpinfo.html" class="function">phpinfo()</a></span> utility API.
    </span>
   </li>
   <li class="listitem">
    <span class="simpara">
     <strong><code>COMPILE_DL_COUNTER</code></strong> will only be defined by
     <strong class="command">configure</strong> if the counter extension is both enabled and
     wants to be built as a dynamically loadable module instead of being
     statically linked into PHP. <strong><code>ZEND_GET_MODULE</code></strong> defines a
     tiny function which Zend can use to get the extension&#039;s
     <em>zend_module_entry</em> at runtime.
    </span>
    <blockquote class="note"><p><strong class="note">Note</strong>: 
     <span class="simpara">
      The astute reader who has peeked into
      <var class="filename">main/php_config.h</var> after trying to build with the
      counter module enabled statically may have noticed that there is also a
      <strong><code>HAVE_COUNTER</code></strong> constant defined that the source code
      doesn&#039;t check for. There&#039;s a simple reason this check isn&#039;t done: It&#039;s
      unnecessary. If the extension isn&#039;t enabled, the source file will never be
      compiled.
     </span>
    </p></blockquote>
   </li>
  </ul>
 
 </div><hr /><div class="manualnavbar" style="text-align: center;">
 <div class="prev" style="text-align: left; float: left;"><a href="internals2.structure.files.html">Files which make up an extension</a></div>
 <div class="next" style="text-align: right; float: right;"><a href="internals2.structure.modstruct.html">The zend_module structure</a></div>
 <div class="up"><a href="internals2.structure.html">Extension structure</a></div>
 <div class="home"><a href="index.html">PHP Manual</a></div>
</div></body></html>