faq.xml: Adjust structure for pdf index.
2010-02-24 Benjamin Kosnik <bkoz@redhat.com> * doc/xml/faq.xml: Adjust structure for pdf index. * doc/xml/manual/mt_allocator.xml: Same. * doc/xml/manual/allocator.xml: Same. * doc/xml/manual/ctype.xml: Same. * doc/xml/manual/numerics.xml: Same. * doc/xml/manual/codecvt.xml: Same. * doc/xml/manual/intro.xml: Same. * doc/xml/manual/shared_ptr.xml: Same. * doc/xml/manual/status_cxxtr1.xml: Same. * doc/xml/manual/auto_ptr.xml: Same. * doc/xml/manual/internals.xml: Same. * doc/xml/manual/status_cxx1998.xml: Same. * doc/xml/manual/parallel_mode.xml: Same. * doc/xml/manual/profile_mode.xml: Same. * doc/xml/manual/containers.xml: Same. * doc/xml/manual/io.xml: Same. * doc/xml/manual/concurrency_extensions.xml: Same. * doc/xml/manual/appendix_porting.xml: Same. * doc/xml/manual/utilities.xml: Same. * doc/xml/manual/support.xml: Same. * doc/xml/manual/bitmap_allocator.xml: Same. * doc/xml/manual/configure.xml: Same. * doc/xml/manual/build_hacking.xml: Same. * doc/xml/manual/evolution.xml: Same. * doc/xml/manual/using.xml: Same. * doc/xml/manual/debug.xml: Same. * doc/xml/manual/localization.xml: Same. * doc/xml/manual/strings.xml: Same. * doc/xml/manual/debug_mode.xml: Same. * doc/xml/manual/locale.xml: Same. * doc/xml/manual/extensions.xml: Same. * doc/xml/manual/appendix_contributing.xml: Same. * doc/xml/manual/prerequisites.xml: Same. * doc/xml/manual/messages.xml: Same. * doc/xml/manual/diagnostics.xml: Same. * doc/xml/manual/algorithms.xml: Same. * doc/xml/manual/appendix_free.xml: Same. * doc/xml/manual/iterators.xml: Same. * doc/xml/manual/spine.xml: Same. * doc/xml/manual/status_cxxtr24733.xml: Same. * doc/xml/manual/status_cxx200x.xml: Same. * doc/Makefile.am: Refactor. * doc/Makefile.in: Regenerate. * include/bits/c++0x_warning.h: Tweak doxygen file markup. From-SVN: r157059
This commit is contained in:
parent
72c2ffd351
commit
03a32789f4
@ -1,3 +1,51 @@
|
||||
2010-02-24 Benjamin Kosnik <bkoz@redhat.com>
|
||||
|
||||
* doc/xml/faq.xml: Adjust structure for pdf index.
|
||||
* doc/xml/manual/mt_allocator.xml: Same.
|
||||
* doc/xml/manual/allocator.xml: Same.
|
||||
* doc/xml/manual/ctype.xml: Same.
|
||||
* doc/xml/manual/numerics.xml: Same.
|
||||
* doc/xml/manual/codecvt.xml: Same.
|
||||
* doc/xml/manual/intro.xml: Same.
|
||||
* doc/xml/manual/shared_ptr.xml: Same.
|
||||
* doc/xml/manual/status_cxxtr1.xml: Same.
|
||||
* doc/xml/manual/auto_ptr.xml: Same.
|
||||
* doc/xml/manual/internals.xml: Same.
|
||||
* doc/xml/manual/status_cxx1998.xml: Same.
|
||||
* doc/xml/manual/parallel_mode.xml: Same.
|
||||
* doc/xml/manual/profile_mode.xml: Same.
|
||||
* doc/xml/manual/containers.xml: Same.
|
||||
* doc/xml/manual/io.xml: Same.
|
||||
* doc/xml/manual/concurrency_extensions.xml: Same.
|
||||
* doc/xml/manual/appendix_porting.xml: Same.
|
||||
* doc/xml/manual/utilities.xml: Same.
|
||||
* doc/xml/manual/support.xml: Same.
|
||||
* doc/xml/manual/bitmap_allocator.xml: Same.
|
||||
* doc/xml/manual/configure.xml: Same.
|
||||
* doc/xml/manual/build_hacking.xml: Same.
|
||||
* doc/xml/manual/evolution.xml: Same.
|
||||
* doc/xml/manual/using.xml: Same.
|
||||
* doc/xml/manual/debug.xml: Same.
|
||||
* doc/xml/manual/localization.xml: Same.
|
||||
* doc/xml/manual/strings.xml: Same.
|
||||
* doc/xml/manual/debug_mode.xml: Same.
|
||||
* doc/xml/manual/locale.xml: Same.
|
||||
* doc/xml/manual/extensions.xml: Same.
|
||||
* doc/xml/manual/appendix_contributing.xml: Same.
|
||||
* doc/xml/manual/prerequisites.xml: Same.
|
||||
* doc/xml/manual/messages.xml: Same.
|
||||
* doc/xml/manual/diagnostics.xml: Same.
|
||||
* doc/xml/manual/algorithms.xml: Same.
|
||||
* doc/xml/manual/appendix_free.xml: Same.
|
||||
* doc/xml/manual/iterators.xml: Same.
|
||||
* doc/xml/manual/spine.xml: Same.
|
||||
* doc/xml/manual/status_cxxtr24733.xml: Same.
|
||||
* doc/xml/manual/status_cxx200x.xml: Same.
|
||||
* doc/Makefile.am: Refactor.
|
||||
* doc/Makefile.in: Regenerate.
|
||||
|
||||
* include/bits/c++0x_warning.h: Tweak doxygen file markup.
|
||||
|
||||
2010-02-24 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
|
||||
|
||||
* testsuite/ext/new_allocator/deallocate_global.cc: Require
|
||||
|
@ -22,44 +22,50 @@
|
||||
|
||||
include $(top_srcdir)/fragment.am
|
||||
|
||||
# Documentation Overview
|
||||
#
|
||||
# There are two main source materials for libstdc++ documentation.
|
||||
# The first is the doxygen markup in libstdc++ sources. And the second
|
||||
# is the docbook markup in doc/xml/. A third and more obscure option
|
||||
# deals with charting performance tests.
|
||||
|
||||
# Default, points to current best sub-rule that is the best conversion.
|
||||
# MAN
|
||||
doc-man: doc-man-doxygen
|
||||
|
||||
# PDF
|
||||
doc-pdf: doc-pdf-dblatex-docbook
|
||||
|
||||
# HTML
|
||||
doc-html: doc-html-docbook
|
||||
|
||||
|
||||
# Doxygen configuration
|
||||
# Assumes doxygen, graphviz (with dot) installed
|
||||
doc_doxygen_script=${top_srcdir}/scripts/run_doxygen
|
||||
doxygen_script=${top_srcdir}/scripts/run_doxygen
|
||||
doxygen_outdir = ${glibcxx_builddir}/doc/doxygen
|
||||
doc-html-doxygen:
|
||||
-(srcdir=`cd ${top_srcdir}; ${PWD_COMMAND}`; \
|
||||
builddir=`cd ..; ${PWD_COMMAND}`; \
|
||||
${SHELL} ${doc_doxygen_script} \
|
||||
${SHELL} ${doxygen_script} \
|
||||
--host_alias=${host_alias} --mode=html $${srcdir} $${builddir} YES)
|
||||
|
||||
doc-man-doxygen:
|
||||
-(srcdir=`cd ${top_srcdir}; ${PWD_COMMAND}`; \
|
||||
builddir=`cd ..; ${PWD_COMMAND}`; \
|
||||
${SHELL} ${doc_doxygen_script} \
|
||||
${SHELL} ${doxygen_script} \
|
||||
--host_alias=${host_alias} --mode=man $${srcdir} $${builddir} YES)
|
||||
|
||||
doc-xml-doxygen:
|
||||
doc-xml-doxygen:
|
||||
-(srcdir=`cd ${top_srcdir}; ${PWD_COMMAND}`; \
|
||||
builddir=`cd ..; ${PWD_COMMAND}`; \
|
||||
${SHELL} ${doc_doxygen_script} \
|
||||
${SHELL} ${doxygen_script} \
|
||||
--host_alias=${host_alias} --mode=xml $${srcdir} $${builddir} NO)
|
||||
|
||||
doxygen_xmldir = ${glibcxx_builddir}/doc/doxygen/xml
|
||||
doc-xml-doxygen-single: doc-xml-doxygen
|
||||
doc-xml-single-doxygen:
|
||||
@echo "Generating doxygen xml single file..."
|
||||
$(XSLTPROC) ${doxygen_xmldir}/combine.xslt ${doxygen_xmldir}/spine.xml > ${doxygen_xmldir}/all.xml;
|
||||
|
||||
|
||||
# Performance doc and graph configuration.
|
||||
# Assumes pychart, beautiful soup installed.
|
||||
# Generates the plots and graphs for performance testing.
|
||||
doc_performance_script=${top_srcdir}/scripts/make_graphs.py
|
||||
doc-html-performance:
|
||||
-@(chmod + ${doc_performance_script}; \
|
||||
${doc_performance_script} ${top_srcdir} \
|
||||
${glibcxx_builddir}/testsuite \
|
||||
${top_srcdir}/testsuite/data/make_graph_htmls.xml \
|
||||
${top_srcdir}/testsuite/data/make_graph_test_infos.xml local g++)
|
||||
$(XSLTPROC) ${doxygen_outdir}/xml/combine.xslt \
|
||||
${doxygen_outdir}/xml/spine.xml > ${doxygen_outdir}/xml/all.xml;
|
||||
|
||||
|
||||
# Docbook configuration.
|
||||
@ -68,6 +74,7 @@ doc-html-performance:
|
||||
# docbook-style-xsl
|
||||
# emacs-nxml-mode
|
||||
# xmlto passivetex
|
||||
docbook_outdir = ${glibcxx_builddir}/doc/docbook
|
||||
xml_srcdir = ${glibcxx_srcdir}/doc/xml
|
||||
xml_sources = \
|
||||
${xml_srcdir}/spine.xml \
|
||||
@ -112,6 +119,7 @@ xml_sources = \
|
||||
${xml_srcdir}/manual/support.xml \
|
||||
${xml_srcdir}/manual/test.xml \
|
||||
${xml_srcdir}/manual/using.xml \
|
||||
${xml_srcdir}/manual/using_exceptions.xml \
|
||||
${xml_srcdir}/manual/utilities.xml \
|
||||
${xml_srcdir}/manual/appendix_free.xml \
|
||||
${xml_srcdir}/manual/appendix_contributing.xml \
|
||||
@ -137,17 +145,17 @@ XSL_HTML_STYLE = $(XSL_STYLE_DIR)/xhtml/chunk.xsl
|
||||
#XSL_HTML_SINGLE_STYLE = $(XSL_STYLE_DIR)/xhtml/onechunk.xsl
|
||||
XSL_HTML_SINGLE_STYLE = $(XSL_STYLE_DIR)/xhtml/docbook.xsl
|
||||
|
||||
${glibcxx_builddir}/doc/html:
|
||||
mkdir ${glibcxx_builddir}/doc/html
|
||||
${docbook_outdir}/html:
|
||||
mkdir -p ${docbook_outdir}/html
|
||||
|
||||
${glibcxx_builddir}/doc/pdf:
|
||||
mkdir ${glibcxx_builddir}/doc/pdf
|
||||
${docbook_outdir}/pdf:
|
||||
mkdir -p ${docbook_outdir}/pdf
|
||||
|
||||
${glibcxx_builddir}/doc/fo:
|
||||
mkdir ${glibcxx_builddir}/doc/fo
|
||||
${docbook_outdir}/fo:
|
||||
mkdir -p ${docbook_outdir}/fo
|
||||
|
||||
${glibcxx_builddir}/doc/xml:
|
||||
mkdir ${glibcxx_builddir}/doc/xml
|
||||
${docbook_outdir}/xml:
|
||||
mkdir -p ${docbook_outdir}/xml
|
||||
|
||||
# Validate existing XML structure.
|
||||
XMLLINT = xmllint
|
||||
@ -156,57 +164,53 @@ XMLLINT = xmllint
|
||||
LINT_FLAGS = --postvalid --debug --xinclude --noent --noblanks --nonet --noout
|
||||
VALID_FLAGS = --dtdvalid http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
|
||||
XMLLINT_FLAGS = $(LINT_FLAGS) $(VALID_FLAGS)
|
||||
doc-xml-validate: $(xml_sources)
|
||||
doc-xml-validate-docbook: $(xml_sources)
|
||||
@echo "Generating XML validation log..."
|
||||
$(XMLLINT) $(XMLLINT_FLAGS) ${top_srcdir}/doc/xml/spine.xml
|
||||
|
||||
doc-xml-single: $(xml_sources) ${glibcxx_builddir}/doc/xml
|
||||
doc-xml-single-docbook: $(xml_sources) ${docbook_outdir}/xml
|
||||
@echo "Generating XML single..."
|
||||
$(XMLLINT) --xinclude --noent --noblanks \
|
||||
-o ${glibcxx_builddir}/doc/xml/spine-single.xml \
|
||||
-o ${docbook_outdir}/xml/spine-single.xml \
|
||||
${top_srcdir}/doc/xml/spine.xml
|
||||
|
||||
# HTML, index plus chapters
|
||||
doc-html: $(xml_sources) ${glibcxx_builddir}/doc/html
|
||||
doc-html-docbook: $(xml_sources) ${docbook_outdir}/html
|
||||
@echo "Generating html files..."
|
||||
$(XSLTPROC) $(XSLTPROC_FLAGS) -o ${glibcxx_builddir}/doc/html/ \
|
||||
$(XSLTPROC) $(XSLTPROC_FLAGS) -o ${docbook_outdir}/html/ \
|
||||
$(XSL_HTML_STYLE) ${top_srcdir}/doc/xml/spine.xml
|
||||
|
||||
# HTML, all one page
|
||||
doc-html-single: $(xml_sources) ${glibcxx_builddir}/doc/html
|
||||
doc-html-single-docbook: $(xml_sources) ${docbook_outdir}/html
|
||||
@echo "Generating html single file..."
|
||||
$(XSLTPROC) $(XSLTPROC_FLAGS) -o ${glibcxx_builddir}/doc/html/ \
|
||||
$(XSLTPROC) $(XSLTPROC_FLAGS) -o ${docbook_outdir}/html/ \
|
||||
$(XSL_HTML_SINGLE_STYLE) ${top_srcdir}/doc/xml/spine.xml
|
||||
|
||||
# FO
|
||||
doc-fo: $(xml_sources) ${glibcxx_builddir}/doc/fo
|
||||
doc-fo-docbook: $(xml_sources) ${docbook_outdir}/fo
|
||||
@echo "Generating FO files..."
|
||||
$(XSLTPROC) $(XSLTPROC_FLAGS) -o ${glibcxx_builddir}/doc/fo/spine.fo \
|
||||
$(XSLTPROC) $(XSLTPROC_FLAGS) -o ${docbook_outdir}/fo/spine.fo \
|
||||
$(XSL_FO_STYLE) ${top_srcdir}/doc/xml/spine.xml
|
||||
|
||||
# PDF
|
||||
# Points to current best xml to PDF generation process.
|
||||
doc-pdf: doc-pdf-dblatex
|
||||
|
||||
# PDF 1
|
||||
# fop
|
||||
FOP = fop
|
||||
FOP_FLAGS = -d -r
|
||||
doc-pdf-fop-xml: $(xml_sources) ${glibcxx_builddir}/doc/pdf
|
||||
doc-pdf-fop-xml-docbook: $(xml_sources) ${glibcxx_builddir}/doc/pdf
|
||||
@echo "Generating pdf fop files from xml..."
|
||||
$(FOP) $(FOP_FLAGS) -xml ${top_srcdir}/doc/xml/spine.xml \
|
||||
-xsl $(XSL_FO_STYLE) -pdf ${glibcxx_builddir}/doc/pdf/spine.pdf
|
||||
-xsl $(XSL_FO_STYLE) -pdf ${docbook_outdir}/pdf/spine.pdf
|
||||
|
||||
doc-pdf-fop-fo: $(xml_sources) ${glibcxx_builddir}/doc/pdf doc-fo
|
||||
doc-pdf-fop-fo-docbook: $(xml_sources) ${glibcxx_builddir}/doc/pdf doc-fo
|
||||
@echo "Generating pdf fop files from fo..."
|
||||
$(FOP) $(FOP_FLAGS) -fo ${glibcxx_builddir}/doc/fo/spine.fo \
|
||||
-pdf ${glibcxx_builddir}/doc/pdf/spine.pdf
|
||||
$(FOP) $(FOP_FLAGS) -fo ${docbook_outdir}/fo/spine.fo \
|
||||
-pdf ${docbook_outdir}/pdf/spine.pdf
|
||||
|
||||
# PDF 2
|
||||
# xmlto
|
||||
XML2PDF = xmlto
|
||||
XML2PDF_FLAGS = -v pdf --skip-validation -o pdf
|
||||
doc-pdf-xmlto: $(xml_sources) ${glibcxx_builddir}/doc/pdf
|
||||
doc-pdf-xmlto-docbook: $(xml_sources) ${docbook_outdir}/pdf
|
||||
@echo "Generating pdf xmlto files..."
|
||||
$(XML2PDF) $(XML2PDF_FLAGS) ${top_srcdir}/doc/xml/spine.xml
|
||||
|
||||
@ -214,26 +218,37 @@ doc-pdf-xmlto: $(xml_sources) ${glibcxx_builddir}/doc/pdf
|
||||
# xmlroff
|
||||
XMLROFF = xmlroff
|
||||
XMLROFF_FLAGS = --format=pdf --backend=cairo --warn=1 --debug=1 --continue
|
||||
doc-pdf-xmlroff: $(xml_sources) doc-fo
|
||||
doc-pdf-xmlroff-docbook: $(xml_sources) doc-fo
|
||||
@echo "Generating pdf xmlroff files..."
|
||||
$(XMLROFF) $(XMLROFF_FLAGS) ${glibcxx_builddir}/doc/fo/spine.fo
|
||||
$(XMLROFF) $(XMLROFF_FLAGS) ${docbook_outdir}/fo/spine.fo
|
||||
|
||||
# PDF 4
|
||||
# prince
|
||||
PRINCE = prince
|
||||
PRINCE_FLAGS = --log prince.log -o pdf/spine.pdf
|
||||
doc-pdf-prince: $(xml_sources) ${glibcxx_builddir}/doc/pdf
|
||||
doc-pdf-prince-docbook: $(xml_sources) ${docbook_outdir}/pdf
|
||||
@echo "Generating pdf prince files..."
|
||||
$(PRINCE) $(PRINCE_FLAGS) ${top_srcdir}/doc/xml/spine.xml
|
||||
$(PRINCE) $(PRINCE_FLAGS) ${top_srcdir}/xml/spine.xml
|
||||
|
||||
# PDF 5
|
||||
# dblatex
|
||||
DBLATEX_FLAGS = --dump --verbose --pdf -o pdf/manual.pdf
|
||||
doc-pdf-dblatex: $(xml_sources) ${glibcxx_builddir}/doc/pdf
|
||||
DBLATEX_FLAGS = --dump --verbose --pdf -o ${docbook_outdir}/pdf/manual.pdf
|
||||
doc-pdf-dblatex-docbook: $(xml_sources) ${docbook_outdir}/pdf
|
||||
@echo "Generating pdf dblatex files..."
|
||||
dblatex $(DBLATEX_FLAGS) ${top_srcdir}/doc/xml/spine.xml
|
||||
|
||||
|
||||
# Performance doc and graph configuration.
|
||||
# Assumes pychart, beautiful soup installed.
|
||||
# Generates the plots and graphs for performance testing.
|
||||
doc_performance_script=${top_srcdir}/scripts/make_graphs.py
|
||||
doc-html-performance:
|
||||
-@(chmod + ${doc_performance_script}; \
|
||||
${doc_performance_script} ${top_srcdir} \
|
||||
${glibcxx_builddir}/testsuite \
|
||||
${top_srcdir}/testsuite/data/make_graph_htmls.xml \
|
||||
${top_srcdir}/testsuite/data/make_graph_test_infos.xml local g++)
|
||||
|
||||
.PHONY: doc-doxygen-html doc-doxygen-man doc-performance
|
||||
|
||||
# By adding these files here, automake will remove them for 'make clean'
|
||||
@ -241,4 +256,4 @@ CLEANFILES = *.log
|
||||
|
||||
# To remove directories.
|
||||
clean-local:
|
||||
rm -rf man html pdf fo doxygen xml
|
||||
rm -rf man html pdf fo xml doxygen docbook
|
||||
|
@ -265,13 +265,8 @@ AM_CPPFLAGS = $(GLIBCXX_INCLUDES)
|
||||
|
||||
# Doxygen configuration
|
||||
# Assumes doxygen, graphviz (with dot) installed
|
||||
doc_doxygen_script = ${top_srcdir}/scripts/run_doxygen
|
||||
doxygen_xmldir = ${glibcxx_builddir}/doc/doxygen/xml
|
||||
|
||||
# Performance doc and graph configuration.
|
||||
# Assumes pychart, beautiful soup installed.
|
||||
# Generates the plots and graphs for performance testing.
|
||||
doc_performance_script = ${top_srcdir}/scripts/make_graphs.py
|
||||
doxygen_script = ${top_srcdir}/scripts/run_doxygen
|
||||
doxygen_outdir = ${glibcxx_builddir}/doc/doxygen
|
||||
|
||||
# Docbook configuration.
|
||||
# Assumes
|
||||
@ -279,6 +274,7 @@ doc_performance_script = ${top_srcdir}/scripts/make_graphs.py
|
||||
# docbook-style-xsl
|
||||
# emacs-nxml-mode
|
||||
# xmlto passivetex
|
||||
docbook_outdir = ${glibcxx_builddir}/doc/docbook
|
||||
xml_srcdir = ${glibcxx_srcdir}/doc/xml
|
||||
xml_sources = \
|
||||
${xml_srcdir}/spine.xml \
|
||||
@ -323,6 +319,7 @@ xml_sources = \
|
||||
${xml_srcdir}/manual/support.xml \
|
||||
${xml_srcdir}/manual/test.xml \
|
||||
${xml_srcdir}/manual/using.xml \
|
||||
${xml_srcdir}/manual/using_exceptions.xml \
|
||||
${xml_srcdir}/manual/utilities.xml \
|
||||
${xml_srcdir}/manual/appendix_free.xml \
|
||||
${xml_srcdir}/manual/appendix_contributing.xml \
|
||||
@ -377,7 +374,12 @@ PRINCE_FLAGS = --log prince.log -o pdf/spine.pdf
|
||||
|
||||
# PDF 5
|
||||
# dblatex
|
||||
DBLATEX_FLAGS = --dump --verbose --pdf -o pdf/manual.pdf
|
||||
DBLATEX_FLAGS = --dump --verbose --pdf -o ${docbook_outdir}/pdf/manual.pdf
|
||||
|
||||
# Performance doc and graph configuration.
|
||||
# Assumes pychart, beautiful soup installed.
|
||||
# Generates the plots and graphs for performance testing.
|
||||
doc_performance_script = ${top_srcdir}/scripts/make_graphs.py
|
||||
|
||||
# By adding these files here, automake will remove them for 'make clean'
|
||||
CLEANFILES = *.log
|
||||
@ -567,26 +569,105 @@ uninstall-am:
|
||||
mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
|
||||
uninstall uninstall-am
|
||||
|
||||
|
||||
# Documentation Overview
|
||||
#
|
||||
# There are two main source materials for libstdc++ documentation.
|
||||
# The first is the doxygen markup in libstdc++ sources. And the second
|
||||
# is the docbook markup in doc/xml/. A third and more obscure option
|
||||
# deals with charting performance tests.
|
||||
|
||||
# Default, points to current best sub-rule that is the best conversion.
|
||||
# MAN
|
||||
doc-man: doc-man-doxygen
|
||||
|
||||
# PDF
|
||||
doc-pdf: doc-pdf-dblatex-docbook
|
||||
|
||||
# HTML
|
||||
doc-html: doc-html-docbook
|
||||
doc-html-doxygen:
|
||||
-(srcdir=`cd ${top_srcdir}; ${PWD_COMMAND}`; \
|
||||
builddir=`cd ..; ${PWD_COMMAND}`; \
|
||||
${SHELL} ${doc_doxygen_script} \
|
||||
${SHELL} ${doxygen_script} \
|
||||
--host_alias=${host_alias} --mode=html $${srcdir} $${builddir} YES)
|
||||
|
||||
doc-man-doxygen:
|
||||
-(srcdir=`cd ${top_srcdir}; ${PWD_COMMAND}`; \
|
||||
builddir=`cd ..; ${PWD_COMMAND}`; \
|
||||
${SHELL} ${doc_doxygen_script} \
|
||||
${SHELL} ${doxygen_script} \
|
||||
--host_alias=${host_alias} --mode=man $${srcdir} $${builddir} YES)
|
||||
|
||||
doc-xml-doxygen:
|
||||
doc-xml-doxygen:
|
||||
-(srcdir=`cd ${top_srcdir}; ${PWD_COMMAND}`; \
|
||||
builddir=`cd ..; ${PWD_COMMAND}`; \
|
||||
${SHELL} ${doc_doxygen_script} \
|
||||
${SHELL} ${doxygen_script} \
|
||||
--host_alias=${host_alias} --mode=xml $${srcdir} $${builddir} NO)
|
||||
doc-xml-doxygen-single: doc-xml-doxygen
|
||||
|
||||
doc-xml-single-doxygen:
|
||||
@echo "Generating doxygen xml single file..."
|
||||
$(XSLTPROC) ${doxygen_xmldir}/combine.xslt ${doxygen_xmldir}/spine.xml > ${doxygen_xmldir}/all.xml;
|
||||
$(XSLTPROC) ${doxygen_outdir}/xml/combine.xslt \
|
||||
${doxygen_outdir}/xml/spine.xml > ${doxygen_outdir}/xml/all.xml;
|
||||
|
||||
${docbook_outdir}/html:
|
||||
mkdir -p ${docbook_outdir}/html
|
||||
|
||||
${docbook_outdir}/pdf:
|
||||
mkdir -p ${docbook_outdir}/pdf
|
||||
|
||||
${docbook_outdir}/fo:
|
||||
mkdir -p ${docbook_outdir}/fo
|
||||
|
||||
${docbook_outdir}/xml:
|
||||
mkdir -p ${docbook_outdir}/xml
|
||||
doc-xml-validate-docbook: $(xml_sources)
|
||||
@echo "Generating XML validation log..."
|
||||
$(XMLLINT) $(XMLLINT_FLAGS) ${top_srcdir}/doc/xml/spine.xml
|
||||
|
||||
doc-xml-single-docbook: $(xml_sources) ${docbook_outdir}/xml
|
||||
@echo "Generating XML single..."
|
||||
$(XMLLINT) --xinclude --noent --noblanks \
|
||||
-o ${docbook_outdir}/xml/spine-single.xml \
|
||||
${top_srcdir}/doc/xml/spine.xml
|
||||
|
||||
# HTML, index plus chapters
|
||||
doc-html-docbook: $(xml_sources) ${docbook_outdir}/html
|
||||
@echo "Generating html files..."
|
||||
$(XSLTPROC) $(XSLTPROC_FLAGS) -o ${docbook_outdir}/html/ \
|
||||
$(XSL_HTML_STYLE) ${top_srcdir}/doc/xml/spine.xml
|
||||
|
||||
# HTML, all one page
|
||||
doc-html-single-docbook: $(xml_sources) ${docbook_outdir}/html
|
||||
@echo "Generating html single file..."
|
||||
$(XSLTPROC) $(XSLTPROC_FLAGS) -o ${docbook_outdir}/html/ \
|
||||
$(XSL_HTML_SINGLE_STYLE) ${top_srcdir}/doc/xml/spine.xml
|
||||
|
||||
# FO
|
||||
doc-fo-docbook: $(xml_sources) ${docbook_outdir}/fo
|
||||
@echo "Generating FO files..."
|
||||
$(XSLTPROC) $(XSLTPROC_FLAGS) -o ${docbook_outdir}/fo/spine.fo \
|
||||
$(XSL_FO_STYLE) ${top_srcdir}/doc/xml/spine.xml
|
||||
doc-pdf-fop-xml-docbook: $(xml_sources) ${glibcxx_builddir}/doc/pdf
|
||||
@echo "Generating pdf fop files from xml..."
|
||||
$(FOP) $(FOP_FLAGS) -xml ${top_srcdir}/doc/xml/spine.xml \
|
||||
-xsl $(XSL_FO_STYLE) -pdf ${docbook_outdir}/pdf/spine.pdf
|
||||
|
||||
doc-pdf-fop-fo-docbook: $(xml_sources) ${glibcxx_builddir}/doc/pdf doc-fo
|
||||
@echo "Generating pdf fop files from fo..."
|
||||
$(FOP) $(FOP_FLAGS) -fo ${docbook_outdir}/fo/spine.fo \
|
||||
-pdf ${docbook_outdir}/pdf/spine.pdf
|
||||
doc-pdf-xmlto-docbook: $(xml_sources) ${docbook_outdir}/pdf
|
||||
@echo "Generating pdf xmlto files..."
|
||||
$(XML2PDF) $(XML2PDF_FLAGS) ${top_srcdir}/doc/xml/spine.xml
|
||||
doc-pdf-xmlroff-docbook: $(xml_sources) doc-fo
|
||||
@echo "Generating pdf xmlroff files..."
|
||||
$(XMLROFF) $(XMLROFF_FLAGS) ${docbook_outdir}/fo/spine.fo
|
||||
doc-pdf-prince-docbook: $(xml_sources) ${docbook_outdir}/pdf
|
||||
@echo "Generating pdf prince files..."
|
||||
$(PRINCE) $(PRINCE_FLAGS) ${top_srcdir}/xml/spine.xml
|
||||
doc-pdf-dblatex-docbook: $(xml_sources) ${docbook_outdir}/pdf
|
||||
@echo "Generating pdf dblatex files..."
|
||||
dblatex $(DBLATEX_FLAGS) ${top_srcdir}/doc/xml/spine.xml
|
||||
doc-html-performance:
|
||||
-@(chmod + ${doc_performance_script}; \
|
||||
${doc_performance_script} ${top_srcdir} \
|
||||
@ -594,75 +675,11 @@ doc-html-performance:
|
||||
${top_srcdir}/testsuite/data/make_graph_htmls.xml \
|
||||
${top_srcdir}/testsuite/data/make_graph_test_infos.xml local g++)
|
||||
|
||||
${glibcxx_builddir}/doc/html:
|
||||
mkdir ${glibcxx_builddir}/doc/html
|
||||
|
||||
${glibcxx_builddir}/doc/pdf:
|
||||
mkdir ${glibcxx_builddir}/doc/pdf
|
||||
|
||||
${glibcxx_builddir}/doc/fo:
|
||||
mkdir ${glibcxx_builddir}/doc/fo
|
||||
|
||||
${glibcxx_builddir}/doc/xml:
|
||||
mkdir ${glibcxx_builddir}/doc/xml
|
||||
doc-xml-validate: $(xml_sources)
|
||||
@echo "Generating XML validation log..."
|
||||
$(XMLLINT) $(XMLLINT_FLAGS) ${top_srcdir}/doc/xml/spine.xml
|
||||
|
||||
doc-xml-single: $(xml_sources) ${glibcxx_builddir}/doc/xml
|
||||
@echo "Generating XML single..."
|
||||
$(XMLLINT) --xinclude --noent --noblanks \
|
||||
-o ${glibcxx_builddir}/doc/xml/spine-single.xml \
|
||||
${top_srcdir}/doc/xml/spine.xml
|
||||
|
||||
# HTML, index plus chapters
|
||||
doc-html: $(xml_sources) ${glibcxx_builddir}/doc/html
|
||||
@echo "Generating html files..."
|
||||
$(XSLTPROC) $(XSLTPROC_FLAGS) -o ${glibcxx_builddir}/doc/html/ \
|
||||
$(XSL_HTML_STYLE) ${top_srcdir}/doc/xml/spine.xml
|
||||
|
||||
# HTML, all one page
|
||||
doc-html-single: $(xml_sources) ${glibcxx_builddir}/doc/html
|
||||
@echo "Generating html single file..."
|
||||
$(XSLTPROC) $(XSLTPROC_FLAGS) -o ${glibcxx_builddir}/doc/html/ \
|
||||
$(XSL_HTML_SINGLE_STYLE) ${top_srcdir}/doc/xml/spine.xml
|
||||
|
||||
# FO
|
||||
doc-fo: $(xml_sources) ${glibcxx_builddir}/doc/fo
|
||||
@echo "Generating FO files..."
|
||||
$(XSLTPROC) $(XSLTPROC_FLAGS) -o ${glibcxx_builddir}/doc/fo/spine.fo \
|
||||
$(XSL_FO_STYLE) ${top_srcdir}/doc/xml/spine.xml
|
||||
|
||||
# PDF
|
||||
# Points to current best xml to PDF generation process.
|
||||
doc-pdf: doc-pdf-dblatex
|
||||
doc-pdf-fop-xml: $(xml_sources) ${glibcxx_builddir}/doc/pdf
|
||||
@echo "Generating pdf fop files from xml..."
|
||||
$(FOP) $(FOP_FLAGS) -xml ${top_srcdir}/doc/xml/spine.xml \
|
||||
-xsl $(XSL_FO_STYLE) -pdf ${glibcxx_builddir}/doc/pdf/spine.pdf
|
||||
|
||||
doc-pdf-fop-fo: $(xml_sources) ${glibcxx_builddir}/doc/pdf doc-fo
|
||||
@echo "Generating pdf fop files from fo..."
|
||||
$(FOP) $(FOP_FLAGS) -fo ${glibcxx_builddir}/doc/fo/spine.fo \
|
||||
-pdf ${glibcxx_builddir}/doc/pdf/spine.pdf
|
||||
doc-pdf-xmlto: $(xml_sources) ${glibcxx_builddir}/doc/pdf
|
||||
@echo "Generating pdf xmlto files..."
|
||||
$(XML2PDF) $(XML2PDF_FLAGS) ${top_srcdir}/doc/xml/spine.xml
|
||||
doc-pdf-xmlroff: $(xml_sources) doc-fo
|
||||
@echo "Generating pdf xmlroff files..."
|
||||
$(XMLROFF) $(XMLROFF_FLAGS) ${glibcxx_builddir}/doc/fo/spine.fo
|
||||
doc-pdf-prince: $(xml_sources) ${glibcxx_builddir}/doc/pdf
|
||||
@echo "Generating pdf prince files..."
|
||||
$(PRINCE) $(PRINCE_FLAGS) ${top_srcdir}/doc/xml/spine.xml
|
||||
doc-pdf-dblatex: $(xml_sources) ${glibcxx_builddir}/doc/pdf
|
||||
@echo "Generating pdf dblatex files..."
|
||||
dblatex $(DBLATEX_FLAGS) ${top_srcdir}/doc/xml/spine.xml
|
||||
|
||||
.PHONY: doc-doxygen-html doc-doxygen-man doc-performance
|
||||
|
||||
# To remove directories.
|
||||
clean-local:
|
||||
rm -rf man html pdf fo doxygen xml
|
||||
rm -rf man html pdf fo xml doxygen docbook
|
||||
|
||||
# Tell versions [3.59,3.63) of GNU make to not export all variables.
|
||||
# Otherwise a system limit (for SysV at least) may be exceeded.
|
||||
|
@ -400,7 +400,7 @@
|
||||
<para>
|
||||
If the only functions from <filename>libstdc++.a</filename>
|
||||
which you need are language support functions (those listed in
|
||||
<link linkend="manual.support">clause 18</link> of the
|
||||
<link linkend="std.support">clause 18</link> of the
|
||||
standard, e.g., <function>new</function> and
|
||||
<function>delete</function>), then try linking against
|
||||
<filename>libsupc++.a</filename>, which is a subset of
|
||||
@ -896,7 +896,7 @@
|
||||
<para>
|
||||
More information, including how to optionally enable/disable the
|
||||
checks, is available
|
||||
<link linkend="manual.diagnostics.concept_checking">here</link>.
|
||||
<link linkend="std.diagnostics.concept_checking">here</link>.
|
||||
</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
@ -962,7 +962,7 @@
|
||||
<answer id="a-list_size_on">
|
||||
<para>
|
||||
See
|
||||
the <link linkend="manual.containers">Containers</link>
|
||||
the <link linkend="std.containers">Containers</link>
|
||||
chapter.
|
||||
</para>
|
||||
</answer>
|
||||
|
@ -1,12 +1,12 @@
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
[ ]>
|
||||
|
||||
<part id="manual.algorithms" xreflabel="Algorithms">
|
||||
<chapter id="std.algorithms" xreflabel="Algorithms">
|
||||
<?dbhtml filename="algorithms.html"?>
|
||||
|
||||
<partinfo>
|
||||
|
||||
<chapterinfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
ISO C++
|
||||
@ -18,71 +18,69 @@
|
||||
algorithm
|
||||
</keyword>
|
||||
</keywordset>
|
||||
</partinfo>
|
||||
</chapterinfo>
|
||||
|
||||
<title>
|
||||
Algorithms
|
||||
<indexterm><primary>Algorithms</primary></indexterm>
|
||||
</title>
|
||||
|
||||
<preface>
|
||||
<title></title>
|
||||
<para>
|
||||
The neatest accomplishment of the algorithms chapter is that all the
|
||||
The neatest accomplishment of the algorithms sect1 is that all the
|
||||
work is done via iterators, not containers directly. This means two
|
||||
important things:
|
||||
</para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Anything that behaves like an iterator can be used in one of
|
||||
these algorithms. Raw pointers make great candidates, thus
|
||||
built-in arrays are fine containers, as well as your own iterators.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The algorithms do not (and cannot) affect the container as a
|
||||
whole; only the things between the two iterator endpoints. If
|
||||
you pass a range of iterators only enclosing the middle third of
|
||||
a container, then anything outside that range is inviolate.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
<para>
|
||||
Even strings can be fed through the algorithms here, although the
|
||||
string class has specialized versions of many of these functions
|
||||
(for example, <code>string::find()</code>). Most of the examples
|
||||
on this page will use simple arrays of integers as a playground
|
||||
for algorithms, just to keep things simple. The use of
|
||||
<emphasis>N</emphasis> as a size in the examples is to keep
|
||||
things easy to read but probably won't be valid code. You can
|
||||
use wrappers such as those described in the <link
|
||||
linkend="manual.containers">containers chapter</link> to
|
||||
keep real code readable.
|
||||
</para>
|
||||
<para>
|
||||
The single thing that trips people up the most is the definition
|
||||
of <emphasis>range</emphasis> used with iterators; the famous
|
||||
"past-the-end" rule that everybody loves to hate. The
|
||||
<link linkend="manual.iterators">iterators
|
||||
chapter</link> of this document has a complete explanation of
|
||||
this simple rule that seems to cause so much confusion. Once you
|
||||
get <emphasis>range</emphasis> into your head (it's not that
|
||||
hard, honest!), then the algorithms are a cakewalk.
|
||||
</para>
|
||||
</preface>
|
||||
<listitem>
|
||||
<para>
|
||||
Anything that behaves like an iterator can be used in one of
|
||||
these algorithms. Raw pointers make great candidates, thus
|
||||
built-in arrays are fine containers, as well as your own
|
||||
iterators.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The algorithms do not (and cannot) affect the container as a
|
||||
whole; only the things between the two iterator endpoints. If
|
||||
you pass a range of iterators only enclosing the middle third of
|
||||
a container, then anything outside that range is inviolate.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
<para>
|
||||
Even strings can be fed through the algorithms here, although the
|
||||
string class has specialized versions of many of these functions
|
||||
(for example, <code>string::find()</code>). Most of the examples
|
||||
on this page will use simple arrays of integers as a playground
|
||||
for algorithms, just to keep things simple. The use of
|
||||
<emphasis>N</emphasis> as a size in the examples is to keep things
|
||||
easy to read but probably won't be valid code. You can use wrappers
|
||||
such as those described in
|
||||
the <link linkend="std.containers">containers sect1</link> to keep
|
||||
real code readable.
|
||||
</para>
|
||||
<para>
|
||||
The single thing that trips people up the most is the definition
|
||||
of <emphasis>range</emphasis> used with iterators; the famous
|
||||
"past-the-end" rule that everybody loves to hate. The
|
||||
<link linkend="std.iterators">iterators sect1</link> of this
|
||||
document has a complete explanation of this simple rule that seems
|
||||
to cause so much confusion. Once you
|
||||
get <emphasis>range</emphasis> into your head (it's not that hard,
|
||||
honest!), then the algorithms are a cakewalk.
|
||||
</para>
|
||||
|
||||
<!-- Chapter 01 : Non Modifying -->
|
||||
<!-- Sect1 01 : Non Modifying -->
|
||||
|
||||
<!-- Chapter 02 : Mutating -->
|
||||
<chapter id="manual.algorithms.mutating" xreflabel="Mutating">
|
||||
<!-- Sect1 02 : Mutating -->
|
||||
<sect1 id="std.algorithms.mutating" xreflabel="Mutating">
|
||||
<title>Mutating</title>
|
||||
|
||||
<sect1 id="algorithms.mutating.swap" xreflabel="swap">
|
||||
<sect2 id="algorithms.mutating.swap" xreflabel="swap">
|
||||
<title><function>swap</function></title>
|
||||
|
||||
<sect2 id="algorithms.swap.specializations" xreflabel="Specializations">
|
||||
<sect3 id="algorithms.swap.specializations" xreflabel="Specializations">
|
||||
<title>Specializations</title>
|
||||
|
||||
<para>If you call <code> std::swap(x,y); </code> where x and y are standard
|
||||
@ -98,10 +96,10 @@
|
||||
internal pointers to storage need to be exchanged.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
</sect3>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<!-- Sect1 03 : Sorting -->
|
||||
|
||||
</chapter>
|
||||
|
||||
<!-- Chapter 03 : Sorting -->
|
||||
|
||||
</part>
|
||||
|
@ -1,7 +1,7 @@
|
||||
<sect1 id="manual.util.memory.allocator" xreflabel="Allocator">
|
||||
<section id="std.util.memory.allocator" xreflabel="Allocator">
|
||||
<?dbhtml filename="allocator.html"?>
|
||||
|
||||
<sect1info>
|
||||
<sectioninfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
ISO C++
|
||||
@ -10,7 +10,7 @@
|
||||
allocator
|
||||
</keyword>
|
||||
</keywordset>
|
||||
</sect1info>
|
||||
</sectioninfo>
|
||||
|
||||
<title>Allocators</title>
|
||||
|
||||
@ -24,7 +24,7 @@
|
||||
management classes.
|
||||
</para>
|
||||
|
||||
<sect2 id="allocator.req">
|
||||
<section id="allocator.req">
|
||||
<title>Requirements</title>
|
||||
|
||||
<para>
|
||||
@ -85,9 +85,9 @@
|
||||
<constant>[20.4 Memory]</constant>.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<sect2 id="allocator.design_issues">
|
||||
<section id="allocator.design_issues">
|
||||
<title>Design Issues</title>
|
||||
|
||||
<para>
|
||||
@ -136,12 +136,12 @@
|
||||
<function>abi::__cxa_atexit</function> is not recommended.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<sect2 id="allocator.impl">
|
||||
<section id="allocator.impl">
|
||||
<title>Implementation</title>
|
||||
|
||||
<sect3>
|
||||
<section>
|
||||
<title>Interface Design</title>
|
||||
|
||||
<para>
|
||||
@ -163,9 +163,9 @@
|
||||
may not be user-configurable.
|
||||
</para>
|
||||
|
||||
</sect3>
|
||||
</section>
|
||||
|
||||
<sect3>
|
||||
<section>
|
||||
<title>Selecting Default Allocation Policy</title>
|
||||
|
||||
<para>
|
||||
@ -229,9 +229,9 @@
|
||||
<classname>__gnu_cxx::new_allocator</classname>.
|
||||
</para>
|
||||
|
||||
</sect3>
|
||||
</section>
|
||||
|
||||
<sect3>
|
||||
<section>
|
||||
<title>Disabling Memory Caching</title>
|
||||
|
||||
<para>
|
||||
@ -281,11 +281,11 @@
|
||||
cached allocations...).
|
||||
</para>
|
||||
|
||||
</sect3>
|
||||
</section>
|
||||
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<sect2 id="allocator.using">
|
||||
<section id="allocator.using">
|
||||
<title>Using a Specific Allocator</title>
|
||||
|
||||
<para>
|
||||
@ -303,9 +303,9 @@
|
||||
<programlisting>
|
||||
std::deque <int, __gnu_cxx::debug_allocator<std::allocator<int> > > debug_deque;
|
||||
</programlisting>
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<sect2 id="allocator.custom">
|
||||
<section id="allocator.custom">
|
||||
<title>Custom Allocators</title>
|
||||
|
||||
<para>
|
||||
@ -321,9 +321,9 @@
|
||||
<classname>new_allocator</classname>.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<sect2 id="allocator.ext">
|
||||
<section id="allocator.ext">
|
||||
<title>Extension Allocators</title>
|
||||
|
||||
<para>
|
||||
@ -489,7 +489,7 @@
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
|
||||
<bibliography id="allocator.biblio">
|
||||
@ -615,4 +615,4 @@
|
||||
</biblioentry>
|
||||
</bibliography>
|
||||
|
||||
</sect1>
|
||||
</section>
|
||||
|
@ -1,6 +1,6 @@
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
[ ]>
|
||||
|
||||
<appendix id="appendix.contrib" xreflabel="Contributing">
|
||||
@ -25,7 +25,7 @@
|
||||
</indexterm>
|
||||
</title>
|
||||
|
||||
<para>
|
||||
<para>
|
||||
The GNU C++ Library follows an open development model. Active
|
||||
contributors are assigned maintainer-ship responsibility, and given
|
||||
write access to the source repository. First time contributors
|
||||
@ -40,7 +40,7 @@
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<para>
|
||||
Get and read the relevant sections of the C++ language
|
||||
specification. Copies of the full ISO 14882 standard are
|
||||
available on line via the ISO mirror site for committee
|
||||
@ -50,14 +50,14 @@
|
||||
the standard from their respective national standards
|
||||
organization. In the USA, this national standards
|
||||
organization is ANSI and their web-site is right
|
||||
<ulink url="http://www.ansi.org">here.</ulink>
|
||||
(And if you've already registered with them, clicking this link will take you to directly to the place where you can
|
||||
<ulink url="http://www.ansi.org">here.</ulink>
|
||||
(And if you've already registered with them, clicking this link will take you to directly to the place where you can
|
||||
<ulink url="http://webstore.ansi.org/RecordDetail.aspx?sku=ISO%2FIEC+14882:2003">buy the standard on-line.)</ulink>
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<para>
|
||||
The library working group bugs, and known defects, can
|
||||
be obtained here:
|
||||
<ulink url="http://www.open-std.org/jtc1/sc22/wg21/">http://www.open-std.org/jtc1/sc22/wg21 </ulink>
|
||||
@ -65,7 +65,7 @@
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<para>
|
||||
The newsgroup dedicated to standardization issues is
|
||||
comp.std.c++: this FAQ for this group is quite useful and
|
||||
can be
|
||||
@ -75,7 +75,7 @@
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<para>
|
||||
Peruse
|
||||
the <ulink url="http://www.gnu.org/prep/standards">GNU
|
||||
Coding Standards</ulink>, and chuckle when you hit the part
|
||||
@ -84,7 +84,7 @@
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<para>
|
||||
Be familiar with the extensions that preceded these
|
||||
general GNU rules. These style issues for libstdc++ can be
|
||||
found <link linkend="contrib.coding_style">here</link>.
|
||||
@ -92,7 +92,7 @@
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<para>
|
||||
And last but certainly not least, read the
|
||||
library-specific information
|
||||
found <link linkend="appendix.porting"> here</link>.
|
||||
@ -107,10 +107,10 @@
|
||||
Small changes can be accepted without a copyright assignment form on
|
||||
file. New code and additions to the library need completed copyright
|
||||
assignment form on file at the FSF. Note: your employer may be required
|
||||
to fill out appropriate disclaimer forms as well.
|
||||
to fill out appropriate disclaimer forms as well.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<para>
|
||||
Historically, the libstdc++ assignment form added the following
|
||||
question:
|
||||
</para>
|
||||
@ -128,7 +128,7 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For more information about getting a copyright assignment, please see
|
||||
For more information about getting a copyright assignment, please see
|
||||
<ulink url="http://www.gnu.org/prep/maintain/html_node/Legal-Matters.html">Legal
|
||||
Matters</ulink>.
|
||||
</para>
|
||||
@ -162,34 +162,34 @@
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<para>
|
||||
A description of the bug and how your patch fixes this
|
||||
bug. For new features a description of the feature and your
|
||||
implementation.
|
||||
implementation.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<para>
|
||||
A ChangeLog entry as plain text; see the various
|
||||
ChangeLog files for format and content. If you are
|
||||
using emacs as your editor, simply position the insertion
|
||||
point at the beginning of your change and hit CX-4a to bring
|
||||
up the appropriate ChangeLog entry. See--magic! Similar
|
||||
functionality also exists for vi.
|
||||
functionality also exists for vi.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<para>
|
||||
A testsuite submission or sample program that will
|
||||
easily and simply show the existing error or test new
|
||||
functionality.
|
||||
functionality.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<para>
|
||||
The patch itself. If you are accessing the SVN
|
||||
repository use <command>svn update; svn diff NEW</command>;
|
||||
else, use <command>diff -cp OLD NEW</command> ... If your
|
||||
@ -202,13 +202,13 @@
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<para>
|
||||
When you have all these pieces, bundle them up in a
|
||||
mail message and send it to libstdc++@gcc.gnu.org. All
|
||||
patches and related discussion should be sent to the
|
||||
libstdc++ mailing list.
|
||||
libstdc++ mailing list.
|
||||
</para>
|
||||
</listitem>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</sect2>
|
||||
@ -218,7 +218,7 @@
|
||||
<sect1 id="contrib.organization" xreflabel="Source Organization">
|
||||
<?dbhtml filename="source_organization.html"?>
|
||||
<title>Directory Layout and Source Conventions</title>
|
||||
|
||||
|
||||
<para>
|
||||
The unpacked source directory of libstdc++ contains the files
|
||||
needed to create the GNU C++ Library.
|
||||
@ -238,26 +238,26 @@ It has subdirectories:
|
||||
|
||||
include/std
|
||||
Files meant to be found by #include <name> directives in
|
||||
standard-conforming user programs.
|
||||
standard-conforming user programs.
|
||||
|
||||
include/c
|
||||
Headers intended to directly include standard C headers.
|
||||
Headers intended to directly include standard C headers.
|
||||
[NB: this can be enabled via --enable-cheaders=c]
|
||||
|
||||
include/c_global
|
||||
include/c_global
|
||||
Headers intended to include standard C headers in
|
||||
the global namespace, and put select names into the std::
|
||||
namespace. [NB: this is the default, and is the same as
|
||||
--enable-cheaders=c_global]
|
||||
|
||||
include/c_std
|
||||
include/c_std
|
||||
Headers intended to include standard C headers
|
||||
already in namespace std, and put select names into the std::
|
||||
namespace. [NB: this is the same as --enable-cheaders=c_std]
|
||||
|
||||
include/bits
|
||||
Files included by standard headers and by other files in
|
||||
the bits directory.
|
||||
the bits directory.
|
||||
|
||||
include/backward
|
||||
Headers provided for backward compatibility, such as <iostream.h>.
|
||||
@ -276,7 +276,7 @@ It has subdirectories:
|
||||
installed.
|
||||
|
||||
testsuites/[backward, demangle, ext, performance, thread, 17_* to 27_*]
|
||||
Test programs are here, and may be used to begin to exercise the
|
||||
Test programs are here, and may be used to begin to exercise the
|
||||
library. Support for "make check" and "make check-install" is
|
||||
complete, and runs through all the subdirectories here when this
|
||||
command is issued from the build directory. Please note that
|
||||
@ -378,7 +378,7 @@ indicate a place that may require attention for multi-thread safety.
|
||||
these names as operators have been fixed.]
|
||||
|
||||
The full set of __* identifiers (combined from gcc/cp/lex.c and
|
||||
gcc/cplus-dem.c) that are either old or new, but are definitely
|
||||
gcc/cplus-dem.c) that are either old or new, but are definitely
|
||||
recognized by the demangler, is:
|
||||
|
||||
__aa
|
||||
@ -548,8 +548,8 @@ indicate a place that may require attention for multi-thread safety.
|
||||
-NOT-
|
||||
char *p = "flop"; // wrong
|
||||
char &c = *p; // wrong
|
||||
|
||||
Reason: In C++, definitions are mixed with executable code. Here,
|
||||
|
||||
Reason: In C++, definitions are mixed with executable code. Here,
|
||||
p is being initialized, not *p. This is near-universal
|
||||
practice among C++ programmers; it is normal for C hackers
|
||||
to switch spontaneously as they gain experience.
|
||||
@ -558,9 +558,9 @@ indicate a place that may require attention for multi-thread safety.
|
||||
operator==(type)
|
||||
-NOT-
|
||||
operator == (type) // wrong
|
||||
|
||||
|
||||
Reason: The == is part of the function name. Separating
|
||||
it makes the declaration look like an expression.
|
||||
it makes the declaration look like an expression.
|
||||
|
||||
03. Function names and parentheses
|
||||
void mangle()
|
||||
@ -569,22 +569,22 @@ indicate a place that may require attention for multi-thread safety.
|
||||
|
||||
Reason: no space before parentheses (except after a control-flow
|
||||
keyword) is near-universal practice for C++. It identifies the
|
||||
parentheses as the function-call operator or declarator, as
|
||||
parentheses as the function-call operator or declarator, as
|
||||
opposed to an expression or other overloaded use of parentheses.
|
||||
|
||||
04. Template function indentation
|
||||
template<typename T>
|
||||
void
|
||||
void
|
||||
template_function(args)
|
||||
{ }
|
||||
-NOT-
|
||||
template<class T>
|
||||
void template_function(args) {};
|
||||
|
||||
|
||||
Reason: In class definitions, without indentation whitespace is
|
||||
needed both above and below the declaration to distinguish
|
||||
it visually from other members. (Also, re: "typename"
|
||||
rather than "class".) T often could be int, which is
|
||||
rather than "class".) T often could be int, which is
|
||||
not a class. ("class", here, is an anachronism.)
|
||||
|
||||
05. Template class indentation
|
||||
@ -622,7 +622,7 @@ indicate a place that may require attention for multi-thread safety.
|
||||
07. Member initialization lists
|
||||
All one line, separate from class name.
|
||||
|
||||
gribble::gribble()
|
||||
gribble::gribble()
|
||||
: _M_private_data(0), _M_more_stuff(0), _M_helper(0);
|
||||
{ }
|
||||
-NOT-
|
||||
@ -630,18 +630,18 @@ indicate a place that may require attention for multi-thread safety.
|
||||
{ }
|
||||
|
||||
08. Try/Catch blocks
|
||||
try
|
||||
try
|
||||
{
|
||||
//
|
||||
}
|
||||
}
|
||||
catch (...)
|
||||
{
|
||||
//
|
||||
}
|
||||
}
|
||||
-NOT-
|
||||
try {
|
||||
//
|
||||
} catch(...) {
|
||||
//
|
||||
} catch(...) {
|
||||
//
|
||||
}
|
||||
|
||||
@ -649,7 +649,7 @@ indicate a place that may require attention for multi-thread safety.
|
||||
Keywords such as extern, static, export, explicit, inline, etc
|
||||
go on the line above the function name. Thus
|
||||
|
||||
virtual int
|
||||
virtual int
|
||||
foo()
|
||||
-NOT-
|
||||
virtual int foo()
|
||||
@ -692,7 +692,7 @@ indicate a place that may require attention for multi-thread safety.
|
||||
|
||||
-NOT-
|
||||
public:
|
||||
|
||||
|
||||
int foo;
|
||||
|
||||
13. Spacing WRT return statements.
|
||||
@ -751,17 +751,17 @@ indicate a place that may require attention for multi-thread safety.
|
||||
|
||||
Name patterns:
|
||||
|
||||
For nonstandard names appearing in Standard headers, we are constrained
|
||||
For nonstandard names appearing in Standard headers, we are constrained
|
||||
to use names that begin with underscores. This is called "uglification".
|
||||
The convention is:
|
||||
|
||||
Local and argument names: __[a-z].*
|
||||
|
||||
Examples: __count __ix __s1
|
||||
Examples: __count __ix __s1
|
||||
|
||||
Type names and template formal-argument names: _[A-Z][^_].*
|
||||
|
||||
Examples: _Helper _CharT _N
|
||||
Examples: _Helper _CharT _N
|
||||
|
||||
Member data and function names: _M_.*
|
||||
|
||||
@ -771,7 +771,7 @@ indicate a place that may require attention for multi-thread safety.
|
||||
|
||||
Examples: _S_max_elements _S_default_value
|
||||
|
||||
Don't use names in the same scope that differ only in the prefix,
|
||||
Don't use names in the same scope that differ only in the prefix,
|
||||
e.g. _S_top and _M_top. See BADNAMES for a list of forbidden names.
|
||||
(The most tempting of these seem to be and "_T" and "__sz".)
|
||||
|
||||
@ -781,7 +781,7 @@ indicate a place that may require attention for multi-thread safety.
|
||||
--------------------------
|
||||
|
||||
[BY EXAMPLE]
|
||||
|
||||
|
||||
#ifndef _HEADER_
|
||||
#define _HEADER_ 1
|
||||
|
||||
@ -794,37 +794,37 @@ indicate a place that may require attention for multi-thread safety.
|
||||
|
||||
gribble(const gribble&);
|
||||
|
||||
explicit
|
||||
explicit
|
||||
gribble(int __howmany);
|
||||
|
||||
gribble&
|
||||
gribble&
|
||||
operator=(const gribble&);
|
||||
|
||||
virtual
|
||||
virtual
|
||||
~gribble() throw ();
|
||||
|
||||
// Start with a capital letter, end with a period.
|
||||
inline void
|
||||
inline void
|
||||
public_member(const char* __arg) const;
|
||||
|
||||
// In-class function definitions should be restricted to one-liners.
|
||||
int
|
||||
int
|
||||
one_line() { return 0 }
|
||||
|
||||
int
|
||||
two_lines(const char* arg)
|
||||
int
|
||||
two_lines(const char* arg)
|
||||
{ return strchr(arg, 'a'); }
|
||||
|
||||
inline int
|
||||
inline int
|
||||
three_lines(); // inline, but defined below.
|
||||
|
||||
// Note indentation.
|
||||
template<typename _Formal_argument>
|
||||
void
|
||||
void
|
||||
public_template() const throw();
|
||||
|
||||
template<typename _Iterator>
|
||||
void
|
||||
void
|
||||
other_template();
|
||||
|
||||
private:
|
||||
@ -835,13 +835,13 @@ indicate a place that may require attention for multi-thread safety.
|
||||
_Helper* _M_helper;
|
||||
int _M_private_function();
|
||||
|
||||
enum _Enum
|
||||
{
|
||||
_S_one,
|
||||
_S_two
|
||||
enum _Enum
|
||||
{
|
||||
_S_one,
|
||||
_S_two
|
||||
};
|
||||
|
||||
static void
|
||||
static void
|
||||
_S_initialize_library();
|
||||
};
|
||||
|
||||
@ -871,20 +871,20 @@ indicate a place that may require attention for multi-thread safety.
|
||||
#endif /* _HEADER_ */
|
||||
|
||||
|
||||
namespace std
|
||||
namespace std
|
||||
{
|
||||
template<typename T> // notice: "typename", not "class", no space
|
||||
long_return_value_type<with_many, args>
|
||||
long_return_value_type<with_many, args>
|
||||
function_name(char* pointer, // "char *pointer" is wrong.
|
||||
char* argument,
|
||||
char* argument,
|
||||
const Reference& ref)
|
||||
{
|
||||
// int a_local; /* wrong; see below. */
|
||||
if (test)
|
||||
{
|
||||
nested code
|
||||
if (test)
|
||||
{
|
||||
nested code
|
||||
}
|
||||
|
||||
|
||||
int a_local = 0; // declare variable at first use.
|
||||
|
||||
// char a, b, *p; /* wrong */
|
||||
@ -897,12 +897,12 @@ indicate a place that may require attention for multi-thread safety.
|
||||
// ...
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
gribble::gribble()
|
||||
: _M_private_data(0), _M_more_stuff(0), _M_helper(0);
|
||||
{ }
|
||||
|
||||
inline int
|
||||
inline int
|
||||
gribble::three_lines()
|
||||
{
|
||||
// doesn't fit in one line.
|
||||
@ -910,7 +910,7 @@ indicate a place that may require attention for multi-thread safety.
|
||||
} // namespace std
|
||||
</literallayout>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="contrib.doc_style" xreflabel="Documentation Style">
|
||||
<?dbhtml filename="documentation_style.html"?>
|
||||
@ -932,7 +932,7 @@ indicate a place that may require attention for multi-thread safety.
|
||||
To generate the pretty pictures and hierarchy
|
||||
graphs, the
|
||||
<ulink url="http://www.graphviz.org">Graphviz</ulink>
|
||||
package will need to be installed.
|
||||
package will need to be installed.
|
||||
</para>
|
||||
</sect3>
|
||||
|
||||
@ -1022,7 +1022,7 @@ indicate a place that may require attention for multi-thread safety.
|
||||
<listitem>
|
||||
<para>
|
||||
Use the triple-slash style only for one-line comments (the
|
||||
<quote>brief</quote> mode).
|
||||
<quote>brief</quote> mode).
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -1032,7 +1032,7 @@ indicate a place that may require attention for multi-thread safety.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
|
||||
<para>
|
||||
Some specific guidelines:
|
||||
</para>
|
||||
@ -1071,7 +1071,7 @@ indicate a place that may require attention for multi-thread safety.
|
||||
* @brief A model of a linear congruential random number generator.
|
||||
*
|
||||
* @f[
|
||||
* x_{i+1}\leftarrow(ax_{i} + c) \bmod m
|
||||
* x_{i+1}\leftarrow(ax_{i} + c) \bmod m
|
||||
* @f]
|
||||
*/
|
||||
</literallayout>
|
||||
@ -1207,11 +1207,11 @@ indicate a place that may require attention for multi-thread safety.
|
||||
consult the <email>libstdc++@gcc.gnu.org</email> list when
|
||||
preparing printed manuals for current best practice and suggestions.
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
Make sure that the XML documentation and markup is valid for
|
||||
any change. This can be done easily, with the validation rules
|
||||
in the <filename>Makefile</filename>, which is equivalent to doing:
|
||||
in the <filename>Makefile</filename>, which is equivalent to doing:
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
@ -1226,25 +1226,25 @@ xmllint --noout --valid <filename>xml/index.xml</filename>
|
||||
|
||||
<para>
|
||||
The following Makefile rules generate (in order): an HTML
|
||||
version of all the documentation, a PDF version of the same, a
|
||||
version of all the DocBook documentation, a PDF version of the same, a
|
||||
single XML document, and the result of validating the entire XML
|
||||
document.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen><userinput>make doc-html</userinput></screen>
|
||||
<screen><userinput>make doc-html-docbook</userinput></screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen><userinput>make doc-pdf</userinput></screen>
|
||||
<screen><userinput>make doc-pdf-docbook</userinput></screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen><userinput>make doc-xml-single</userinput></screen>
|
||||
<screen><userinput>make doc-xml-single-docbook</userinput></screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen><userinput>make doc-xml-validate</userinput></screen>
|
||||
<screen><userinput>make doc-xml-validate-docbook</userinput></screen>
|
||||
</para>
|
||||
|
||||
</sect3>
|
||||
@ -1259,11 +1259,11 @@ xmllint --noout --valid <filename>xml/index.xml</filename>
|
||||
libstdc++-v3/doc/xml
|
||||
|
||||
Inside this directory, the files of importance:
|
||||
spine.xml - index to documentation set
|
||||
spine.xml - index to documentation set
|
||||
manual/spine.xml - index to manual
|
||||
manual/*.xml - individual chapters and sections of the manual
|
||||
faq.xml - index to FAQ
|
||||
api.xml - index to source level / API
|
||||
api.xml - index to source level / API
|
||||
|
||||
All *.txml files are template xml files, i.e., otherwise empty files with
|
||||
the correct structure, suitable for filling in with new information.
|
||||
@ -1291,7 +1291,7 @@ xmllint --noout --valid <filename>xml/index.xml</filename>
|
||||
</chapter>
|
||||
</book>
|
||||
|
||||
<book>
|
||||
<book>
|
||||
<part>
|
||||
<chapter>
|
||||
<section>
|
||||
@ -1308,7 +1308,7 @@ xmllint --noout --valid <filename>xml/index.xml</filename>
|
||||
|
||||
<chapter>
|
||||
</chapter>
|
||||
</part>
|
||||
</part>
|
||||
</book>
|
||||
|
||||
</set>
|
||||
@ -1321,7 +1321,7 @@ xmllint --noout --valid <filename>xml/index.xml</filename>
|
||||
<para>
|
||||
Complete details on Docbook markup can be found in the DocBook
|
||||
Element Reference,
|
||||
<ulink url="http://www.docbook.org/tdg/en/html/part2.html">online</ulink>.
|
||||
<ulink url="http://www.docbook.org/tdg/en/html/part2.html">online</ulink>.
|
||||
An incomplete reference for HTML to Docbook conversion is
|
||||
detailed in the table below.
|
||||
</para>
|
||||
@ -1346,7 +1346,7 @@ xmllint --noout --valid <filename>xml/index.xml</filename>
|
||||
</row>
|
||||
<row>
|
||||
<entry><pre></entry>
|
||||
<entry><computeroutput>, <programlisting>,
|
||||
<entry><computeroutput>, <programlisting>,
|
||||
<literallayout></entry>
|
||||
</row>
|
||||
<row>
|
||||
@ -1477,7 +1477,45 @@ xmllint --noout --valid <filename>xml/index.xml</filename>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
<sect2 id="doc_style.combines">
|
||||
<title>Combines</title>
|
||||
|
||||
<sect3 id="combines.rules">
|
||||
<title>Generating Combines and Assemblages</title>
|
||||
|
||||
<para>
|
||||
The following Makefile rules are defaults, and are usually
|
||||
aliased to variable rules.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen><userinput>make doc-html</userinput></screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen><userinput>make doc-man</userinput></screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen><userinput>make doc-pdf</userinput></screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following Makefile rules generate (in order): an HTML
|
||||
version of all the DocBook documentation with links into an
|
||||
local Doxygen cache, and a PDF version of the same.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen><userinput>make doc-html-combine</userinput></screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen><userinput>make doc-pdf-combine</userinput></screen>
|
||||
</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="contrib.design_notes" xreflabel="Design Notes">
|
||||
<?dbhtml filename="source_design_notes.html"?>
|
||||
@ -2339,6 +2377,6 @@ xmllint --noout --valid <filename>xml/index.xml</filename>
|
||||
include them via "<backward/hash_map.h>" or "<ext/hash_map>" than
|
||||
to search the subdirectory itself via a "-I" directive.
|
||||
</literallayout>
|
||||
</sect1>
|
||||
</sect1>
|
||||
|
||||
</appendix>
|
||||
|
@ -1,6 +1,6 @@
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
[ ]>
|
||||
|
||||
<appendix id="appendix.free" xreflabel="Free">
|
||||
@ -64,7 +64,7 @@ Given that writing good English is a rare skill among programmers, we
|
||||
can ill afford to lose manuals this way.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<para>
|
||||
Free documentation, like free software, is a matter of freedom,
|
||||
not price. The problem with these manuals was not that O'Reilly
|
||||
Associates charged a price for printed copies--that in itself is fine.
|
||||
@ -170,7 +170,7 @@ prefer copylefted manuals to non-copylefted ones.
|
||||
[Note: We now maintain a <ulink url="http://www.fsf.org/licensing/doc/other-free-books.html">web page
|
||||
that lists free books available from other publishers</ulink>].
|
||||
</para>
|
||||
|
||||
|
||||
<para>Copyright © 2004, 2005, 2006, 2007 Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA</para>
|
||||
|
||||
<para>Verbatim copying and distribution of this entire article are
|
||||
|
@ -1,11 +1,11 @@
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
[ ]>
|
||||
|
||||
<appendix id="appendix.porting" xreflabel="Porting">
|
||||
<?dbhtml filename="appendix_porting.html"?>
|
||||
|
||||
|
||||
<appendixinfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
@ -26,32 +26,32 @@
|
||||
</title>
|
||||
|
||||
<!-- Hacking the Build System -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="build_hacking.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Internals: Porting to New Hardware or Operating Systems -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="internals.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Test -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="test.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- ABI Policy and Guidelines -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="abi.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- API Evolution and Deprecation History -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="evolution.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Backwards Compatibility -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="backwards_compatibility.xml">
|
||||
</xi:include>
|
||||
|
||||
|
@ -1,7 +1,7 @@
|
||||
<sect1 id="manual.util.memory.auto_ptr" xreflabel="auto_ptr">
|
||||
<section id="std.util.memory.auto_ptr" xreflabel="auto_ptr">
|
||||
<?dbhtml filename="auto_ptr.html"?>
|
||||
|
||||
<sect1info>
|
||||
|
||||
<sectioninfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
ISO C++
|
||||
@ -10,11 +10,11 @@
|
||||
auto_ptr
|
||||
</keyword>
|
||||
</keywordset>
|
||||
</sect1info>
|
||||
</sectioninfo>
|
||||
|
||||
<title>auto_ptr</title>
|
||||
|
||||
<sect2 id="auto_ptr.limitations">
|
||||
<section id="auto_ptr.limitations">
|
||||
<title>Limitations</title>
|
||||
|
||||
<para>Explaining all of the fun and delicious things that can
|
||||
@ -48,11 +48,11 @@
|
||||
|
||||
void func (int data)
|
||||
{
|
||||
APMC ap (new MyClass(data));
|
||||
APMC ap (new MyClass(data));
|
||||
|
||||
some_throwable_function(); // this will throw an exception
|
||||
some_throwable_function(); // this will throw an exception
|
||||
|
||||
function_taking_MyClass_pointer (ap.get());
|
||||
function_taking_MyClass_pointer (ap.get());
|
||||
}
|
||||
</programlisting>
|
||||
<para>When an exception gets thrown, the instance of MyClass that's
|
||||
@ -62,15 +62,15 @@
|
||||
<para>Changing that code as follows is not <acronym>AP</acronym>-friendly:
|
||||
</para>
|
||||
<programlisting>
|
||||
APMC ap (new MyClass[22]);
|
||||
APMC ap (new MyClass[22]);
|
||||
</programlisting>
|
||||
<para>You will get the same problems as you would without the use
|
||||
of <acronym>AP</acronym>:
|
||||
</para>
|
||||
<programlisting>
|
||||
char* array = new char[10]; // array new...
|
||||
...
|
||||
delete array; // ...but single-object delete
|
||||
char* array = new char[10]; // array new...
|
||||
...
|
||||
delete array; // ...but single-object delete
|
||||
</programlisting>
|
||||
<para>
|
||||
AP cannot tell whether the pointer you've passed at creation points
|
||||
@ -79,21 +79,21 @@
|
||||
own <code>auto_array_ptr</code> for that situation (in fact, this has
|
||||
been done many times; check the mailing lists, Usenet, Boost, etc).
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="auto_ptr.using">
|
||||
</section>
|
||||
|
||||
<section id="auto_ptr.using">
|
||||
<title>Use in Containers</title>
|
||||
|
||||
<para>
|
||||
</para>
|
||||
<para>All of the <link linkend="manual.containers">containers</link>
|
||||
<para>All of the <link linkend="std.containers">containers</link>
|
||||
described in the standard library require their contained types
|
||||
to have, among other things, a copy constructor like this:
|
||||
</para>
|
||||
<programlisting>
|
||||
struct My_Type
|
||||
{
|
||||
My_Type (My_Type const&);
|
||||
My_Type (My_Type const&);
|
||||
};
|
||||
</programlisting>
|
||||
<para>
|
||||
@ -119,15 +119,15 @@
|
||||
<programlisting>
|
||||
#include <vector>
|
||||
#include <memory>
|
||||
|
||||
|
||||
void f()
|
||||
{
|
||||
std::vector< std::auto_ptr<int> > vec_ap_int;
|
||||
std::vector< std::auto_ptr<int> > vec_ap_int;
|
||||
}
|
||||
</programlisting>
|
||||
<para>
|
||||
Should you try this with the checks enabled, you will see an error.
|
||||
</para>
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
</sect1>
|
||||
</section>
|
||||
|
@ -1,6 +1,6 @@
|
||||
<sect1 id="manual.ext.allocator.bitmap" xreflabel="bitmap_allocator">
|
||||
<?dbhtml filename="bitmap_allocator.html"?>
|
||||
|
||||
|
||||
<sect1info>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
@ -81,7 +81,7 @@
|
||||
the search would go up given an increasing size, for 64 entries
|
||||
however, lg(64) == 6 comparisons are enough to locate the correct
|
||||
free list if it exists.
|
||||
</para>
|
||||
</para>
|
||||
<para>
|
||||
Suppose the free list size has reached it's threshold, then the
|
||||
largest block from among those in the list and the new block will
|
||||
@ -223,7 +223,7 @@ else return false.</para></listitem>
|
||||
|
||||
<sect3 id="bitmap.impl.max_wasted" xreflabel="Max Wasted Percentage">
|
||||
<title>Maximum Wasted Percentage</title>
|
||||
|
||||
|
||||
<para>
|
||||
This has nothing to do with the algorithm per-se,
|
||||
only with some vales that must be chosen correctly to ensure that the
|
||||
@ -328,12 +328,12 @@ For map/multimap: k = 12, and c = 4 (int and double), we get: 37.524%
|
||||
<listitem>
|
||||
<para>
|
||||
Gets more memory from the Global Free List of the Required
|
||||
size.
|
||||
size.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Adjusts the size for the next call to itself.
|
||||
Adjusts the size for the next call to itself.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -344,7 +344,7 @@ For map/multimap: k = 12, and c = 4 (int and double), we get: 37.524%
|
||||
<listitem>
|
||||
<para>
|
||||
Sets the use count for that super-block just allocated to 0
|
||||
(zero).
|
||||
(zero).
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -353,7 +353,7 @@ For map/multimap: k = 12, and c = 4 (int and double), we get: 37.524%
|
||||
for the allocator. If the invariant is maintained, we are
|
||||
sure that all is well. Now, the same process is applied on
|
||||
the newly acquired free blocks, which are dispatched
|
||||
accordingly.
|
||||
accordingly.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
@ -378,7 +378,7 @@ single object allocations.
|
||||
<para>
|
||||
However for n == 1, a series of steps are performed:
|
||||
</para>
|
||||
|
||||
|
||||
<orderedlist>
|
||||
<listitem><para>
|
||||
We first need to locate that super-block which holds the memory
|
||||
@ -504,7 +504,7 @@ Block a bitmap as well?
|
||||
testing, I've decided to keep these bitmaps close to the actual
|
||||
blocks. This will help in 2 ways.
|
||||
</para>
|
||||
|
||||
|
||||
<orderedlist>
|
||||
<listitem><para>Constant time access for the bitmap themselves, since no kind of
|
||||
look up will be needed to find the correct bitmap list or it's
|
||||
@ -555,5 +555,5 @@ equivalent.</para></listitem>
|
||||
</sect3>
|
||||
|
||||
</sect2>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
@ -1,6 +1,6 @@
|
||||
<sect1 id="appendix.porting.build_hacking" xreflabel="Build Hacking">
|
||||
<?dbhtml filename="build_hacking.html"?>
|
||||
|
||||
|
||||
<sect1info>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
@ -25,7 +25,7 @@
|
||||
|
||||
<sect2 id="build_hacking.prereq">
|
||||
<title>Prerequisites</title>
|
||||
<para>
|
||||
<para>
|
||||
As noted <ulink
|
||||
url="http://gcc.gnu.org/install/prerequisites.html">previously</ulink>,
|
||||
certain other tools are necessary for hacking on files that
|
||||
@ -42,7 +42,7 @@
|
||||
|
||||
<sect2 id="build_hacking.map">
|
||||
<title>Overview: What Comes from Where</title>
|
||||
|
||||
|
||||
<screen>
|
||||
<inlinemediaobject>
|
||||
<imageobject>
|
||||
|
@ -1,7 +1,7 @@
|
||||
<sect1 id="manual.localization.facet.codecvt" xreflabel="codecvt">
|
||||
<section id="std.localization.facet.codecvt" xreflabel="codecvt">
|
||||
<?dbhtml filename="codecvt.html"?>
|
||||
|
||||
<sect1info>
|
||||
<sectioninfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
ISO C++
|
||||
@ -10,7 +10,7 @@
|
||||
codecvt
|
||||
</keyword>
|
||||
</keywordset>
|
||||
</sect1info>
|
||||
</sectioninfo>
|
||||
|
||||
<title>codecvt</title>
|
||||
|
||||
@ -30,7 +30,7 @@ specializations for wide and narrow characters and the
|
||||
implementation-provided extended functionality are given.
|
||||
</para>
|
||||
|
||||
<sect2 id="facet.codecvt.req">
|
||||
<section id="facet.codecvt.req">
|
||||
<title>Requirements</title>
|
||||
|
||||
<para>
|
||||
@ -108,12 +108,12 @@ Two: The required conversions, by specifying mbstate_t as the third
|
||||
template parameter, imply an implementation strategy that is mostly
|
||||
(or wholly) based on the underlying C library, and the functions
|
||||
mcsrtombs and wcsrtombs in particular.</para>
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<sect2 id="facet.codecvt.design">
|
||||
<section id="facet.codecvt.design">
|
||||
<title>Design</title>
|
||||
|
||||
<sect3 id="codecvt.design.wchar_t_size">
|
||||
<section id="codecvt.design.wchar_t_size">
|
||||
<title><type>wchar_t</type> Size</title>
|
||||
|
||||
<para>
|
||||
@ -131,9 +131,9 @@ mcsrtombs and wcsrtombs in particular.</para>
|
||||
<para>
|
||||
Thus, portable C++ code cannot assume a byte size (or endianness) either.
|
||||
</para>
|
||||
</sect3>
|
||||
</section>
|
||||
|
||||
<sect3 id="codecvt.design.unicode">
|
||||
<section id="codecvt.design.unicode">
|
||||
<title>Support for Unicode</title>
|
||||
<para>
|
||||
Probably the most frequently asked question about code conversion
|
||||
@ -236,9 +236,9 @@ mechanism may be required.
|
||||
external types will need to be known.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</sect3>
|
||||
</section>
|
||||
|
||||
<sect3 id="codecvt.design.issues">
|
||||
<section id="codecvt.design.issues">
|
||||
<title>Other Issues</title>
|
||||
<para>
|
||||
In addition, multi-threaded and multi-locale environments also impact
|
||||
@ -284,11 +284,11 @@ on GNU/Linux) and whatever the currently selected locale for the
|
||||
LC_CTYPE category implements.
|
||||
</para>
|
||||
|
||||
</sect3>
|
||||
</section>
|
||||
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<sect2 id="facet.codecvt.impl">
|
||||
<section id="facet.codecvt.impl">
|
||||
<title>Implementation</title>
|
||||
|
||||
<para>
|
||||
@ -432,9 +432,9 @@ external character type, encoding_state> is consistent with other
|
||||
codecvt usage.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<sect2 id="facet.codecvt.use">
|
||||
<section id="facet.codecvt.use">
|
||||
<title>Use</title>
|
||||
<para>A conversions involving string literal.</para>
|
||||
|
||||
@ -477,9 +477,9 @@ codecvt usage.
|
||||
VERIFY( ito_next == i_arr + size );
|
||||
</programlisting>
|
||||
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<sect2 id="facet.codecvt.future">
|
||||
<section id="facet.codecvt.future">
|
||||
<title>Future</title>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
@ -532,7 +532,7 @@ codecvt usage.
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
|
||||
<bibliography id="facet.codecvt.biblio">
|
||||
@ -702,4 +702,4 @@ codecvt usage.
|
||||
|
||||
</bibliography>
|
||||
|
||||
</sect1>
|
||||
</section>
|
||||
|
@ -1,6 +1,6 @@
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
[ ]>
|
||||
|
||||
<chapter id="manual.ext.concurrency" xreflabel="Concurrency Extensions">
|
||||
@ -85,7 +85,7 @@ critical sections, while retaining exception-safety.
|
||||
|
||||
|
||||
<para>
|
||||
Two functions and one type form the base of atomic support.
|
||||
Two functions and one type form the base of atomic support.
|
||||
</para>
|
||||
|
||||
|
||||
@ -130,7 +130,7 @@ __atomic_add_dispatch
|
||||
|
||||
<para>
|
||||
These functions forward to one of several specialized helper
|
||||
functions, depending on the circumstances. For instance,
|
||||
functions, depending on the circumstances. For instance,
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -152,7 +152,7 @@ sequence.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem><para><code>__exchange_and_add_single</code>
|
||||
<listitem><para><code>__exchange_and_add_single</code>
|
||||
</para>
|
||||
<para>Single threaded version. Inlined.</para>
|
||||
</listitem>
|
||||
@ -173,12 +173,12 @@ In addition, there are two macros
|
||||
|
||||
<para>
|
||||
<code>
|
||||
_GLIBCXX_READ_MEM_BARRIER
|
||||
_GLIBCXX_READ_MEM_BARRIER
|
||||
</code>
|
||||
</para>
|
||||
<para>
|
||||
<code>
|
||||
_GLIBCXX_WRITE_MEM_BARRIER
|
||||
_GLIBCXX_WRITE_MEM_BARRIER
|
||||
</code>
|
||||
</para>
|
||||
|
||||
@ -195,7 +195,7 @@ host hardware and operating system.
|
||||
<title>Implementation</title>
|
||||
<sect2 id="manual.ext.concurrency.impl.atomic_fallbacks" xreflabel="Atomic F">
|
||||
<title>Using Builtin Atomic Functions</title>
|
||||
|
||||
|
||||
<para>The functions for atomic operations described above are either
|
||||
implemented via compiler intrinsics (if the underlying host is
|
||||
capable) or by library fallbacks.</para>
|
||||
@ -214,7 +214,7 @@ usage vary depending on the target hardware and the flags used during
|
||||
compile.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<para>
|
||||
If builtins are possible for bool-sized integral types,
|
||||
<code>_GLIBCXX_ATOMIC_BUILTINS_1</code> will be defined.
|
||||
If builtins are possible for int-sized integral types,
|
||||
@ -285,7 +285,7 @@ including <code>pthread_t</code>, <code>pthread_once_t</code>, <code>pthread_cre
|
||||
etc.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="manual.ext.concurrency.use" xreflabel="Use">
|
||||
|
@ -1,6 +1,6 @@
|
||||
<sect1 id="manual.intro.setup.configure" xreflabel="Configuring">
|
||||
<?dbhtml filename="configure.html"?>
|
||||
|
||||
|
||||
<sect1info>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
@ -43,71 +43,71 @@
|
||||
<variablelist>
|
||||
<varlistentry><term><code>--enable-multilib</code>[default]</term>
|
||||
<listitem><para>This is part of the generic multilib support for building cross
|
||||
compilers. As such, targets like "powerpc-elf" will have
|
||||
libstdc++ built many different ways: "-msoft-float"
|
||||
and not, etc. A different libstdc++ will be built for each of
|
||||
the different multilib versions. This option is on by default.
|
||||
compilers. As such, targets like "powerpc-elf" will have
|
||||
libstdc++ built many different ways: "-msoft-float"
|
||||
and not, etc. A different libstdc++ will be built for each of
|
||||
the different multilib versions. This option is on by default.
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-sjlj-exceptions</code></term>
|
||||
<listitem><para>Forces old, set-jump/long-jump exception handling model. If
|
||||
at all possible, the new, frame unwinding exception handling routines
|
||||
should be used instead, as they significantly reduce both
|
||||
runtime memory usage and executable size. This option can
|
||||
change the library ABI.
|
||||
at all possible, the new, frame unwinding exception handling routines
|
||||
should be used instead, as they significantly reduce both
|
||||
runtime memory usage and executable size. This option can
|
||||
change the library ABI.
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-version-specific-runtime-libs</code></term>
|
||||
<listitem><para>Specify that run-time libraries should be installed in the
|
||||
compiler-specific subdirectory (i.e.,
|
||||
<code>${libdir}/gcc-lib/${target_alias}/${gcc_version}</code>)
|
||||
instead of <code>${libdir}</code>. This option is useful if you
|
||||
intend to use several versions of gcc in parallel. In addition,
|
||||
libstdc++'s include files will be installed in
|
||||
<code>${libdir}/gcc-lib/${target_alias}/${gcc_version}/include/g++</code>,
|
||||
unless you also specify
|
||||
compiler-specific subdirectory (i.e.,
|
||||
<code>${libdir}/gcc-lib/${target_alias}/${gcc_version}</code>)
|
||||
instead of <code>${libdir}</code>. This option is useful if you
|
||||
intend to use several versions of gcc in parallel. In addition,
|
||||
libstdc++'s include files will be installed in
|
||||
<code>${libdir}/gcc-lib/${target_alias}/${gcc_version}/include/g++</code>,
|
||||
unless you also specify
|
||||
<literal>--with-gxx-include-dir=<filename class="directory">dirname</filename></literal> during configuration.
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--with-gxx-include-dir=<include-files dir></code></term>
|
||||
<listitem><para>Adds support for named libstdc++ include directory. For instance,
|
||||
the following puts all the libstdc++ headers into a directory
|
||||
called "4.4-20090404" instead of the usual
|
||||
"c++/(version)".
|
||||
the following puts all the libstdc++ headers into a directory
|
||||
called "4.4-20090404" instead of the usual
|
||||
"c++/(version)".
|
||||
</para>
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
--with-gxx-include-dir=/foo/H-x86-gcc-3-c-gxx-inc/include/4.4-20090404</programlisting> </listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-cstdio</code></term>
|
||||
<listitem><para>This is an abbreviated form of <code>'--enable-cstdio=stdio'</code>
|
||||
(described next).
|
||||
(described next).
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-cstdio=OPTION</code></term>
|
||||
<listitem><para>Select a target-specific I/O package. At the moment, the only
|
||||
choice is to use 'stdio', a generic "C" abstraction.
|
||||
The default is 'stdio'. This option can change the library ABI.
|
||||
choice is to use 'stdio', a generic "C" abstraction.
|
||||
The default is 'stdio'. This option can change the library ABI.
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-clocale</code></term>
|
||||
<listitem><para>This is an abbreviated form of <code>'--enable-clocale=generic'</code>
|
||||
(described next).
|
||||
(described next).
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-clocale=OPTION</code></term>
|
||||
<listitem><para>Select a target-specific underlying locale package. The
|
||||
choices are 'ieee_1003.1-2001' to specify an X/Open, Standard Unix
|
||||
(IEEE Std. 1003.1-2001) model based on langinfo/iconv/catgets,
|
||||
'gnu' to specify a model based on functionality from the GNU C
|
||||
library (langinfo/iconv/gettext) (from <ulink url="http://sources.redhat.com/glibc/">glibc</ulink>, the GNU C
|
||||
library), or 'generic' to use a generic "C"
|
||||
abstraction which consists of "C" locale info.
|
||||
choices are 'ieee_1003.1-2001' to specify an X/Open, Standard Unix
|
||||
(IEEE Std. 1003.1-2001) model based on langinfo/iconv/catgets,
|
||||
'gnu' to specify a model based on functionality from the GNU C
|
||||
library (langinfo/iconv/gettext) (from <ulink url="http://sources.redhat.com/glibc/">glibc</ulink>, the GNU C
|
||||
library), or 'generic' to use a generic "C"
|
||||
abstraction which consists of "C" locale info.
|
||||
</para>
|
||||
|
||||
<para>If not explicitly specified, the configure proccess tries
|
||||
@ -121,146 +121,146 @@
|
||||
|
||||
<varlistentry><term><code>--enable-libstdcxx-allocator</code></term>
|
||||
<listitem><para>This is an abbreviated form of
|
||||
<code>'--enable-libstdcxx-allocator=auto'</code> (described
|
||||
next).
|
||||
<code>'--enable-libstdcxx-allocator=auto'</code> (described
|
||||
next).
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-libstdcxx-allocator=OPTION </code></term>
|
||||
<listitem><para>Select a target-specific underlying std::allocator. The
|
||||
choices are 'new' to specify a wrapper for new, 'malloc' to
|
||||
specify a wrapper for malloc, 'mt' for a fixed power of two allocator,
|
||||
choices are 'new' to specify a wrapper for new, 'malloc' to
|
||||
specify a wrapper for malloc, 'mt' for a fixed power of two allocator,
|
||||
'pool' for the SGI pooled allocator or 'bitmap' for a bitmap allocator.
|
||||
See this page for more information on allocator
|
||||
<link linkend="allocator.ext">extensions</link>. This option
|
||||
can change the library ABI.
|
||||
See this page for more information on allocator
|
||||
<link linkend="allocator.ext">extensions</link>. This option
|
||||
can change the library ABI.
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-cheaders=OPTION</code></term>
|
||||
<listitem><para>This allows the user to define the approach taken for C header
|
||||
compatibility with C++. Options are c, c_std, and c_global.
|
||||
These correspond to the source directory's include/c,
|
||||
include/c_std, and include/c_global, and may also include
|
||||
include/c_compatibility. The default is 'c_global'.
|
||||
compatibility with C++. Options are c, c_std, and c_global.
|
||||
These correspond to the source directory's include/c,
|
||||
include/c_std, and include/c_global, and may also include
|
||||
include/c_compatibility. The default is 'c_global'.
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-threads</code></term>
|
||||
<listitem><para>This is an abbreviated form of <code>'--enable-threads=yes'</code>
|
||||
(described next).
|
||||
(described next).
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-threads=OPTION</code></term>
|
||||
<listitem><para>Select a threading library. A full description is
|
||||
given in the
|
||||
general <ulink url="http://gcc.gnu.org/install/configure.html">compiler
|
||||
configuration instructions</ulink>. This option can change the
|
||||
library ABI.
|
||||
given in the
|
||||
general <ulink url="http://gcc.gnu.org/install/configure.html">compiler
|
||||
configuration instructions</ulink>. This option can change the
|
||||
library ABI.
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-libstdcxx-debug</code></term>
|
||||
<listitem><para>Build separate debug libraries in addition to what is normally built.
|
||||
By default, the debug libraries are compiled with
|
||||
<code> CXXFLAGS='-g3 -O0 -fno-inline'</code>
|
||||
, are installed in <code>${libdir}/debug</code>, and have the
|
||||
same names and versioning information as the non-debug
|
||||
libraries. This option is off by default.
|
||||
By default, the debug libraries are compiled with
|
||||
<code> CXXFLAGS='-g3 -O0 -fno-inline'</code>
|
||||
, are installed in <code>${libdir}/debug</code>, and have the
|
||||
same names and versioning information as the non-debug
|
||||
libraries. This option is off by default.
|
||||
</para>
|
||||
<para>Note this make command, executed in
|
||||
the build directory, will do much the same thing, without the
|
||||
configuration difference and without building everything twice:
|
||||
<code>make CXXFLAGS='-g3 -O0 -fno-inline' all</code>
|
||||
the build directory, will do much the same thing, without the
|
||||
configuration difference and without building everything twice:
|
||||
<code>make CXXFLAGS='-g3 -O0 -fno-inline' all</code>
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-libstdcxx-debug-flags=FLAGS</code></term>
|
||||
|
||||
<listitem><para>This option is only valid when <code> --enable-debug </code>
|
||||
is also specified, and applies to the debug builds only. With
|
||||
this option, you can pass a specific string of flags to the
|
||||
compiler to use when building the debug versions of libstdc++.
|
||||
FLAGS is a quoted string of options, like
|
||||
is also specified, and applies to the debug builds only. With
|
||||
this option, you can pass a specific string of flags to the
|
||||
compiler to use when building the debug versions of libstdc++.
|
||||
FLAGS is a quoted string of options, like
|
||||
</para>
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
--enable-libstdcxx-debug-flags='-g3 -O1 -fno-inline'</programlisting>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-cxx-flags=FLAGS</code></term>
|
||||
<listitem><para>With this option, you can pass a string of -f (functionality)
|
||||
flags to the compiler to use when building libstdc++. This
|
||||
option can change the library ABI. FLAGS is a quoted string of
|
||||
options, like
|
||||
flags to the compiler to use when building libstdc++. This
|
||||
option can change the library ABI. FLAGS is a quoted string of
|
||||
options, like
|
||||
</para>
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
--enable-cxx-flags='-fvtable-gc -fomit-frame-pointer -ansi'</programlisting>
|
||||
<para>
|
||||
Note that the flags don't necessarily have to all be -f flags,
|
||||
as shown, but usually those are the ones that will make sense
|
||||
for experimentation and configure-time overriding.
|
||||
Note that the flags don't necessarily have to all be -f flags,
|
||||
as shown, but usually those are the ones that will make sense
|
||||
for experimentation and configure-time overriding.
|
||||
</para>
|
||||
<para>The advantage of --enable-cxx-flags over setting CXXFLAGS in
|
||||
the 'make' environment is that, if files are automatically
|
||||
rebuilt, the same flags will be used when compiling those files
|
||||
as well, so that everything matches.
|
||||
the 'make' environment is that, if files are automatically
|
||||
rebuilt, the same flags will be used when compiling those files
|
||||
as well, so that everything matches.
|
||||
</para>
|
||||
<para>Fun flags to try might include combinations of
|
||||
</para>
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
-fstrict-aliasing
|
||||
-fno-exceptions
|
||||
-ffunction-sections
|
||||
-fvtable-gc</programlisting>
|
||||
<para>and opposite forms (-fno-) of the same. Tell us (the libstdc++
|
||||
mailing list) if you discover more!
|
||||
mailing list) if you discover more!
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-c99</code></term>
|
||||
<listitem><para>The "long long" type was introduced in C99, along
|
||||
with many other functions for wide characters, and math
|
||||
classification macros, etc. If enabled, all C99 functions not
|
||||
specified by the C++ standard will be put into <code>namespace
|
||||
__gnu_cxx</code>, and then all these names will
|
||||
be injected into namespace std, so that C99 functions can be
|
||||
used "as if" they were in the C++ standard (as they
|
||||
will eventually be in some future revision of the standard,
|
||||
without a doubt). By default, C99 support is on, assuming the
|
||||
configure probes find all the necessary functions and bits
|
||||
necessary. This option can change the library ABI.
|
||||
with many other functions for wide characters, and math
|
||||
classification macros, etc. If enabled, all C99 functions not
|
||||
specified by the C++ standard will be put into <code>namespace
|
||||
__gnu_cxx</code>, and then all these names will
|
||||
be injected into namespace std, so that C99 functions can be
|
||||
used "as if" they were in the C++ standard (as they
|
||||
will eventually be in some future revision of the standard,
|
||||
without a doubt). By default, C99 support is on, assuming the
|
||||
configure probes find all the necessary functions and bits
|
||||
necessary. This option can change the library ABI.
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-wchar_t</code>[default]</term>
|
||||
<listitem><para>Template specializations for the "wchar_t" type are
|
||||
required for wide character conversion support. Disabling
|
||||
wide character specializations may be expedient for initial
|
||||
porting efforts, but builds only a subset of what is required by
|
||||
ISO, and is not recommended. By default, this option is on.
|
||||
This option can change the library ABI.
|
||||
required for wide character conversion support. Disabling
|
||||
wide character specializations may be expedient for initial
|
||||
porting efforts, but builds only a subset of what is required by
|
||||
ISO, and is not recommended. By default, this option is on.
|
||||
This option can change the library ABI.
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-long-long </code></term>
|
||||
<listitem><para>The "long long" type was introduced in C99. It is
|
||||
provided as a GNU extension to C++98 in g++. This flag builds
|
||||
support for "long long" into the library (specialized
|
||||
templates and the like for iostreams). This option is on by default:
|
||||
if enabled, users will have to either use the new-style "C"
|
||||
headers by default (i.e., <cmath> not <math.h>)
|
||||
or add appropriate compile-time flags to all compile lines to
|
||||
allow "C" visibility of this feature (on GNU/Linux,
|
||||
the flag is -D_ISOC99_SOURCE, which is added automatically via
|
||||
CPLUSPLUS_CPP_SPEC's addition of _GNU_SOURCE).
|
||||
This option can change the library ABI.
|
||||
provided as a GNU extension to C++98 in g++. This flag builds
|
||||
support for "long long" into the library (specialized
|
||||
templates and the like for iostreams). This option is on by default:
|
||||
if enabled, users will have to either use the new-style "C"
|
||||
headers by default (i.e., <cmath> not <math.h>)
|
||||
or add appropriate compile-time flags to all compile lines to
|
||||
allow "C" visibility of this feature (on GNU/Linux,
|
||||
the flag is -D_ISOC99_SOURCE, which is added automatically via
|
||||
CPLUSPLUS_CPP_SPEC's addition of _GNU_SOURCE).
|
||||
This option can change the library ABI.
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-fully-dynamic-string</code></term>
|
||||
<listitem><para>This option enables a special version of basic_string avoiding
|
||||
the optimization that allocates empty objects in static memory.
|
||||
the optimization that allocates empty objects in static memory.
|
||||
Mostly useful together with shared memory allocators, see PR
|
||||
libstdc++/16612 for details.
|
||||
</para>
|
||||
@ -268,48 +268,48 @@
|
||||
|
||||
<varlistentry><term><code>--enable-concept-checks</code></term>
|
||||
<listitem><para>This turns on additional compile-time checks for instantiated
|
||||
library templates, in the form of specialized templates,
|
||||
<link linkend="manual.diagnostics.concept_checking">described here</link>. They
|
||||
can help users discover when they break the rules of the STL, before
|
||||
their programs run.
|
||||
library templates, in the form of specialized templates,
|
||||
<link linkend="std.diagnostics.concept_checking">described here</link>. They
|
||||
can help users discover when they break the rules of the STL, before
|
||||
their programs run.
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-symvers[=style]</code></term>
|
||||
|
||||
<listitem><para>In 3.1 and later, tries to turn on symbol versioning in the
|
||||
shared library (if a shared library has been
|
||||
requested). Values for 'style' that are currently supported
|
||||
are 'gnu', 'gnu-versioned-namespace', 'darwin', and
|
||||
'darwin-export'. Both gnu- options require that a recent
|
||||
version of the GNU linker be in use. Both darwin options are
|
||||
equivalent. With no style given, the configure script will try
|
||||
to guess correct defaults for the host system, probe to see if
|
||||
additional requirements are necessary and present for
|
||||
activation, and if so, will turn symbol versioning on. This
|
||||
option can change the library ABI.
|
||||
shared library (if a shared library has been
|
||||
requested). Values for 'style' that are currently supported
|
||||
are 'gnu', 'gnu-versioned-namespace', 'darwin', and
|
||||
'darwin-export'. Both gnu- options require that a recent
|
||||
version of the GNU linker be in use. Both darwin options are
|
||||
equivalent. With no style given, the configure script will try
|
||||
to guess correct defaults for the host system, probe to see if
|
||||
additional requirements are necessary and present for
|
||||
activation, and if so, will turn symbol versioning on. This
|
||||
option can change the library ABI.
|
||||
</para>
|
||||
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-visibility</code></term>
|
||||
<listitem><para> In 4.2 and later, enables or disables visibility attributes.
|
||||
If enabled (as by default), and the compiler seems capable of
|
||||
passing the simple sanity checks thrown at it, adjusts items
|
||||
in namespace std, namespace std::tr1, and namespace __gnu_cxx
|
||||
so that -fvisibility options work.
|
||||
If enabled (as by default), and the compiler seems capable of
|
||||
passing the simple sanity checks thrown at it, adjusts items
|
||||
in namespace std, namespace std::tr1, and namespace __gnu_cxx
|
||||
so that -fvisibility options work.
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-libstdcxx-pch</code></term>
|
||||
<listitem><para>In 3.4 and later, tries to turn on the generation of
|
||||
stdc++.h.gch, a pre-compiled file including all the standard
|
||||
C++ includes. If enabled (as by default), and the compiler
|
||||
seems capable of passing the simple sanity checks thrown at
|
||||
it, try to build stdc++.h.gch as part of the make process.
|
||||
In addition, this generated file is used later on (by appending <code>
|
||||
--include bits/stdc++.h </code> to CXXFLAGS) when running the
|
||||
testsuite.
|
||||
stdc++.h.gch, a pre-compiled file including all the standard
|
||||
C++ includes. If enabled (as by default), and the compiler
|
||||
seems capable of passing the simple sanity checks thrown at
|
||||
it, try to build stdc++.h.gch as part of the make process.
|
||||
In addition, this generated file is used later on (by appending <code>
|
||||
--include bits/stdc++.h </code> to CXXFLAGS) when running the
|
||||
testsuite.
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
@ -326,23 +326,23 @@
|
||||
|
||||
<varlistentry><term><code>--enable-clock-gettime</code></term>
|
||||
<listitem><para>This is an abbreviated form of
|
||||
<code>'--enable-clock-gettime=yes'</code>(described next).
|
||||
<code>'--enable-clock-gettime=yes'</code>(described next).
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>--enable-libstdcxx-time=OPTION</code></term>
|
||||
<listitem><para>Enables link-type checks for the availability of the
|
||||
clock_gettime clocks, used in the implementation of [time.clock],
|
||||
and of the nanosleep and sched_yield functions, used in the
|
||||
implementation of [thread.thread.this] of the current C++0x draft.
|
||||
The choice OPTION=yes checks for the availability of the facilities
|
||||
in libc and libposix4. In case of need the latter is also linked
|
||||
to libstdc++ as part of the build process. OPTION=rt also searches
|
||||
(and, in case, links) librt. Note that the latter is not always
|
||||
desirable because, in glibc, for example, in turn it triggers the
|
||||
linking of libpthread too, which activates locking, a large overhead
|
||||
for single-thread programs. OPTION=no skips the tests completely.
|
||||
The default is OPTION=no.
|
||||
clock_gettime clocks, used in the implementation of [time.clock],
|
||||
and of the nanosleep and sched_yield functions, used in the
|
||||
implementation of [thread.thread.this] of the current C++0x draft.
|
||||
The choice OPTION=yes checks for the availability of the facilities
|
||||
in libc and libposix4. In case of need the latter is also linked
|
||||
to libstdc++ as part of the build process. OPTION=rt also searches
|
||||
(and, in case, links) librt. Note that the latter is not always
|
||||
desirable because, in glibc, for example, in turn it triggers the
|
||||
linking of libpthread too, which activates locking, a large overhead
|
||||
for single-thread programs. OPTION=no skips the tests completely.
|
||||
The default is OPTION=no.
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
|
@ -1,12 +1,12 @@
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
[ ]>
|
||||
|
||||
<part id="manual.containers" xreflabel="Containers">
|
||||
<chapter id="std.containers" xreflabel="Containers">
|
||||
<?dbhtml filename="containers.html"?>
|
||||
|
||||
<partinfo>
|
||||
|
||||
<chapterinfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
ISO C++
|
||||
@ -15,22 +15,22 @@
|
||||
library
|
||||
</keyword>
|
||||
</keywordset>
|
||||
</partinfo>
|
||||
</chapterinfo>
|
||||
|
||||
<title>
|
||||
Containers
|
||||
<indexterm><primary>Containers</primary></indexterm>
|
||||
</title>
|
||||
|
||||
<!-- Chapter 01 : Sequences -->
|
||||
<chapter id="manual.containers.sequences" xreflabel="Sequences">
|
||||
<!-- Sect1 01 : Sequences -->
|
||||
<sect1 id="std.containers.sequences" xreflabel="Sequences">
|
||||
<?dbhtml filename="sequences.html"?>
|
||||
<title>Sequences</title>
|
||||
|
||||
<sect1 id="containers.sequences.list" xreflabel="list">
|
||||
<sect2 id="containers.sequences.list" xreflabel="list">
|
||||
<?dbhtml filename="list.html"?>
|
||||
<title>list</title>
|
||||
<sect2 id="sequences.list.size" xreflabel="list::size() is O(n)">
|
||||
<sect3 id="sequences.list.size" xreflabel="list::size() is O(n)">
|
||||
<title>list::size() is O(n)</title>
|
||||
<para>
|
||||
Yes it is, and that's okay. This is a decision that we preserved
|
||||
@ -64,29 +64,29 @@
|
||||
<para>
|
||||
One implication of linear time size(): you should never write
|
||||
</para>
|
||||
<programlisting>
|
||||
if (L.size() == 0)
|
||||
...
|
||||
<programlisting>
|
||||
if (L.size() == 0)
|
||||
...
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
Instead, you should write
|
||||
Instead, you should write
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
if (L.empty())
|
||||
...
|
||||
<programlisting>
|
||||
if (L.empty())
|
||||
...
|
||||
</programlisting>
|
||||
</blockquote>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect1 id="containers.sequences.vector" xreflabel="vector">
|
||||
<sect2 id="containers.sequences.vector" xreflabel="vector">
|
||||
<?dbhtml filename="vector.html"?>
|
||||
<title>vector</title>
|
||||
<para>
|
||||
</para>
|
||||
<sect2 id="sequences.vector.management" xreflabel="Space Overhead Management">
|
||||
<sect3 id="sequences.vector.management" xreflabel="Space Overhead Management">
|
||||
<title>Space Overhead Management</title>
|
||||
<para>
|
||||
In <ulink
|
||||
@ -103,15 +103,15 @@
|
||||
url="http://gcc.gnu.org/ml/libstdc++/2002-07/msg00111.html">here</ulink>.
|
||||
</para>
|
||||
|
||||
</sect2></sect1>
|
||||
</chapter>
|
||||
</sect3></sect2>
|
||||
</sect1>
|
||||
|
||||
<!-- Chapter 02 : Associative -->
|
||||
<chapter id="manual.containers.associative" xreflabel="Associative">
|
||||
<!-- Sect1 02 : Associative -->
|
||||
<sect1 id="std.containers.associative" xreflabel="Associative">
|
||||
<?dbhtml filename="associative.html"?>
|
||||
<title>Associative</title>
|
||||
|
||||
<sect1 id="containers.associative.insert_hints" xreflabel="Insertion Hints">
|
||||
<sect2 id="containers.associative.insert_hints" xreflabel="Insertion Hints">
|
||||
<title>Insertion Hints</title>
|
||||
<para>
|
||||
Section [23.1.2], Table 69, of the C++ standard lists this
|
||||
@ -170,7 +170,7 @@
|
||||
<code>end()</code>, then the item being inserted should have
|
||||
a key greater than all the other keys in the container. The
|
||||
item will be inserted at the end of the container, becoming
|
||||
the new entry before <code>end()</code>.
|
||||
the new entry before <code>end()</code>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -216,13 +216,13 @@
|
||||
point to the correct place, then no further local searching is
|
||||
done; the search begins from scratch in logarithmic time.
|
||||
</para>
|
||||
</sect1>
|
||||
</sect2>
|
||||
|
||||
|
||||
<sect1 id="containers.associative.bitset" xreflabel="bitset">
|
||||
<sect2 id="containers.associative.bitset" xreflabel="bitset">
|
||||
<?dbhtml filename="bitset.html"?>
|
||||
<title>bitset</title>
|
||||
<sect2 id="associative.bitset.size_variable" xreflabel="Variable">
|
||||
<sect3 id="associative.bitset.size_variable" xreflabel="Variable">
|
||||
<title>Size Variable</title>
|
||||
<para>
|
||||
No, you cannot write code of the form
|
||||
@ -233,9 +233,9 @@
|
||||
|
||||
void foo (size_t n)
|
||||
{
|
||||
std::bitset<n> bits;
|
||||
....
|
||||
}
|
||||
std::bitset<n> bits;
|
||||
....
|
||||
}
|
||||
</programlisting>
|
||||
<para>
|
||||
because <code>n</code> must be known at compile time. Your
|
||||
@ -245,12 +245,12 @@
|
||||
<para>
|
||||
There are a couple of ways to handle this kind of thing. Please
|
||||
consider all of them before passing judgement. They include, in
|
||||
no particular order:
|
||||
no chaptericular order:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem><para>A very large N in <code>bitset<N></code>.</para></listitem>
|
||||
<listitem><para>A container<bool>.</para></listitem>
|
||||
<listitem><para>Extremely weird solutions.</para></listitem>
|
||||
<listitem><para>A very large N in <code>bitset<N></code>.</para></listitem>
|
||||
<listitem><para>A container<bool>.</para></listitem>
|
||||
<listitem><para>Extremely weird solutions.</para></listitem>
|
||||
</itemizedlist>
|
||||
<para>
|
||||
<emphasis>A very large N in
|
||||
@ -329,8 +329,8 @@
|
||||
<link linkend="manual.ext.containers.sgi">some extensions</link>.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
<sect2 id="associative.bitset.type_string" xreflabel="Type String">
|
||||
</sect3>
|
||||
<sect3 id="associative.bitset.type_string" xreflabel="Type String">
|
||||
<title>Type String</title>
|
||||
<para>
|
||||
</para>
|
||||
@ -349,7 +349,7 @@
|
||||
<programlisting>
|
||||
std::bitset<5> b ( std::string(<quote>10110</quote>) );
|
||||
</programlisting>
|
||||
|
||||
|
||||
<para>
|
||||
instead of
|
||||
</para>
|
||||
@ -357,17 +357,17 @@
|
||||
<programlisting>
|
||||
std::bitset<5> b ( <quote>10110</quote> ); // invalid
|
||||
</programlisting>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
</chapter>
|
||||
</sect1>
|
||||
|
||||
<!-- Chapter 03 : Interacting with C -->
|
||||
<chapter id="manual.containers.c" xreflabel="Interacting with C">
|
||||
<!-- Sect1 03 : Interacting with C -->
|
||||
<sect1 id="std.containers.c" xreflabel="Interacting with C">
|
||||
<?dbhtml filename="containers_and_c.html"?>
|
||||
<title>Interacting with C</title>
|
||||
|
||||
<sect1 id="containers.c.vs_array" xreflabel="Containers vs. Arrays">
|
||||
<sect2 id="containers.c.vs_array" xreflabel="Containers vs. Arrays">
|
||||
<title>Containers vs. Arrays</title>
|
||||
<para>
|
||||
You're writing some code and can't decide whether to use builtin
|
||||
@ -422,27 +422,27 @@ template<typename T>
|
||||
{ return v.begin(); }
|
||||
|
||||
template<typename T, unsigned int sz>
|
||||
inline T*
|
||||
inline T*
|
||||
beginof(T (&array)[sz]) { return array; }
|
||||
|
||||
// endof
|
||||
template<typename T>
|
||||
inline typename vector<T>::iterator
|
||||
inline typename vector<T>::iterator
|
||||
endof(vector<T> &v)
|
||||
{ return v.end(); }
|
||||
|
||||
template<typename T, unsigned int sz>
|
||||
inline T*
|
||||
inline T*
|
||||
endof(T (&array)[sz]) { return array + sz; }
|
||||
|
||||
// lengthof
|
||||
template<typename T>
|
||||
inline typename vector<T>::size_type
|
||||
inline typename vector<T>::size_type
|
||||
lengthof(vector<T> &v)
|
||||
{ return v.size(); }
|
||||
|
||||
template<typename T, unsigned int sz>
|
||||
inline unsigned int
|
||||
inline unsigned int
|
||||
lengthof(T (&)[sz]) { return sz; }
|
||||
</programlisting>
|
||||
|
||||
@ -459,13 +459,13 @@ template<typename T, unsigned int sz>
|
||||
Second, the line
|
||||
</para>
|
||||
<programlisting>
|
||||
inline unsigned int lengthof (T (&)[sz]) { return sz; }
|
||||
inline unsigned int lengthof (T (&)[sz]) { return sz; }
|
||||
</programlisting>
|
||||
<para>
|
||||
looks just weird! Hint: unused parameters can be left nameless.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
</sect2>
|
||||
|
||||
</part>
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
|
@ -1,7 +1,7 @@
|
||||
<sect1 id="manual.localization.facet.ctype" xreflabel="ctype">
|
||||
<section id="std.localization.facet.ctype" xreflabel="ctype">
|
||||
<?dbhtml filename="ctype.html"?>
|
||||
|
||||
<sect1info>
|
||||
<sectioninfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
ISO C++
|
||||
@ -10,14 +10,14 @@
|
||||
ctype
|
||||
</keyword>
|
||||
</keywordset>
|
||||
</sect1info>
|
||||
</sectioninfo>
|
||||
|
||||
<title>ctype</title>
|
||||
|
||||
<sect2 id="facet.ctype.impl">
|
||||
<section id="facet.ctype.impl">
|
||||
<title>Implementation</title>
|
||||
|
||||
<sect3>
|
||||
<section>
|
||||
<title>Specializations</title>
|
||||
|
||||
<para>
|
||||
@ -57,10 +57,10 @@ Neither of these two required specializations deals with Unicode
|
||||
characters.
|
||||
</para>
|
||||
|
||||
</sect3>
|
||||
</sect2>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<sect2 id="facet.ctype.future">
|
||||
<section id="facet.ctype.future">
|
||||
<title>Future</title>
|
||||
|
||||
|
||||
@ -114,7 +114,7 @@ characters.
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
|
||||
<bibliography id="facet.ctype.biblio">
|
||||
@ -236,4 +236,4 @@ characters.
|
||||
|
||||
</bibliography>
|
||||
|
||||
</sect1>
|
||||
</section>
|
||||
|
@ -1,6 +1,6 @@
|
||||
<sect1 id="manual.intro.using.debug" xreflabel="Debugging Support">
|
||||
<?dbhtml filename="debug.html"?>
|
||||
|
||||
|
||||
<sect1info>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
@ -22,11 +22,11 @@
|
||||
|
||||
<sect2 id="debug.compiler">
|
||||
<title>Using <command>g++</command></title>
|
||||
<para>
|
||||
<para>
|
||||
Compiler flags determine how debug information is transmitted
|
||||
between compilation and debug or analysis tools.
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
The default optimizations and debug flags for a libstdc++ build
|
||||
are <code>-g -O2</code>. However, both debug and optimization
|
||||
@ -84,7 +84,7 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A second approach is to use the configuration flags
|
||||
A second approach is to use the configuration flags
|
||||
</para>
|
||||
<programlisting>
|
||||
make CXXFLAGS='-g3 -fno-inline -O0' all
|
||||
@ -95,7 +95,7 @@
|
||||
debugging tasks, when you cannot or don't want to recompile your
|
||||
application to use the <link linkend="manual.ext.debug_mode">debug mode</link>.</para>
|
||||
</sect2>
|
||||
|
||||
|
||||
<sect2 id="debug.memory">
|
||||
<title>Memory Leak Hunting</title>
|
||||
|
||||
@ -174,8 +174,8 @@
|
||||
int main()
|
||||
{
|
||||
extern void* __dso_handle __attribute__ ((__weak__));
|
||||
__cxa_atexit((void (*) (void *)) __libc_freeres, NULL,
|
||||
&__dso_handle ? __dso_handle : NULL);
|
||||
__cxa_atexit((void (*) (void *)) __libc_freeres, NULL,
|
||||
&__dso_handle ? __dso_handle : NULL);
|
||||
do_test();
|
||||
return 0;
|
||||
}
|
||||
@ -185,7 +185,7 @@
|
||||
Suggested valgrind flags, given the suggestions above about setting
|
||||
up the runtime environment, library, and test file, might be:
|
||||
</para>
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
valgrind -v --num-callers=20 --leak-check=yes --leak-resolution=high --show-reachable=yes a.out
|
||||
</programlisting>
|
||||
|
||||
@ -193,7 +193,7 @@
|
||||
|
||||
<sect2 id="debug.gdb">
|
||||
<title>Using <command>gdb</command></title>
|
||||
<para>
|
||||
<para>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -228,7 +228,7 @@
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
svn co svn://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python
|
||||
svn co svn://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
@ -295,8 +295,8 @@
|
||||
|
||||
<sect2 id="debug.profile_mode" xreflabel="debug.profile_mode">
|
||||
<title>Profile-based Performance Analysis</title>
|
||||
<para> The <link linkend="manual.ext.profile_mode">Profile-based
|
||||
Performance Analysis</link> Extension has performance checks for many
|
||||
<para> The <link linkend="manual.ext.profile_mode">Profile-based
|
||||
Performance Analysis</link> Extension has performance checks for many
|
||||
algorithms.
|
||||
</para>
|
||||
</sect2>
|
||||
|
@ -1,11 +1,11 @@
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
[ ]>
|
||||
|
||||
<chapter id="manual.ext.debug_mode" xreflabel="Debug Mode">
|
||||
<?dbhtml filename="debug_mode.html"?>
|
||||
|
||||
|
||||
<chapterinfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
@ -36,7 +36,7 @@
|
||||
library facilities, and will report errors in the use of libstdc++
|
||||
as soon as they can be detected by emitting a description of the
|
||||
problem to standard error and aborting the program. This debug
|
||||
mode is available with GCC 3.4.0 and later versions.
|
||||
mode is available with GCC 3.4.0 and later versions.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -51,7 +51,7 @@
|
||||
incrementing a past-the-end iterator or dereferencing an iterator
|
||||
that points to a container that has been destructed are diagnosed
|
||||
immediately.</para></listitem>
|
||||
|
||||
|
||||
<listitem><para><emphasis>Algorithm preconditions</emphasis>: Algorithms attempt to
|
||||
validate their input parameters to detect errors as early as
|
||||
possible. For instance, the <code>set_intersection</code>
|
||||
@ -81,7 +81,7 @@
|
||||
instance, erasing an element in a <code>std::list</code> is a
|
||||
constant-time operation in normal library, but in debug mode it is
|
||||
linear in the number of iterators that reference that particular
|
||||
list. So while your (correct) program won't change its results, it
|
||||
list. So while your (correct) program won't change its results, it
|
||||
is likely to execute more slowly.</para>
|
||||
|
||||
<para>libstdc++ includes many extensions to the C++ standard library. In
|
||||
@ -375,7 +375,7 @@ containers have additional debug capability.
|
||||
own usability and implementation characteristics. In general, the
|
||||
higher-numbered conformance levels are more usable (i.e., require
|
||||
less recompilation) but are more complicated to implement than
|
||||
the lower-numbered conformance levels.
|
||||
the lower-numbered conformance levels.
|
||||
<orderedlist>
|
||||
<listitem><para><emphasis>Full recompilation</emphasis>: The user must recompile his or
|
||||
her entire application and all C++ libraries it depends on,
|
||||
@ -486,7 +486,7 @@ containers have additional debug capability.
|
||||
<listitem><para><code>Iterator</code>: The underlying iterator type, which must
|
||||
be either the <code>iterator</code> or <code>const_iterator</code>
|
||||
typedef from the sequence type this iterator can reference.</para></listitem>
|
||||
|
||||
|
||||
<listitem><para><code>Sequence</code>: The type of sequence that this iterator
|
||||
references. This sequence must be a safe sequence (discussed below)
|
||||
whose <code>iterator</code> or <code>const_iterator</code> typedef
|
||||
@ -511,7 +511,7 @@ containers have additional debug capability.
|
||||
instantiated with the type of the safe container itself (an instance
|
||||
of the curiously recurring template pattern).</para>
|
||||
|
||||
<para>The iterators of a container wrapper will be
|
||||
<para>The iterators of a container wrapper will be
|
||||
<link linkend="debug_mode.design.methods.safe_iter">safe
|
||||
iterators</link> that reference sequences of this type and wrap the
|
||||
iterators provided by the release-mode base class. The debugging
|
||||
@ -627,7 +627,7 @@ namespace std
|
||||
};
|
||||
} // namespace std
|
||||
</programlisting>
|
||||
|
||||
|
||||
<para>In debug mode we include the release-mode container (which is now
|
||||
defined in the namespace <code>__norm</code>) and also the
|
||||
debug-mode container. The debug-mode container is defined within the
|
||||
@ -646,7 +646,7 @@ namespace std
|
||||
template<typename _Tp, typename _Alloc = allocator<_Tp> >
|
||||
class list
|
||||
{
|
||||
// ...
|
||||
// ...
|
||||
};
|
||||
} // namespace __gnu_norm
|
||||
|
||||
@ -655,9 +655,9 @@ namespace std
|
||||
template<typename _Tp, typename _Alloc = allocator<_Tp> >
|
||||
class list
|
||||
: public __norm::list<_Tp, _Alloc>,
|
||||
public __gnu_debug::_Safe_sequence<list<_Tp, _Alloc> >
|
||||
public __gnu_debug::_Safe_sequence<list<_Tp, _Alloc> >
|
||||
{
|
||||
// ...
|
||||
// ...
|
||||
};
|
||||
} // namespace __norm
|
||||
|
||||
@ -694,12 +694,12 @@ runtime errors. A simplified example of this problem is as follows.
|
||||
#include <string>
|
||||
|
||||
std::string test02();
|
||||
|
||||
|
||||
std::string test01()
|
||||
{
|
||||
return test02();
|
||||
}
|
||||
|
||||
|
||||
int main()
|
||||
{
|
||||
test01();
|
||||
@ -711,7 +711,7 @@ int main()
|
||||
|
||||
<programlisting>
|
||||
#include <string>
|
||||
|
||||
|
||||
std::string
|
||||
test02()
|
||||
{
|
||||
@ -831,7 +831,7 @@ test02()
|
||||
include ordering. Two, ODR issues remained with container member
|
||||
functions taking no arguments in mixed-mode settings resulting in
|
||||
equivalent link names, <code> vector::push_back() </code> being
|
||||
one example.
|
||||
one example.
|
||||
See <ulink url="http://gcc.gnu.org/ml/libstdc++/2003-08/msg00177.html">link
|
||||
name</ulink> </para></listitem>
|
||||
</itemizedlist>
|
||||
@ -850,7 +850,7 @@ test02()
|
||||
mode implementations.</para>
|
||||
</sect4>
|
||||
</sect3>
|
||||
</sect2>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="debug_mode.design.other" xreflabel="Other">
|
||||
<title>Other Implementations</title>
|
||||
@ -885,7 +885,7 @@ test02()
|
||||
guarantee.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</sect2>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
|
@ -1,12 +1,12 @@
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
[ ]>
|
||||
|
||||
<part id="manual.diagnostics" xreflabel="Diagnostics">
|
||||
<chapter id="std.diagnostics" xreflabel="Diagnostics">
|
||||
<?dbhtml filename="diagnostics.html"?>
|
||||
|
||||
<partinfo>
|
||||
|
||||
<chapterinfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
ISO C++
|
||||
@ -15,18 +15,18 @@
|
||||
library
|
||||
</keyword>
|
||||
</keywordset>
|
||||
</partinfo>
|
||||
</chapterinfo>
|
||||
|
||||
<title>
|
||||
Diagnostics
|
||||
<indexterm><primary>Diagnostics</primary></indexterm>
|
||||
</title>
|
||||
|
||||
<chapter id="manual.diagnostics.exceptions" xreflabel="Exceptions">
|
||||
<sect1 id="std.diagnostics.exceptions" xreflabel="Exceptions">
|
||||
<?dbhtml filename="exceptions.html"?>
|
||||
<title>Exceptions</title>
|
||||
|
||||
<sect1 id="manual.diagnostics.exceptions.hierarchy" xreflabel="Exception Classes">
|
||||
<sect2 id="std.diagnostics.exceptions.hierarchy" xreflabel="Exception Classes">
|
||||
<title>Exception Classes</title>
|
||||
<para>
|
||||
All exception objects are defined in one of the standard header
|
||||
@ -47,8 +47,8 @@
|
||||
found in the <ulink url="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00460.html">source documentation</ulink>.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
<sect1 id="manual.diagnostics.exceptions.data" xreflabel="Adding Data to Exceptions">
|
||||
</sect2>
|
||||
<sect2 id="std.diagnostics.exceptions.data" xreflabel="Adding Data to Exceptions">
|
||||
<title>Adding Data to Exceptions</title>
|
||||
<para>
|
||||
The standard exception classes carry with them a single string as
|
||||
@ -61,7 +61,7 @@
|
||||
{
|
||||
public:
|
||||
My_Exception (const string& whatarg)
|
||||
: std::runtime_error(whatarg), e(errno), id(GetDataBaseID()) { }
|
||||
: std::runtime_error(whatarg), e(errno), id(GetDataBaseID()) { }
|
||||
int errno_at_time_of_throw() const { return e; }
|
||||
DBID id_of_thing_that_threw() const { return id; }
|
||||
protected:
|
||||
@ -70,10 +70,10 @@
|
||||
};
|
||||
</programlisting>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<chapter id="manual.diagnostics.concept_checking" xreflabel="Concept Checking">
|
||||
<sect1 id="std.diagnostics.concept_checking" xreflabel="Concept Checking">
|
||||
<title>Concept Checking</title>
|
||||
<para>
|
||||
In 1999, SGI added <quote>concept checkers</quote> to their
|
||||
@ -112,7 +112,7 @@
|
||||
You can enable them on a per-translation-unit basis with
|
||||
<literal>-D_GLIBCXX_CONCEPT_CHECKS</literal>.
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
Please note that the upcoming C++ standard has first-class
|
||||
support for template parameter constraints based on concepts in the core
|
||||
@ -120,6 +120,6 @@
|
||||
checking described above.
|
||||
</para>
|
||||
|
||||
</chapter>
|
||||
</sect1>
|
||||
|
||||
</part>
|
||||
</chapter>
|
||||
|
@ -1,6 +1,6 @@
|
||||
<sect1 id="appendix.porting.api" xreflabel="api">
|
||||
<?dbhtml filename="api.html"?>
|
||||
|
||||
|
||||
<sect1info>
|
||||
<keywordset>
|
||||
<keyword>ISO C++</keyword>
|
||||
@ -80,10 +80,10 @@ Removal of <filename class="headerfile">ext/tree</filename>, moved to <filename
|
||||
<para> For GCC releases from 2.95 through the 3.1 series, defining
|
||||
<literal>__USE_MALLOC</literal> on the gcc command line would change the
|
||||
default allocation strategy to instead use <code> malloc</code> and
|
||||
<function>free</function>. (This same functionality is now spelled <literal>_GLIBCXX_FORCE_NEW</literal>, see
|
||||
<link linkend="manual.intro.using.macros">this page</link>
|
||||
<function>free</function>. (This same functionality is now spelled <literal>_GLIBCXX_FORCE_NEW</literal>, see
|
||||
<link linkend="manual.intro.using.macros">this page</link>
|
||||
for details.
|
||||
</para>
|
||||
</para>
|
||||
|
||||
|
||||
<para>Error handling in iostreams cleaned up, made consistent. </para>
|
||||
@ -431,7 +431,7 @@ Parallel mode first appears.
|
||||
</para>
|
||||
|
||||
<para>Variadic template implementations of items in <filename class="headerfile">tuple</filename> and
|
||||
<filename class="headerfile">functional</filename>.
|
||||
<filename class="headerfile">functional</filename>.
|
||||
</para>
|
||||
|
||||
<para>Default <code>what</code> implementations give more elaborate
|
||||
@ -441,7 +441,7 @@ Parallel mode first appears.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
PCH binary files no longer installed. Instead, the source files are installed.
|
||||
PCH binary files no longer installed. Instead, the source files are installed.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -604,7 +604,7 @@ Profile mode first appears.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Support for decimal floating-point arithmetic, including <classname>decimal32</classname>, <classname>decimal64</classname>, and <classname>decimal128</classname>.
|
||||
Support for decimal floating-point arithmetic, including <classname>decimal32</classname>, <classname>decimal64</classname>, and <classname>decimal128</classname>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,11 +1,11 @@
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
<!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
[ ]>
|
||||
|
||||
<part id="manual.ext" xreflabel="Extensions">
|
||||
<?dbhtml filename="extensions.html"?>
|
||||
|
||||
|
||||
<partinfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
@ -35,7 +35,7 @@ extensions, be aware of two things:
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Non-Standard means exactly that.
|
||||
Non-Standard means exactly that.
|
||||
</para>
|
||||
<para>
|
||||
The behavior, and the very
|
||||
@ -43,12 +43,12 @@ extensions, be aware of two things:
|
||||
warning. (Ideally, the really good ones will appear in the next
|
||||
revision of C++.) Also, other platforms, other compilers, other
|
||||
versions of g++ or libstdc++ may not recognize these names, or
|
||||
treat them differently, or...
|
||||
treat them differently, or...
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
You should know how to access these headers properly.
|
||||
You should know how to access these headers properly.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
@ -104,17 +104,17 @@ extensions, be aware of two things:
|
||||
</chapter>
|
||||
|
||||
<!-- Chapter 02 : Debug Mode -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="debug_mode.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Chapter 03 : Parallel Mode -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="parallel_mode.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Chapter 04 : Profile Mode -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="profile_mode.xml">
|
||||
</xi:include>
|
||||
|
||||
@ -125,12 +125,12 @@ extensions, be aware of two things:
|
||||
<title>Allocators</title>
|
||||
|
||||
<!-- Section 01 : __mt_alloc -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="mt_allocator.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Section 02 : bitmap_allocator -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="bitmap_allocator.xml">
|
||||
</xi:include>
|
||||
|
||||
@ -186,7 +186,7 @@ extensions, be aware of two things:
|
||||
no present plans to do so (and there doesn't seem to be any immediate
|
||||
reason to).
|
||||
</para>
|
||||
<para>The semantics of member function <code>operator[]</code> are not specified
|
||||
<para>The semantics of member function <code>operator[]</code> are not specified
|
||||
in the C++ standard. A long-standing defect report calls for sensible
|
||||
obvious semantics, which are already implemented here: <code>op[]</code>
|
||||
on a const bitset returns a bool, and for a non-const bitset returns a
|
||||
@ -269,7 +269,7 @@ extensions, be aware of two things:
|
||||
</para>
|
||||
</blockquote>
|
||||
|
||||
</sect1>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<!-- Chapter 07 : Utilities -->
|
||||
@ -283,22 +283,22 @@ extensions, be aware of two things:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><code>identity_element</code> for addition and multiplication. *
|
||||
<para><code>identity_element</code> for addition and multiplication. *
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The functor <code>identity</code>, whose <code>operator()</code>
|
||||
returns the argument unchanged. *
|
||||
returns the argument unchanged. *
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Composition functors <code>unary_function</code> and
|
||||
<code>binary_function</code>, and their helpers <code>compose1</code>
|
||||
and <code>compose2</code>. *
|
||||
and <code>compose2</code>. *
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><code>select1st</code> and <code>select2nd</code>, to strip pairs. *
|
||||
<para><code>select1st</code> and <code>select2nd</code>, to strip pairs. *
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem><para><code>project1st</code> and <code>project2nd</code>. * </para></listitem>
|
||||
@ -368,13 +368,13 @@ get_temporary_buffer(5, (int*)0);
|
||||
<itemizedlist>
|
||||
<listitem><para><code>is_heap</code> tests whether or not a range is a heap.</para></listitem>
|
||||
<listitem><para><code>is_sorted</code> tests whether or not a range is sorted in
|
||||
nondescending order.</para></listitem>
|
||||
nondescending order.</para></listitem>
|
||||
</itemizedlist>
|
||||
<para>25.3.8 (lexicographical_compare) is extended with
|
||||
</para>
|
||||
<programlisting>
|
||||
lexicographical_compare_3way(_InputIter1 first1, _InputIter1 last1,
|
||||
_InputIter2 first2, _InputIter2 last2)</programlisting>
|
||||
_InputIter2 first2, _InputIter2 last2)</programlisting>
|
||||
<para>which does... what?
|
||||
</para>
|
||||
|
||||
@ -451,41 +451,41 @@ get_temporary_buffer(5, (int*)0);
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem><para>3.0.x <code>filebuf</code>s have another ctor with this signature:
|
||||
<code>basic_filebuf(__c_file_type*, ios_base::openmode, int_type);
|
||||
<code>basic_filebuf(__c_file_type*, ios_base::openmode, int_type);
|
||||
</code>
|
||||
This comes in very handy in a number of places, such as
|
||||
attaching Unix sockets, pipes, and anything else which uses file
|
||||
descriptors, into the IOStream buffering classes. The three
|
||||
arguments are as follows:
|
||||
<itemizedlist>
|
||||
<listitem><para><code>__c_file_type* F </code>
|
||||
// the __c_file_type typedef usually boils down to stdio's FILE
|
||||
</para></listitem>
|
||||
<listitem><para><code>ios_base::openmode M </code>
|
||||
// same as all the other uses of openmode
|
||||
</para></listitem>
|
||||
<listitem><para><code>int_type B </code>
|
||||
// buffer size, defaults to BUFSIZ if not specified
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
For those wanting to use file descriptors instead of FILE*'s, I
|
||||
invite you to contemplate the mysteries of C's <code>fdopen()</code>.
|
||||
This comes in very handy in a number of places, such as
|
||||
attaching Unix sockets, pipes, and anything else which uses file
|
||||
descriptors, into the IOStream buffering classes. The three
|
||||
arguments are as follows:
|
||||
<itemizedlist>
|
||||
<listitem><para><code>__c_file_type* F </code>
|
||||
// the __c_file_type typedef usually boils down to stdio's FILE
|
||||
</para></listitem>
|
||||
<listitem><para><code>ios_base::openmode M </code>
|
||||
// same as all the other uses of openmode
|
||||
</para></listitem>
|
||||
<listitem><para><code>int_type B </code>
|
||||
// buffer size, defaults to BUFSIZ if not specified
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
For those wanting to use file descriptors instead of FILE*'s, I
|
||||
invite you to contemplate the mysteries of C's <code>fdopen()</code>.
|
||||
</para></listitem>
|
||||
<listitem><para>In library snapshot 3.0.95 and later, <code>filebuf</code>s bring
|
||||
back an old extension: the <code>fd()</code> member function. The
|
||||
integer returned from this function can be used for whatever file
|
||||
descriptors can be used for on your platform. Naturally, the
|
||||
library cannot track what you do on your own with a file descriptor,
|
||||
so if you perform any I/O directly, don't expect the library to be
|
||||
aware of it.
|
||||
back an old extension: the <code>fd()</code> member function. The
|
||||
integer returned from this function can be used for whatever file
|
||||
descriptors can be used for on your platform. Naturally, the
|
||||
library cannot track what you do on your own with a file descriptor,
|
||||
so if you perform any I/O directly, don't expect the library to be
|
||||
aware of it.
|
||||
</para></listitem>
|
||||
<listitem><para>Beginning with 3.1, the extra <code>filebuf</code> constructor and
|
||||
the <code>fd()</code> function were removed from the standard
|
||||
filebuf. Instead, <code><ext/stdio_filebuf.h></code> contains
|
||||
a derived class called
|
||||
<ulink url="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00074.html"><code>__gnu_cxx::stdio_filebuf</code></ulink>.
|
||||
This class can be constructed from a C <code>FILE*</code> or a file
|
||||
descriptor, and provides the <code>fd()</code> function.
|
||||
the <code>fd()</code> function were removed from the standard
|
||||
filebuf. Instead, <code><ext/stdio_filebuf.h></code> contains
|
||||
a derived class called
|
||||
<ulink url="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00074.html"><code>__gnu_cxx::stdio_filebuf</code></ulink>.
|
||||
This class can be constructed from a C <code>FILE*</code> or a file
|
||||
descriptor, and provides the <code>fd()</code> function.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
<para>If you want to access a <code>filebuf</code>'s file descriptor to
|
||||
@ -572,7 +572,7 @@ int main()
|
||||
<screen>
|
||||
<computeroutput>
|
||||
St13bad_exception => std::bad_exception : 0
|
||||
3barI5emptyLi17EE => bar<empty, 17> : 0
|
||||
3barI5emptyLi17EE => bar<empty, 17> : 0
|
||||
</computeroutput>
|
||||
</screen>
|
||||
|
||||
@ -586,7 +586,7 @@ int main()
|
||||
</chapter>
|
||||
|
||||
<!-- Chapter 13 : Concurrency -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="concurrency_extensions.xml">
|
||||
</xi:include>
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
<sect1 id="appendix.porting.internals" xreflabel="Portin Internals">
|
||||
<?dbhtml filename="internals.html"?>
|
||||
|
||||
|
||||
<sect1info>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
@ -73,7 +73,7 @@ OS portion of the triplet (the default), then nothing needs to be changed.
|
||||
|
||||
<para>The first file to create in this directory, should be called
|
||||
<code>os_defines.h</code>. This file contains basic macro definitions
|
||||
that are required to allow the C++ library to work with your C library.
|
||||
that are required to allow the C++ library to work with your C library.
|
||||
</para>
|
||||
|
||||
<para>Several libstdc++ source files unconditionally define the macro
|
||||
@ -140,7 +140,7 @@ it must be 0 while bootstrapping the compiler/rebuilding the library.
|
||||
this:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
|
||||
#ifndef _GLIBCXX_OS_DEFINES
|
||||
#define _GLIBCXX_OS_DEFINES
|
||||
@ -207,7 +207,7 @@ masks. You will have to peer at your own <code><ctype.h></code> to figure
|
||||
how to define the values required by this file.
|
||||
</para>
|
||||
|
||||
<para>The <code>ctype_base.h</code> header file does not need include guards.
|
||||
<para>The <code>ctype_base.h</code> header file does not need include guards.
|
||||
It should contain a single <code>struct</code> definition called
|
||||
<code>ctype_base</code>. This <code>struct</code> should contain two type
|
||||
declarations, and one enumeration declaration, like this example, taken
|
||||
@ -219,20 +219,20 @@ from the IRIX configuration:
|
||||
{
|
||||
typedef unsigned int mask;
|
||||
typedef int* __to_type;
|
||||
|
||||
|
||||
enum
|
||||
{
|
||||
space = _ISspace,
|
||||
print = _ISprint,
|
||||
cntrl = _IScntrl,
|
||||
upper = _ISupper,
|
||||
lower = _ISlower,
|
||||
alpha = _ISalpha,
|
||||
digit = _ISdigit,
|
||||
punct = _ISpunct,
|
||||
xdigit = _ISxdigit,
|
||||
alnum = _ISalnum,
|
||||
graph = _ISgraph
|
||||
space = _ISspace,
|
||||
print = _ISprint,
|
||||
cntrl = _IScntrl,
|
||||
upper = _ISupper,
|
||||
lower = _ISlower,
|
||||
alpha = _ISalpha,
|
||||
digit = _ISdigit,
|
||||
punct = _ISpunct,
|
||||
xdigit = _ISxdigit,
|
||||
alnum = _ISalnum,
|
||||
graph = _ISgraph
|
||||
};
|
||||
};
|
||||
</programlisting>
|
||||
@ -262,14 +262,14 @@ constructor. Here is the IRIX example:
|
||||
|
||||
<programlisting>
|
||||
ctype<char>::ctype(const mask* __table = 0, bool __del = false,
|
||||
size_t __refs = 0)
|
||||
size_t __refs = 0)
|
||||
: _Ctype_nois<char>(__refs), _M_del(__table != 0 && __del),
|
||||
_M_toupper(NULL),
|
||||
_M_tolower(NULL),
|
||||
_M_ctable(NULL),
|
||||
_M_table(!__table
|
||||
? (const mask*) (__libc_attr._ctype_tbl->_class + 1)
|
||||
: __table)
|
||||
_M_toupper(NULL),
|
||||
_M_tolower(NULL),
|
||||
_M_ctable(NULL),
|
||||
_M_table(!__table
|
||||
? (const mask*) (__libc_attr._ctype_tbl->_class + 1)
|
||||
: __table)
|
||||
{ }
|
||||
</programlisting>
|
||||
|
||||
@ -291,7 +291,7 @@ lower-case, and vice versa. Here are the IRIX versions:
|
||||
char
|
||||
ctype<char>::do_toupper(char __c) const
|
||||
{ return _toupper(__c); }
|
||||
|
||||
|
||||
char
|
||||
ctype<char>::do_tolower(char __c) const
|
||||
{ return _tolower(__c); }
|
||||
@ -313,21 +313,21 @@ machinery to do that on your system:
|
||||
ctype<char>::do_toupper(char* __low, const char* __high) const
|
||||
{
|
||||
while (__low < __high)
|
||||
{
|
||||
*__low = do_toupper(*__low);
|
||||
++__low;
|
||||
}
|
||||
{
|
||||
*__low = do_toupper(*__low);
|
||||
++__low;
|
||||
}
|
||||
return __high;
|
||||
}
|
||||
|
||||
|
||||
const char*
|
||||
ctype<char>::do_tolower(char* __low, const char* __high) const
|
||||
{
|
||||
while (__low < __high)
|
||||
{
|
||||
*__low = do_tolower(*__low);
|
||||
++__low;
|
||||
}
|
||||
{
|
||||
*__low = do_tolower(*__low);
|
||||
++__low;
|
||||
}
|
||||
return __high;
|
||||
}
|
||||
</programlisting>
|
||||
@ -352,7 +352,7 @@ properties; they are analogous to the functions like <code>isalpha</code> and
|
||||
{ return (_M_table)[(unsigned char)(__c)] & __m; }
|
||||
</programlisting>
|
||||
|
||||
<para>The <code>_M_table</code> is the table passed in above, in the constructor.
|
||||
<para>The <code>_M_table</code> is the table passed in above, in the constructor.
|
||||
This is the table that contains the bitmasks for each character. The
|
||||
implementation here should work on all systems.
|
||||
</para>
|
||||
@ -366,7 +366,7 @@ implementation here should work on all systems.
|
||||
is(const char* __low, const char* __high, mask* __vec) const throw()
|
||||
{
|
||||
while (__low < __high)
|
||||
*__vec++ = (_M_table)[(unsigned char)(*__low++)];
|
||||
*__vec++ = (_M_table)[(unsigned char)(*__low++)];
|
||||
return __high;
|
||||
}
|
||||
</programlisting>
|
||||
@ -385,16 +385,16 @@ from <code>__low</code> up until <code>__high</code> into the vector given by
|
||||
scan_is(mask __m, const char* __low, const char* __high) const throw()
|
||||
{
|
||||
while (__low < __high && !this->is(__m, *__low))
|
||||
++__low;
|
||||
++__low;
|
||||
return __low;
|
||||
}
|
||||
|
||||
|
||||
const char*
|
||||
ctype<char>::
|
||||
scan_not(mask __m, const char* __low, const char* __high) const throw()
|
||||
{
|
||||
while (__low < __high && this->is(__m, *__low))
|
||||
++__low;
|
||||
++__low;
|
||||
return __low;
|
||||
}
|
||||
</programlisting>
|
||||
@ -454,7 +454,7 @@ type, and two functions.
|
||||
typedef long _Atomic_word;
|
||||
</programlisting>
|
||||
|
||||
<para>This type must be a signed integral type supporting atomic operations.
|
||||
<para>This type must be a signed integral type supporting atomic operations.
|
||||
If you're using the OS approach, use the same type used by your system's
|
||||
primitives. Otherwise, use the type for which your CPU provides atomic
|
||||
primitives.
|
||||
@ -473,7 +473,7 @@ must be equivalent to those provided here, but using atomic operations:
|
||||
*__mem += __val;
|
||||
return __result;
|
||||
}
|
||||
|
||||
|
||||
static inline void
|
||||
__attribute__ ((__unused__))
|
||||
__atomic_add (_Atomic_word* __mem, int __val)
|
||||
@ -489,17 +489,17 @@ must be equivalent to those provided here, but using atomic operations:
|
||||
<title>Numeric Limits</title>
|
||||
|
||||
<para>The C++ library requires information about the fundamental data types,
|
||||
such as the minimum and maximum representable values of each type.
|
||||
such as the minimum and maximum representable values of each type.
|
||||
You can define each of these values individually, but it is usually
|
||||
easiest just to indicate how many bits are used in each of the data
|
||||
types and let the library do the rest. For information about the
|
||||
macros to define, see the top of <code>include/bits/std_limits.h</code>.
|
||||
</para>
|
||||
|
||||
<para>If you need to define any macros, you can do so in <code>os_defines.h</code>.
|
||||
<para>If you need to define any macros, you can do so in <code>os_defines.h</code>.
|
||||
However, if all operating systems for your CPU are likely to use the
|
||||
same values, you can provide a CPU-specific file instead so that you
|
||||
do not have to provide the same definitions for each operating system.
|
||||
do not have to provide the same definitions for each operating system.
|
||||
To take that approach, create a new file called <code>cpu_limits.h</code> in
|
||||
your CPU configuration directory (see <link linkend="internals.cpu">CPU</link>).
|
||||
</para>
|
||||
@ -510,7 +510,7 @@ your CPU configuration directory (see <link linkend="internals.cpu">CPU</link>).
|
||||
<sect2 id="internals.libtool">
|
||||
<title>Libtool</title>
|
||||
|
||||
<para>The C++ library is compiled, archived and linked with libtool.
|
||||
<para>The C++ library is compiled, archived and linked with libtool.
|
||||
Explaining the full workings of libtool is beyond the scope of this
|
||||
document, but there are a few, particular bits that are necessary for
|
||||
porting.
|
||||
|
@ -1,11 +1,11 @@
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
<!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
[ ]>
|
||||
|
||||
<part id="manual.intro" xreflabel="Introduction">
|
||||
<?dbhtml filename="intro.html"?>
|
||||
|
||||
|
||||
<partinfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
@ -31,22 +31,22 @@
|
||||
<title>Implementation Status</title>
|
||||
|
||||
<!-- Section 01.1 : Status C++ 1998 -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="status_cxx1998.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Section 01.2 : Status C++ 200x -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="status_cxx200x.xml">
|
||||
</xi:include>
|
||||
</xi:include>
|
||||
|
||||
<!-- Section 01.3 : Status C++ TR1 -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="status_cxxtr1.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Section 01.4 : Status C++ TR24733 -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="status_cxxtr24733.xml">
|
||||
</xi:include>
|
||||
</sect1>
|
||||
@ -57,7 +57,7 @@
|
||||
<title>License</title>
|
||||
<para>
|
||||
There are two licenses affecting GNU libstdc++: one for the code,
|
||||
and one for the documentation.
|
||||
and one for the documentation.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -69,7 +69,7 @@
|
||||
|
||||
<sect2 id="manual.intro.status.license.gpl" xreflabel="License GPL">
|
||||
<title>The Code: GPL</title>
|
||||
|
||||
|
||||
<para>
|
||||
The source code is distributed under the <link
|
||||
linkend="appendix.gpl-3.0">GNU General Public License version 3</link>,
|
||||
@ -77,7 +77,7 @@
|
||||
the <quote>GCC Runtime Library Exception, version 3.1</quote>
|
||||
as follows (or see the file COPYING.RUNTIME):
|
||||
</para>
|
||||
|
||||
|
||||
<literallayout>
|
||||
GCC RUNTIME LIBRARY EXCEPTION
|
||||
|
||||
@ -152,7 +152,7 @@ The availability of this Exception does not imply any general
|
||||
presumption that third-party software is unaffected by the copyleft
|
||||
requirements of the license of GCC.
|
||||
</literallayout>
|
||||
|
||||
|
||||
<para>
|
||||
Hopefully that text is self-explanatory. If it isn't, you need to speak
|
||||
to your lawyer, or the Free Software Foundation.
|
||||
@ -161,7 +161,7 @@ requirements of the license of GCC.
|
||||
|
||||
<sect2 id="manual.intro.status.license.fdl" xreflabel="License FDL">
|
||||
<title>The Documentation: GPL, FDL</title>
|
||||
|
||||
|
||||
<para>
|
||||
The documentation shipped with the library and made available over
|
||||
the web, excluding the pages generated from source comments, are
|
||||
@ -170,14 +170,14 @@ requirements of the license of GCC.
|
||||
License version 1.2</link>. There are no Front-Cover Texts, no
|
||||
Back-Cover Texts, and no Invariant Sections.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
||||
<para>
|
||||
For documentation generated by doxygen or other automated tools
|
||||
via processing source code comments and markup, the original source
|
||||
code license applies to the generated files. Thus, the doxygen
|
||||
documents are licensed <link linkend="appendix.gpl-3.0">GPL</link>.
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
If you plan on making copies of the documentation, please let us know.
|
||||
We can probably offer suggestions.
|
||||
@ -185,7 +185,7 @@ requirements of the license of GCC.
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
|
||||
<!-- Section 03 : Known Bugs -->
|
||||
<sect1 id="manual.intro.status.bugs" xreflabel="Bugs">
|
||||
<?dbhtml filename="bugs.html"?>
|
||||
@ -242,590 +242,590 @@ requirements of the license of GCC.
|
||||
|
||||
<variablelist>
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#5">5</ulink>:
|
||||
<emphasis>string::compare specification questionable</emphasis>
|
||||
<emphasis>string::compare specification questionable</emphasis>
|
||||
</term>
|
||||
<listitem><para>This should be two overloaded functions rather than a single function.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#17">17</ulink>:
|
||||
<emphasis>Bad bool parsing</emphasis>
|
||||
<emphasis>Bad bool parsing</emphasis>
|
||||
</term>
|
||||
<listitem><para>Apparently extracting Boolean values was messed up...
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#19">19</ulink>:
|
||||
<emphasis>"Noconv" definition too vague</emphasis>
|
||||
<emphasis>"Noconv" definition too vague</emphasis>
|
||||
</term>
|
||||
<listitem><para>If <code>codecvt::do_in</code> returns <code>noconv</code> there are
|
||||
no changes to the values in <code>[to, to_limit)</code>.
|
||||
no changes to the values in <code>[to, to_limit)</code>.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#22">22</ulink>:
|
||||
<emphasis>Member open vs flags</emphasis>
|
||||
<emphasis>Member open vs flags</emphasis>
|
||||
</term>
|
||||
<listitem><para>Re-opening a file stream does <emphasis>not</emphasis> clear the state flags.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#23">23</ulink>:
|
||||
<emphasis>Num_get overflow result</emphasis>
|
||||
<emphasis>Num_get overflow result</emphasis>
|
||||
</term>
|
||||
<listitem><para>Implement the proposed resolution.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#25">25</ulink>:
|
||||
<emphasis>String operator<< uses width() value wrong</emphasis>
|
||||
<emphasis>String operator<< uses width() value wrong</emphasis>
|
||||
</term>
|
||||
<listitem><para>Padding issues.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#48">48</ulink>:
|
||||
<emphasis>Use of non-existent exception constructor</emphasis>
|
||||
<emphasis>Use of non-existent exception constructor</emphasis>
|
||||
</term>
|
||||
<listitem><para>An instance of <code>ios_base::failure</code> is constructed instead.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#49">49</ulink>:
|
||||
<emphasis>Underspecification of ios_base::sync_with_stdio</emphasis>
|
||||
<emphasis>Underspecification of ios_base::sync_with_stdio</emphasis>
|
||||
</term>
|
||||
<listitem><para>The return type is the <emphasis>previous</emphasis> state of synchronization.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#50">50</ulink>:
|
||||
<emphasis>Copy constructor and assignment operator of ios_base</emphasis>
|
||||
<emphasis>Copy constructor and assignment operator of ios_base</emphasis>
|
||||
</term>
|
||||
<listitem><para>These members functions are declared <code>private</code> and are
|
||||
thus inaccessible. Specifying the correct semantics of
|
||||
"copying stream state" was deemed too complicated.
|
||||
thus inaccessible. Specifying the correct semantics of
|
||||
"copying stream state" was deemed too complicated.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#60">60</ulink>:
|
||||
<emphasis>What is a formatted input function?</emphasis>
|
||||
<emphasis>What is a formatted input function?</emphasis>
|
||||
</term>
|
||||
<listitem><para>This DR made many widespread changes to <code>basic_istream</code>
|
||||
and <code>basic_ostream</code> all of which have been implemented.
|
||||
and <code>basic_ostream</code> all of which have been implemented.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#63">63</ulink>:
|
||||
<emphasis>Exception-handling policy for unformatted output</emphasis>
|
||||
<emphasis>Exception-handling policy for unformatted output</emphasis>
|
||||
</term>
|
||||
<listitem><para>Make the policy consistent with that of formatted input, unformatted
|
||||
input, and formatted output.
|
||||
input, and formatted output.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#68">68</ulink>:
|
||||
<emphasis>Extractors for char* should store null at end</emphasis>
|
||||
<emphasis>Extractors for char* should store null at end</emphasis>
|
||||
</term>
|
||||
<listitem><para>And they do now. An editing glitch in the last item in the list of
|
||||
[27.6.1.2.3]/7.
|
||||
[27.6.1.2.3]/7.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#74">74</ulink>:
|
||||
<emphasis>Garbled text for codecvt::do_max_length</emphasis>
|
||||
<emphasis>Garbled text for codecvt::do_max_length</emphasis>
|
||||
</term>
|
||||
<listitem><para>The text of the standard was gibberish. Typos gone rampant.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#75">75</ulink>:
|
||||
<emphasis>Contradiction in codecvt::length's argument types</emphasis>
|
||||
<emphasis>Contradiction in codecvt::length's argument types</emphasis>
|
||||
</term>
|
||||
<listitem><para>Change the first parameter to <code>stateT&</code> and implement
|
||||
the new effects paragraph.
|
||||
the new effects paragraph.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#83">83</ulink>:
|
||||
<emphasis>string::npos vs. string::max_size()</emphasis>
|
||||
<emphasis>string::npos vs. string::max_size()</emphasis>
|
||||
</term>
|
||||
<listitem><para>Safety checks on the size of the string should test against
|
||||
<code>max_size()</code> rather than <code>npos</code>.
|
||||
<code>max_size()</code> rather than <code>npos</code>.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#90">90</ulink>:
|
||||
<emphasis>Incorrect description of operator>> for strings</emphasis>
|
||||
<emphasis>Incorrect description of operator>> for strings</emphasis>
|
||||
</term>
|
||||
<listitem><para>The effect contain <code>isspace(c,getloc())</code> which must be
|
||||
replaced by <code>isspace(c,is.getloc())</code>.
|
||||
replaced by <code>isspace(c,is.getloc())</code>.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#91">91</ulink>:
|
||||
<emphasis>Description of operator>> and getline() for string<>
|
||||
<emphasis>Description of operator>> and getline() for string<>
|
||||
might cause endless loop</emphasis>
|
||||
</term>
|
||||
<listitem><para>They behave as a formatted input function and as an unformatted
|
||||
input function, respectively (except that <code>getline</code> is
|
||||
input function, respectively (except that <code>getline</code> is
|
||||
not required to set <code>gcount</code>).
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#103">103</ulink>:
|
||||
<emphasis>set::iterator is required to be modifiable, but this allows
|
||||
<emphasis>set::iterator is required to be modifiable, but this allows
|
||||
modification of keys.</emphasis>
|
||||
</term>
|
||||
<listitem><para>For associative containers where the value type is the same as
|
||||
the key type, both <code>iterator</code> and <code>const_iterator
|
||||
the key type, both <code>iterator</code> and <code>const_iterator
|
||||
</code> are constant iterators.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#109">109</ulink>:
|
||||
<emphasis>Missing binders for non-const sequence elements</emphasis>
|
||||
<emphasis>Missing binders for non-const sequence elements</emphasis>
|
||||
</term>
|
||||
<listitem><para>The <code>binder1st</code> and <code>binder2nd</code> didn't have an
|
||||
<code>operator()</code> taking a non-const parameter.
|
||||
<code>operator()</code> taking a non-const parameter.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#110">110</ulink>:
|
||||
<emphasis>istreambuf_iterator::equal not const</emphasis>
|
||||
<emphasis>istreambuf_iterator::equal not const</emphasis>
|
||||
</term>
|
||||
<listitem><para>This was not a const member function. Note that the DR says to
|
||||
replace the function with a const one; we have instead provided an
|
||||
overloaded version with identical contents.
|
||||
replace the function with a const one; we have instead provided an
|
||||
overloaded version with identical contents.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#117">117</ulink>:
|
||||
<emphasis>basic_ostream uses nonexistent num_put member functions</emphasis>
|
||||
<emphasis>basic_ostream uses nonexistent num_put member functions</emphasis>
|
||||
</term>
|
||||
<listitem><para><code>num_put::put()</code> was overloaded on the wrong types.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#118">118</ulink>:
|
||||
<emphasis>basic_istream uses nonexistent num_get member functions</emphasis>
|
||||
<emphasis>basic_istream uses nonexistent num_get member functions</emphasis>
|
||||
</term>
|
||||
<listitem><para>Same as 117, but for <code>num_get::get()</code>.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#129">129</ulink>:
|
||||
<emphasis>Need error indication from seekp() and seekg()</emphasis>
|
||||
<emphasis>Need error indication from seekp() and seekg()</emphasis>
|
||||
</term>
|
||||
<listitem><para>These functions set <code>failbit</code> on error now.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#130">130</ulink>:
|
||||
<emphasis>Return type of container::erase(iterator) differs for associative containers</emphasis>
|
||||
<emphasis>Return type of container::erase(iterator) differs for associative containers</emphasis>
|
||||
</term>
|
||||
<listitem><para>Make member <code>erase</code> return iterator for <code>set</code>, <code>multiset</code>, <code>map</code>, <code>multimap</code>.
|
||||
<listitem><para>Make member <code>erase</code> return iterator for <code>set</code>, <code>multiset</code>, <code>map</code>, <code>multimap</code>.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#136">136</ulink>:
|
||||
<emphasis>seekp, seekg setting wrong streams?</emphasis>
|
||||
<emphasis>seekp, seekg setting wrong streams?</emphasis>
|
||||
</term>
|
||||
<listitem><para><code>seekp</code> should only set the output stream, and
|
||||
<code>seekg</code> should only set the input stream.
|
||||
<code>seekg</code> should only set the input stream.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<!--<varlistentry><term><ulink url="../ext/lwg-defects.html#159">159</ulink>:
|
||||
<emphasis>Strange use of underflow()</emphasis>
|
||||
<emphasis>Strange use of underflow()</emphasis>
|
||||
</term>
|
||||
<listitem><para>In fstream.tcc, the basic_filebuf<>::showmanyc() function
|
||||
should probably not be calling <code>underflow()</code>.
|
||||
should probably not be calling <code>underflow()</code>.
|
||||
</para></listitem></varlistentry> -->
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#167">167</ulink>:
|
||||
<emphasis>Improper use of traits_type::length()</emphasis>
|
||||
<emphasis>Improper use of traits_type::length()</emphasis>
|
||||
</term>
|
||||
<listitem><para><code>op<<</code> with a <code>const char*</code> was
|
||||
calculating an incorrect number of characters to write.
|
||||
calculating an incorrect number of characters to write.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#169">169</ulink>:
|
||||
<emphasis>Bad efficiency of overflow() mandated</emphasis>
|
||||
<emphasis>Bad efficiency of overflow() mandated</emphasis>
|
||||
</term>
|
||||
<listitem><para>Grow efficiently the internal array object.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#171">171</ulink>:
|
||||
<emphasis>Strange seekpos() semantics due to joint position</emphasis>
|
||||
<emphasis>Strange seekpos() semantics due to joint position</emphasis>
|
||||
</term>
|
||||
<listitem><para>Quite complex to summarize...
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#181">181</ulink>:
|
||||
<emphasis>make_pair() unintended behavior</emphasis>
|
||||
<emphasis>make_pair() unintended behavior</emphasis>
|
||||
</term>
|
||||
<listitem><para>This function used to take its arguments as reference-to-const, now
|
||||
it copies them (pass by value).
|
||||
it copies them (pass by value).
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#195">195</ulink>:
|
||||
<emphasis>Should basic_istream::sentry's constructor ever set eofbit?</emphasis>
|
||||
<emphasis>Should basic_istream::sentry's constructor ever set eofbit?</emphasis>
|
||||
</term>
|
||||
<listitem><para>Yes, it can, specifically if EOF is reached while skipping whitespace.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#211">211</ulink>:
|
||||
<emphasis>operator>>(istream&, string&) doesn't set failbit</emphasis>
|
||||
<emphasis>operator>>(istream&, string&) doesn't set failbit</emphasis>
|
||||
</term>
|
||||
<listitem><para>If nothing is extracted into the string, <code>op>></code> now
|
||||
sets <code>failbit</code> (which can cause an exception, etc., etc.).
|
||||
sets <code>failbit</code> (which can cause an exception, etc., etc.).
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#214">214</ulink>:
|
||||
<emphasis>set::find() missing const overload</emphasis>
|
||||
<emphasis>set::find() missing const overload</emphasis>
|
||||
</term>
|
||||
<listitem><para>Both <code>set</code> and <code>multiset</code> were missing
|
||||
overloaded find, lower_bound, upper_bound, and equal_range functions
|
||||
for const instances.
|
||||
overloaded find, lower_bound, upper_bound, and equal_range functions
|
||||
for const instances.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#231">231</ulink>:
|
||||
<emphasis>Precision in iostream?</emphasis>
|
||||
<emphasis>Precision in iostream?</emphasis>
|
||||
</term>
|
||||
<listitem><para>For conversion from a floating-point type, <code>str.precision()</code>
|
||||
is specified in the conversion specification.
|
||||
is specified in the conversion specification.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#233">233</ulink>:
|
||||
<emphasis>Insertion hints in associative containers</emphasis>
|
||||
<emphasis>Insertion hints in associative containers</emphasis>
|
||||
</term>
|
||||
<listitem><para>Implement N1780, first check before then check after, insert as close
|
||||
to hint as possible.
|
||||
to hint as possible.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#235">235</ulink>:
|
||||
<emphasis>No specification of default ctor for reverse_iterator</emphasis>
|
||||
<emphasis>No specification of default ctor for reverse_iterator</emphasis>
|
||||
</term>
|
||||
<listitem><para>The declaration of <code>reverse_iterator</code> lists a default constructor.
|
||||
However, no specification is given what this constructor should do.
|
||||
However, no specification is given what this constructor should do.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#241">241</ulink>:
|
||||
<emphasis>Does unique_copy() require CopyConstructible and Assignable?</emphasis>
|
||||
<emphasis>Does unique_copy() require CopyConstructible and Assignable?</emphasis>
|
||||
</term>
|
||||
<listitem><para>Add a helper for forward_iterator/output_iterator, fix the existing
|
||||
one for input_iterator/output_iterator to not rely on Assignability.
|
||||
one for input_iterator/output_iterator to not rely on Assignability.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#243">243</ulink>:
|
||||
<emphasis>get and getline when sentry reports failure</emphasis>
|
||||
<emphasis>get and getline when sentry reports failure</emphasis>
|
||||
</term>
|
||||
<listitem><para>Store a null character only if the character array has a non-zero size.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#251">251</ulink>:
|
||||
<emphasis>basic_stringbuf missing allocator_type</emphasis>
|
||||
<emphasis>basic_stringbuf missing allocator_type</emphasis>
|
||||
</term>
|
||||
<listitem><para>This nested typedef was originally not specified.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#253">253</ulink>:
|
||||
<emphasis>valarray helper functions are almost entirely useless</emphasis>
|
||||
<emphasis>valarray helper functions are almost entirely useless</emphasis>
|
||||
</term>
|
||||
<listitem><para>Make the copy constructor and copy-assignment operator declarations
|
||||
public in gslice_array, indirect_array, mask_array, slice_array; provide
|
||||
public in gslice_array, indirect_array, mask_array, slice_array; provide
|
||||
definitions.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#265">265</ulink>:
|
||||
<emphasis>std::pair::pair() effects overly restrictive</emphasis>
|
||||
<emphasis>std::pair::pair() effects overly restrictive</emphasis>
|
||||
</term>
|
||||
<listitem><para>The default ctor would build its members from copies of temporaries;
|
||||
now it simply uses their respective default ctors.
|
||||
now it simply uses their respective default ctors.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#266">266</ulink>:
|
||||
<emphasis>bad_exception::~bad_exception() missing Effects clause</emphasis>
|
||||
<emphasis>bad_exception::~bad_exception() missing Effects clause</emphasis>
|
||||
</term>
|
||||
<listitem><para>The <code>bad_</code>* classes no longer have destructors (they
|
||||
are trivial), since no description of them was ever given.
|
||||
are trivial), since no description of them was ever given.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#271">271</ulink>:
|
||||
<emphasis>basic_iostream missing typedefs</emphasis>
|
||||
<emphasis>basic_iostream missing typedefs</emphasis>
|
||||
</term>
|
||||
<listitem><para>The typedefs it inherits from its base classes can't be used, since
|
||||
(for example) <code>basic_iostream<T>::traits_type</code> is ambiguous.
|
||||
(for example) <code>basic_iostream<T>::traits_type</code> is ambiguous.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#275">275</ulink>:
|
||||
<emphasis>Wrong type in num_get::get() overloads</emphasis>
|
||||
<emphasis>Wrong type in num_get::get() overloads</emphasis>
|
||||
</term>
|
||||
<listitem><para>Similar to 118.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#280">280</ulink>:
|
||||
<emphasis>Comparison of reverse_iterator to const reverse_iterator</emphasis>
|
||||
<emphasis>Comparison of reverse_iterator to const reverse_iterator</emphasis>
|
||||
</term>
|
||||
<listitem><para>Add global functions with two template parameters.
|
||||
(NB: not added for now a templated assignment operator)
|
||||
(NB: not added for now a templated assignment operator)
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#292">292</ulink>:
|
||||
<emphasis>Effects of a.copyfmt (a)</emphasis>
|
||||
<emphasis>Effects of a.copyfmt (a)</emphasis>
|
||||
</term>
|
||||
<listitem><para>If <code>(this == &rhs)</code> do nothing.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#300">300</ulink>:
|
||||
<emphasis>List::merge() specification incomplete</emphasis>
|
||||
<emphasis>List::merge() specification incomplete</emphasis>
|
||||
</term>
|
||||
<listitem><para>If <code>(this == &x)</code> do nothing.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#303">303</ulink>:
|
||||
<emphasis>Bitset input operator underspecified</emphasis>
|
||||
<emphasis>Bitset input operator underspecified</emphasis>
|
||||
</term>
|
||||
<listitem><para>Basically, compare the input character to
|
||||
<code>is.widen(0)</code> and <code>is.widen(1)</code>.
|
||||
<listitem><para>Basically, compare the input character to
|
||||
<code>is.widen(0)</code> and <code>is.widen(1)</code>.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#305">305</ulink>:
|
||||
<emphasis>Default behavior of codecvt<wchar_t, char,
|
||||
mbstate_t>::length()</emphasis>
|
||||
<emphasis>Default behavior of codecvt<wchar_t, char,
|
||||
mbstate_t>::length()</emphasis>
|
||||
</term>
|
||||
<listitem><para>Do not specify what <code>codecvt<wchar_t, char,
|
||||
mbstate_t>::do_length</code> must return.
|
||||
<listitem><para>Do not specify what <code>codecvt<wchar_t, char,
|
||||
mbstate_t>::do_length</code> must return.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#328">328</ulink>:
|
||||
<emphasis>Bad sprintf format modifier in
|
||||
money_put<>::do_put()</emphasis>
|
||||
<emphasis>Bad sprintf format modifier in
|
||||
money_put<>::do_put()</emphasis>
|
||||
</term>
|
||||
<listitem><para>Change the format string to "%.0Lf".
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#365">365</ulink>:
|
||||
<emphasis>Lack of const-qualification in clause 27</emphasis>
|
||||
<emphasis>Lack of const-qualification in clause 27</emphasis>
|
||||
</term>
|
||||
<listitem><para>Add const overloads of <code>is_open</code>.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#387">387</ulink>:
|
||||
<emphasis>std::complex over-encapsulated</emphasis>
|
||||
<emphasis>std::complex over-encapsulated</emphasis>
|
||||
</term>
|
||||
<listitem><para>Add the <code>real(T)</code> and <code>imag(T)</code>
|
||||
members; in C++0x mode, also adjust the existing
|
||||
<code>real()</code> and <code>imag()</code> members and
|
||||
free functions.
|
||||
members; in C++0x mode, also adjust the existing
|
||||
<code>real()</code> and <code>imag()</code> members and
|
||||
free functions.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#389">389</ulink>:
|
||||
<emphasis>Const overload of valarray::operator[] returns
|
||||
by value</emphasis>
|
||||
<emphasis>Const overload of valarray::operator[] returns
|
||||
by value</emphasis>
|
||||
</term>
|
||||
<listitem><para>Change it to return a <code>const T&</code>.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#396">396</ulink>:
|
||||
<emphasis>what are characters zero and one</emphasis>
|
||||
<emphasis>what are characters zero and one</emphasis>
|
||||
</term>
|
||||
<listitem><para>Implement the proposed resolution.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#402">402</ulink>:
|
||||
<emphasis>Wrong new expression in [some_]allocator::construct</emphasis>
|
||||
<emphasis>Wrong new expression in [some_]allocator::construct</emphasis>
|
||||
</term>
|
||||
<listitem><para>Replace "new" with "::new".
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-active.html#408">408</ulink>:
|
||||
<emphasis>
|
||||
Is vector<reverse_iterator<char*> > forbidden?
|
||||
</emphasis>
|
||||
<emphasis>
|
||||
Is vector<reverse_iterator<char*> > forbidden?
|
||||
</emphasis>
|
||||
</term>
|
||||
<listitem><para>Tweak the debug-mode checks in _Safe_iterator.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#409">409</ulink>:
|
||||
<emphasis>Closing an fstream should clear the error state</emphasis>
|
||||
<emphasis>Closing an fstream should clear the error state</emphasis>
|
||||
</term>
|
||||
<listitem><para>Have <code>open</code> clear the error flags.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-closed.html#431">431</ulink>:
|
||||
<emphasis>Swapping containers with unequal allocators</emphasis>
|
||||
<emphasis>Swapping containers with unequal allocators</emphasis>
|
||||
</term>
|
||||
<listitem><para>Implement Option 3, as per N1599.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#432">432</ulink>:
|
||||
<emphasis>stringbuf::overflow() makes only one write position
|
||||
<emphasis>stringbuf::overflow() makes only one write position
|
||||
available</emphasis>
|
||||
</term>
|
||||
<listitem><para>Implement the resolution, beyond DR 169.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#434">434</ulink>:
|
||||
<emphasis>bitset::to_string() hard to use</emphasis>
|
||||
<emphasis>bitset::to_string() hard to use</emphasis>
|
||||
</term>
|
||||
<listitem><para>Add three overloads, taking fewer template arguments.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#438">438</ulink>:
|
||||
<emphasis>Ambiguity in the "do the right thing" clause</emphasis>
|
||||
<emphasis>Ambiguity in the "do the right thing" clause</emphasis>
|
||||
</term>
|
||||
<listitem><para>Implement the resolution, basically cast less.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#453">453</ulink>:
|
||||
<emphasis>basic_stringbuf::seekoff need not always fail for an empty stream</emphasis>
|
||||
<emphasis>basic_stringbuf::seekoff need not always fail for an empty stream</emphasis>
|
||||
</term>
|
||||
<listitem><para>Don't fail if the next pointer is null and newoff is zero.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#455">455</ulink>:
|
||||
<emphasis>cerr::tie() and wcerr::tie() are overspecified</emphasis>
|
||||
<emphasis>cerr::tie() and wcerr::tie() are overspecified</emphasis>
|
||||
</term>
|
||||
<listitem><para>Initialize cerr tied to cout and wcerr tied to wcout.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#464">464</ulink>:
|
||||
<emphasis>Suggestion for new member functions in standard containers</emphasis>
|
||||
<emphasis>Suggestion for new member functions in standard containers</emphasis>
|
||||
</term>
|
||||
<listitem><para>Add <code>data()</code> to <code>std::vector</code> and
|
||||
<code>at(const key_type&)</code> to <code>std::map</code>.
|
||||
<code>at(const key_type&)</code> to <code>std::map</code>.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#508">508</ulink>:
|
||||
<emphasis>Bad parameters for ranlux64_base_01</emphasis>
|
||||
<emphasis>Bad parameters for ranlux64_base_01</emphasis>
|
||||
</term>
|
||||
<listitem><para>Fix the parameters.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-closed.html#512">512</ulink>:
|
||||
<emphasis>Seeding subtract_with_carry_01 from a single unsigned long</emphasis>
|
||||
<emphasis>Seeding subtract_with_carry_01 from a single unsigned long</emphasis>
|
||||
</term>
|
||||
<listitem><para>Construct a <code>linear_congruential</code> engine and seed with it.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-closed.html#526">526</ulink>:
|
||||
<emphasis>Is it undefined if a function in the standard changes in
|
||||
<emphasis>Is it undefined if a function in the standard changes in
|
||||
parameters?</emphasis>
|
||||
</term>
|
||||
<listitem><para>Use &value.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#538">538</ulink>:
|
||||
<emphasis>241 again: Does unique_copy() require CopyConstructible
|
||||
<emphasis>241 again: Does unique_copy() require CopyConstructible
|
||||
and Assignable?</emphasis>
|
||||
</term>
|
||||
<listitem><para>In case of input_iterator/output_iterator rely on Assignability of
|
||||
input_iterator' value_type.
|
||||
input_iterator' value_type.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-active.html#539">539</ulink>:
|
||||
<emphasis>partial_sum and adjacent_difference should mention
|
||||
requirements</emphasis>
|
||||
<emphasis>partial_sum and adjacent_difference should mention
|
||||
requirements</emphasis>
|
||||
</term>
|
||||
<listitem><para>We were almost doing the right thing, just use std::move
|
||||
in adjacent_difference.
|
||||
in adjacent_difference.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#541">541</ulink>:
|
||||
<emphasis>shared_ptr template assignment and void</emphasis>
|
||||
<emphasis>shared_ptr template assignment and void</emphasis>
|
||||
</term>
|
||||
<listitem><para>Add an auto_ptr<void> specialization.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#543">543</ulink>:
|
||||
<emphasis>valarray slice default constructor</emphasis>
|
||||
<emphasis>valarray slice default constructor</emphasis>
|
||||
</term>
|
||||
<listitem><para>Follow the straightforward proposed resolution.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#550">550</ulink>:
|
||||
<emphasis>What should the return type of pow(float,int) be?</emphasis>
|
||||
<emphasis>What should the return type of pow(float,int) be?</emphasis>
|
||||
</term>
|
||||
<listitem><para>In C++0x mode, remove the pow(float,int), etc., signatures.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#586">586</ulink>:
|
||||
<emphasis>string inserter not a formatted function</emphasis>
|
||||
<emphasis>string inserter not a formatted function</emphasis>
|
||||
</term>
|
||||
<listitem><para>Change it to be a formatted output function (i.e. catch exceptions).
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#596">596</ulink>:
|
||||
<emphasis>27.8.1.3 Table 112 omits "a+" and "a+b" modes</emphasis>
|
||||
<emphasis>27.8.1.3 Table 112 omits "a+" and "a+b" modes</emphasis>
|
||||
</term>
|
||||
<listitem><para>Add the missing modes to fopen_mode.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#630">630</ulink>:
|
||||
<emphasis>arrays of valarray</emphasis>
|
||||
<emphasis>arrays of valarray</emphasis>
|
||||
</term>
|
||||
<listitem><para>Implement the simple resolution.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#660">660</ulink>:
|
||||
<emphasis>Missing bitwise operations</emphasis>
|
||||
<emphasis>Missing bitwise operations</emphasis>
|
||||
</term>
|
||||
<listitem><para>Add the missing operations.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#691">691</ulink>:
|
||||
<emphasis>const_local_iterator cbegin, cend missing from TR1</emphasis>
|
||||
<emphasis>const_local_iterator cbegin, cend missing from TR1</emphasis>
|
||||
</term>
|
||||
<listitem><para>In C++0x mode add cbegin(size_type) and cend(size_type)
|
||||
to the unordered containers.
|
||||
to the unordered containers.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#693">693</ulink>:
|
||||
<emphasis>std::bitset::all() missing</emphasis>
|
||||
<emphasis>std::bitset::all() missing</emphasis>
|
||||
</term>
|
||||
<listitem><para>Add it, consistently with the discussion.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#695">695</ulink>:
|
||||
<emphasis>ctype<char>::classic_table() not accessible</emphasis>
|
||||
<emphasis>ctype<char>::classic_table() not accessible</emphasis>
|
||||
</term>
|
||||
<listitem><para>Make the member functions table and classic_table public.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#696">696</ulink>:
|
||||
<emphasis>istream::operator>>(int&) broken</emphasis>
|
||||
<emphasis>istream::operator>>(int&) broken</emphasis>
|
||||
</term>
|
||||
<listitem><para>Implement the straightforward resolution.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#761">761</ulink>:
|
||||
<emphasis>unordered_map needs an at() member function</emphasis>
|
||||
<emphasis>unordered_map needs an at() member function</emphasis>
|
||||
</term>
|
||||
<listitem><para>In C++0x mode, add at() and at() const.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#775">775</ulink>:
|
||||
<emphasis>Tuple indexing should be unsigned?</emphasis>
|
||||
<emphasis>Tuple indexing should be unsigned?</emphasis>
|
||||
</term>
|
||||
<listitem><para>Implement the int -> size_t replacements.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#776">776</ulink>:
|
||||
<emphasis>Undescribed assign function of std::array</emphasis>
|
||||
<emphasis>Undescribed assign function of std::array</emphasis>
|
||||
</term>
|
||||
<listitem><para>In C++0x mode, remove assign, add fill.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#781">781</ulink>:
|
||||
<emphasis>std::complex should add missing C99 functions</emphasis>
|
||||
<emphasis>std::complex should add missing C99 functions</emphasis>
|
||||
</term>
|
||||
<listitem><para>In C++0x mode, add std::proj.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#809">809</ulink>:
|
||||
<emphasis>std::swap should be overloaded for array types</emphasis>
|
||||
<emphasis>std::swap should be overloaded for array types</emphasis>
|
||||
</term>
|
||||
<listitem><para>Add the overload.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#844">844</ulink>:
|
||||
<emphasis>complex pow return type is ambiguous</emphasis>
|
||||
<emphasis>complex pow return type is ambiguous</emphasis>
|
||||
</term>
|
||||
<listitem><para>In C++0x mode, remove the pow(complex<T>, int) signature.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-defects.html#853">853</ulink>:
|
||||
<emphasis>to_string needs updating with zero and one</emphasis>
|
||||
<emphasis>to_string needs updating with zero and one</emphasis>
|
||||
</term>
|
||||
<listitem><para>Update / add the signatures.
|
||||
</para></listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><ulink url="../ext/lwg-active.html#865">865</ulink>:
|
||||
<emphasis>More algorithms that throw away information</emphasis>
|
||||
<emphasis>More algorithms that throw away information</emphasis>
|
||||
</term>
|
||||
<listitem><para>The traditional HP / SGI return type and value is blessed
|
||||
by the resolution of the DR.
|
||||
by the resolution of the DR.
|
||||
</para></listitem></varlistentry>
|
||||
</variablelist>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
|
||||
@ -859,12 +859,12 @@ requirements of the license of GCC.
|
||||
</para>
|
||||
|
||||
<!-- Section 01 : Prerequisites -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="prerequisites.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Section 02 : Configure -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="configure.xml">
|
||||
</xi:include>
|
||||
|
||||
|
@ -1,12 +1,12 @@
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
[ ]>
|
||||
|
||||
<part id="manual.io" xreflabel="Input and Output">
|
||||
<chapter id="std.io" xreflabel="Input and Output">
|
||||
<?dbhtml filename="io.html"?>
|
||||
|
||||
<partinfo>
|
||||
|
||||
<chapterinfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
ISO C++
|
||||
@ -15,15 +15,15 @@
|
||||
library
|
||||
</keyword>
|
||||
</keywordset>
|
||||
</partinfo>
|
||||
</chapterinfo>
|
||||
|
||||
<title>
|
||||
Input and Output
|
||||
<indexterm><primary>Input and Output</primary></indexterm>
|
||||
</title>
|
||||
|
||||
<!-- Chapter 01 : Iostream Objects -->
|
||||
<chapter id="manual.io.objects" xreflabel="IO Objects">
|
||||
<!-- Sect1 01 : Iostream Objects -->
|
||||
<sect1 id="std.io.objects" xreflabel="IO Objects">
|
||||
<?dbhtml filename="iostream_objects.html"?>
|
||||
<title>Iostream Objects</title>
|
||||
|
||||
@ -46,8 +46,8 @@
|
||||
|
||||
class MyClass
|
||||
{
|
||||
....
|
||||
std::ifstream& input_file;
|
||||
....
|
||||
std::ifstream& input_file;
|
||||
};
|
||||
|
||||
extern std::ostream& operator<< (std::ostream&, MyClass&);
|
||||
@ -115,19 +115,19 @@
|
||||
|
||||
namespace std
|
||||
{
|
||||
extern istream cin;
|
||||
extern ostream cout;
|
||||
....
|
||||
extern istream cin;
|
||||
extern ostream cout;
|
||||
....
|
||||
|
||||
// this is explained below
|
||||
<emphasis>static ios_base::Init __foo;</emphasis> // not its real name
|
||||
// this is explained below
|
||||
<emphasis>static ios_base::Init __foo;</emphasis> // not its real name
|
||||
}
|
||||
</programlisting>
|
||||
<para>Now, the runtime penalty mentioned previously: the global objects
|
||||
must be initialized before any of your own code uses them; this is
|
||||
guaranteed by the standard. Like any other global object, they must
|
||||
be initialized once and only once. This is typically done with a
|
||||
construct like the one above, and the nested class ios_base::Init is
|
||||
construct like the one above, and the nested class ios_base::Init is
|
||||
specified in the standard for just this reason.
|
||||
</para>
|
||||
<para>How does it work? Because the header is included before any of your
|
||||
@ -157,14 +157,14 @@
|
||||
compile times will go down when there's less parsing work to do.
|
||||
</para>
|
||||
|
||||
</chapter>
|
||||
</sect1>
|
||||
|
||||
<!-- Chapter 02 : Stream Buffers -->
|
||||
<chapter id="manual.io.streambufs" xreflabel="Stream Buffers">
|
||||
<!-- Sect1 02 : Stream Buffers -->
|
||||
<sect1 id="std.io.streambufs" xreflabel="Stream Buffers">
|
||||
<?dbhtml filename="streambufs.html"?>
|
||||
<title>Stream Buffers</title>
|
||||
|
||||
<sect1 id="io.streambuf.derived" xreflabel="Derived streambuf Classes">
|
||||
<sect2 id="io.streambuf.derived" xreflabel="Derived streambuf Classes">
|
||||
<title>Derived streambuf Classes</title>
|
||||
<para>
|
||||
</para>
|
||||
@ -227,11 +227,11 @@
|
||||
Streambufs</ulink>.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
</sect2>
|
||||
|
||||
<sect1 id="io.streambuf.buffering" xreflabel="Buffering">
|
||||
<sect2 id="io.streambuf.buffering" xreflabel="Buffering">
|
||||
<title>Buffering</title>
|
||||
<para>First, are you sure that you understand buffering? Particularly
|
||||
<para>First, are you sure that you understand buffering? Chaptericularly
|
||||
the fact that C++ may not, in fact, have anything to do with it?
|
||||
</para>
|
||||
<para>The rules for buffering can be a little odd, but they aren't any
|
||||
@ -261,8 +261,8 @@
|
||||
</para>
|
||||
<programlisting>
|
||||
output << "a line of text\n"
|
||||
<< some_data_variable << '\n'
|
||||
<< "another line of text\n"; </programlisting>
|
||||
<< some_data_variable << '\n'
|
||||
<< "another line of text\n"; </programlisting>
|
||||
<para>I have also joined the output statements into a single statement.
|
||||
You could make the code prettier by moving the single newline to
|
||||
the start of the quoted text on the last line, for example.
|
||||
@ -275,7 +275,7 @@
|
||||
output << ...... << flush; // can use std::flush manipulator
|
||||
output.flush(); // or call a member fn </programlisting>
|
||||
<para>On the other hand, there are times when writing to a file should
|
||||
be like writing to standard error; no buffering should be done
|
||||
be like writing to standard error; no buffering should be done
|
||||
because the data needs to appear quickly (a prime example is a
|
||||
log file for security-related information). The way to do this is
|
||||
just to turn off the buffering <emphasis>before any I/O operations at
|
||||
@ -296,14 +296,14 @@
|
||||
is >> i; // and this will probably cause a disk read </programlisting>
|
||||
<para>Since all aspects of buffering are handled by a streambuf-derived
|
||||
member, it is necessary to get at that member with <code>rdbuf()</code>.
|
||||
Then the public version of <code>setbuf</code> can be called. The
|
||||
Then the public version of <code>setbuf</code> can be called. The
|
||||
arguments are the same as those for the Standard C I/O Library
|
||||
function (a buffer area followed by its size).
|
||||
</para>
|
||||
<para>A great deal of this is implementation-dependent. For example,
|
||||
<code>streambuf</code> does not specify any actions for its own
|
||||
<code>streambuf</code> does not specify any actions for its own
|
||||
<code>setbuf()</code>-ish functions; the classes derived from
|
||||
<code>streambuf</code> each define behavior that "makes
|
||||
<code>streambuf</code> each define behavior that "makes
|
||||
sense" for that class: an argument of (0,0) turns off buffering
|
||||
for <code>filebuf</code> but does nothing at all for its siblings
|
||||
<code>stringbuf</code> and <code>strstreambuf</code>, and specifying
|
||||
@ -320,21 +320,21 @@
|
||||
changing those are system-dependent.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<!-- Chapter 03 : Memory-based Streams -->
|
||||
<chapter id="manual.io.memstreams" xreflabel="Memory Streams">
|
||||
<!-- Sect1 03 : Memory-based Streams -->
|
||||
<sect1 id="std.io.memstreams" xreflabel="Memory Streams">
|
||||
<?dbhtml filename="stringstreams.html"?>
|
||||
<title>Memory Based Streams</title>
|
||||
<sect1 id="manual.io.memstreams.compat" xreflabel="Compatibility strstream">
|
||||
<sect2 id="std.io.memstreams.compat" xreflabel="Compatibility strstream">
|
||||
<title>Compatibility With strstream</title>
|
||||
<para>
|
||||
</para>
|
||||
<para>Stringstreams (defined in the header <code><sstream></code>)
|
||||
are in this author's opinion one of the coolest things since
|
||||
sliced time. An example of their use is in the Received Wisdom
|
||||
section for Chapter 21 (Strings),
|
||||
section for Sect1 21 (Strings),
|
||||
<link linkend="strings.string.Cstring"> describing how to
|
||||
format strings</link>.
|
||||
</para>
|
||||
@ -367,15 +367,15 @@
|
||||
</para>
|
||||
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<!-- Chapter 04 : File-based Streams -->
|
||||
<chapter id="manual.io.filestreams" xreflabel="File Streams">
|
||||
<!-- Sect1 04 : File-based Streams -->
|
||||
<sect1 id="std.io.filestreams" xreflabel="File Streams">
|
||||
<?dbhtml filename="fstreams.html"?>
|
||||
<title>File Based Streams</title>
|
||||
|
||||
<sect1 id="manual.io.filestreams.copying_a_file" xreflabel="Copying a File">
|
||||
<sect2 id="std.io.filestreams.copying_a_file" xreflabel="Copying a File">
|
||||
<title>Copying a File</title>
|
||||
<para>
|
||||
</para>
|
||||
@ -406,7 +406,7 @@
|
||||
<para>Seriously, go do it. Get surprised, then come back. It's worth it.
|
||||
</para>
|
||||
<para>The thing to remember is that the <code>basic_[io]stream</code> classes
|
||||
handle formatting, nothing else. In particular, they break up on
|
||||
handle formatting, nothing else. In chaptericular, they break up on
|
||||
whitespace. The actual reading, writing, and storing of data is
|
||||
handled by the <code>basic_streambuf</code> family. Fortunately, the
|
||||
<code>operator<<</code> is overloaded to take an ostream and
|
||||
@ -416,7 +416,7 @@
|
||||
<para>Why a <emphasis>pointer</emphasis> to streambuf and not just a streambuf? Well,
|
||||
the [io]streams hold pointers (or references, depending on the
|
||||
implementation) to their buffers, not the actual
|
||||
buffers. This allows polymorphic behavior on the part of the buffers
|
||||
buffers. This allows polymorphic behavior on the chapter of the buffers
|
||||
as well as the streams themselves. The pointer is easily retrieved
|
||||
using the <code>rdbuf()</code> member function. Therefore, the easiest
|
||||
way to copy the file is:
|
||||
@ -424,7 +424,7 @@
|
||||
<programlisting>
|
||||
OUT << IN.rdbuf();</programlisting>
|
||||
<para>So what <emphasis>was</emphasis> happening with OUT<<IN? Undefined
|
||||
behavior, since that particular << isn't defined by the Standard.
|
||||
behavior, since that chaptericular << isn't defined by the Standard.
|
||||
I have seen instances where it is implemented, but the character
|
||||
extraction process removes all the whitespace, leaving you with no
|
||||
blank lines and only "Thequickbrownfox...". With
|
||||
@ -433,15 +433,15 @@
|
||||
file then contains a perfect text representation of a hexadecimal
|
||||
address (quite a big surprise). Others don't compile at all.
|
||||
</para>
|
||||
<para>Also note that none of this is specific to o<emphasis>*f*</emphasis>streams.
|
||||
The operators shown above are all defined in the parent
|
||||
<para>Also note that none of this is specific to o<emphasis>*f*</emphasis>streams.
|
||||
The operators shown above are all defined in the parent
|
||||
basic_ostream class and are therefore available with all possible
|
||||
descendants.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
</sect2>
|
||||
|
||||
<sect1 id="manual.io.filestreams.binary" xreflabel="Binary Input and Output">
|
||||
<sect2 id="std.io.filestreams.binary" xreflabel="Binary Input and Output">
|
||||
<title>Binary Input and Output</title>
|
||||
<para>
|
||||
</para>
|
||||
@ -468,12 +468,12 @@
|
||||
under Windows won't accidentally get mapped to a '\n' character, etc.
|
||||
Binary mode is not supposed to suddenly give you a bitstream, and
|
||||
if it is doing so in your program then you've discovered a bug in
|
||||
your vendor's compiler (or some other part of the C++ implementation,
|
||||
your vendor's compiler (or some other chapter of the C++ implementation,
|
||||
possibly the runtime system).
|
||||
</para>
|
||||
<para>Second, using <code><<</code> to write and <code>>></code> to
|
||||
read isn't going to work with the standard file stream classes, even
|
||||
if you use <code>skipws</code> during reading. Why not? Because
|
||||
if you use <code>skipws</code> during reading. Why not? Because
|
||||
ifstream and ofstream exist for the purpose of <emphasis>formatting</emphasis>,
|
||||
not reading and writing. Their job is to interpret the data into
|
||||
text characters, and that's exactly what you don't want to happen
|
||||
@ -492,14 +492,14 @@
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><quote>Derive your own fstream-type classes and write your own
|
||||
<</>> operators to do binary I/O on whatever data
|
||||
types you're using.</quote>
|
||||
<</>> operators to do binary I/O on whatever data
|
||||
types you're using.</quote>
|
||||
</para>
|
||||
<para>
|
||||
This is a Bad Thing, because while
|
||||
the compiler would probably be just fine with it, other humans
|
||||
are going to be confused. The overloaded bitshift operators
|
||||
have a well-defined meaning (formatting), and this breaks it.
|
||||
the compiler would probably be just fine with it, other humans
|
||||
are going to be confused. The overloaded bitshift operators
|
||||
have a well-defined meaning (formatting), and this breaks it.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -521,10 +521,10 @@
|
||||
<quote>Use streambufs, that's what they're there for.</quote>
|
||||
</para>
|
||||
<para>
|
||||
While not trivial for the beginner, this is the best of all
|
||||
solutions. The streambuf/filebuf layer is the layer that is
|
||||
responsible for actual I/O. If you want to use the C++
|
||||
library for binary I/O, this is where you start.
|
||||
While not trivial for the beginner, this is the best of all
|
||||
solutions. The streambuf/filebuf layer is the layer that is
|
||||
responsible for actual I/O. If you want to use the C++
|
||||
library for binary I/O, this is where you start.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
@ -552,7 +552,7 @@
|
||||
</para>
|
||||
<para>Another area of problems is opening text files in binary mode.
|
||||
Generally, binary mode is intended for binary files, and opening
|
||||
text files in binary mode means that you now have to deal with all of
|
||||
text files in binary mode means that you now have to deal with all of
|
||||
those end-of-line and end-of-file problems that we mentioned before.
|
||||
</para>
|
||||
<para>
|
||||
@ -569,17 +569,17 @@
|
||||
invocation of a program to another invocation of the same program
|
||||
on a different platform, etc.
|
||||
</para>
|
||||
</sect1>
|
||||
</sect2>
|
||||
|
||||
</chapter>
|
||||
</sect1>
|
||||
|
||||
<!-- Chapter 03 : Interacting with C -->
|
||||
<chapter id="manual.io.c" xreflabel="Interacting with C">
|
||||
<!-- Sect1 03 : Interacting with C -->
|
||||
<sect1 id="std.io.c" xreflabel="Interacting with C">
|
||||
<?dbhtml filename="io_and_c.html"?>
|
||||
<title>Interacting with C</title>
|
||||
|
||||
|
||||
<sect1 id="manual.io.c.FILE" xreflabel="Using FILE* and file descriptors">
|
||||
<sect2 id="std.io.c.FILE" xreflabel="Using FILE* and file descriptors">
|
||||
<title>Using FILE* and file descriptors</title>
|
||||
<para>
|
||||
See the <link linkend="manual.ext.io">extensions</link> for using
|
||||
@ -587,9 +587,9 @@
|
||||
<classname>ofstream</classname> and
|
||||
<classname>ifstream</classname>.
|
||||
</para>
|
||||
</sect1>
|
||||
</sect2>
|
||||
|
||||
<sect1 id="manual.io.c.sync" xreflabel="Performance Issues">
|
||||
<sect2 id="std.io.c.sync" xreflabel="Performance Issues">
|
||||
<title>Performance</title>
|
||||
<para>
|
||||
Pathetic Performance? Ditch C.
|
||||
@ -641,13 +641,13 @@
|
||||
<para>Note, by the way, that the synchronization requirement only applies to
|
||||
the standard streams (<code>cin</code>, <code>cout</code>,
|
||||
<code>cerr</code>,
|
||||
<code>clog</code>, and their wide-character counterparts). File stream
|
||||
<code>clog</code>, and their wide-character counterchapters). File stream
|
||||
objects that you declare yourself have no such requirement and are fully
|
||||
buffered.
|
||||
</para>
|
||||
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
</part>
|
||||
</chapter>
|
||||
|
@ -1,12 +1,12 @@
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
[ ]>
|
||||
|
||||
<part id="manual.iterators" xreflabel="Iterators">
|
||||
<chapter id="std.iterators" xreflabel="Iterators">
|
||||
<?dbhtml filename="iterators.html"?>
|
||||
|
||||
<partinfo>
|
||||
|
||||
<chapterinfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
ISO C++
|
||||
@ -15,18 +15,18 @@
|
||||
library
|
||||
</keyword>
|
||||
</keywordset>
|
||||
</partinfo>
|
||||
</chapterinfo>
|
||||
|
||||
<title>
|
||||
Iterators
|
||||
<indexterm><primary>Iterators</primary></indexterm>
|
||||
</title>
|
||||
|
||||
<!-- Chapter 01 : Predefined -->
|
||||
<chapter id="manual.iterators.predefined" xreflabel="Predefined">
|
||||
<!-- Sect1 01 : Predefined -->
|
||||
<sect1 id="std.iterators.predefined" xreflabel="Predefined">
|
||||
<title>Predefined</title>
|
||||
|
||||
<sect1 id="iterators.predefined.vs_pointers" xreflabel="Versus Pointers">
|
||||
<sect2 id="iterators.predefined.vs_pointers" xreflabel="Versus Pointers">
|
||||
<title>Iterators vs. Pointers</title>
|
||||
<para>
|
||||
The following
|
||||
@ -35,39 +35,45 @@ iterators are not implemented as pointers. They are a generalization
|
||||
of pointers, but they are implemented in libstdc++ as separate
|
||||
classes.
|
||||
</para>
|
||||
<para>Keeping that simple fact in mind as you design your code will
|
||||
<para>
|
||||
Keeping that simple fact in mind as you design your code will
|
||||
prevent a whole lot of difficult-to-understand bugs.
|
||||
</para>
|
||||
<para>You can think of it the other way 'round, even. Since iterators
|
||||
are a generalization, that means that <emphasis>pointers</emphasis> are
|
||||
<emphasis>iterators</emphasis>, and that pointers can be used whenever an
|
||||
iterator would be. All those functions in the Algorithms chapter
|
||||
of the Standard will work just as well on plain arrays and their
|
||||
pointers.
|
||||
<para>
|
||||
You can think of it the other way 'round, even. Since iterators
|
||||
are a generalization, that means
|
||||
that <emphasis>pointers</emphasis> are
|
||||
<emphasis>iterators</emphasis>, and that pointers can be used
|
||||
whenever an iterator would be. All those functions in the
|
||||
Algorithms sect1 of the Standard will work just as well on plain
|
||||
arrays and their pointers.
|
||||
</para>
|
||||
<para>That doesn't mean that when you pass in a pointer, it gets wrapped
|
||||
into some special delegating iterator-to-pointer class with a layer
|
||||
of overhead. (If you think that's the case anywhere, you don't
|
||||
understand templates to begin with...) Oh, no; if you pass
|
||||
in a pointer, then the compiler will instantiate that template
|
||||
using T* as a type, and good old high-speed pointer arithmetic as
|
||||
its operations, so the resulting code will be doing exactly the same
|
||||
things as it would be doing if you had hand-coded it yourself (for
|
||||
the 273rd time).
|
||||
<para>
|
||||
That doesn't mean that when you pass in a pointer, it gets
|
||||
wrapped into some special delegating iterator-to-pointer class
|
||||
with a layer of overhead. (If you think that's the case
|
||||
anywhere, you don't understand templates to begin with...) Oh,
|
||||
no; if you pass in a pointer, then the compiler will instantiate
|
||||
that template using T* as a type, and good old high-speed
|
||||
pointer arithmetic as its operations, so the resulting code will
|
||||
be doing exactly the same things as it would be doing if you had
|
||||
hand-coded it yourself (for the 273rd time).
|
||||
</para>
|
||||
<para>How much overhead <emphasis>is</emphasis> there when using an iterator class?
|
||||
Very little. Most of the layering classes contain nothing but
|
||||
typedefs, and typedefs are "meta-information" that simply
|
||||
tell the compiler some nicknames; they don't create code. That
|
||||
information gets passed down through inheritance, so while the
|
||||
compiler has to do work looking up all the names, your runtime code
|
||||
does not. (This has been a prime concern from the beginning.)
|
||||
<para>
|
||||
How much overhead <emphasis>is</emphasis> there when using an
|
||||
iterator class? Very little. Most of the layering classes
|
||||
contain nothing but typedefs, and typedefs are
|
||||
"meta-information" that simply tell the compiler some
|
||||
nicknames; they don't create code. That information gets passed
|
||||
down through inheritance, so while the compiler has to do work
|
||||
looking up all the names, your runtime code does not. (This has
|
||||
been a prime concern from the beginning.)
|
||||
</para>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="iterators.predefined.end" xreflabel="end() Is One Past the End">
|
||||
</sect2>
|
||||
|
||||
<sect2 id="iterators.predefined.end" xreflabel="end() Is One Past the End">
|
||||
<title>One Past the End</title>
|
||||
|
||||
<para>This starts off sounding complicated, but is actually very easy,
|
||||
@ -85,23 +91,23 @@ classes.
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>You can point anywhere in the array, <emphasis>or to the first element
|
||||
past the end of the array</emphasis>. A pointer that points to one
|
||||
past the end of the array is guaranteed to be as unique as a
|
||||
pointer to somewhere inside the array, so that you can compare
|
||||
such pointers safely.
|
||||
past the end of the array</emphasis>. A pointer that points to one
|
||||
past the end of the array is guaranteed to be as unique as a
|
||||
pointer to somewhere inside the array, so that you can compare
|
||||
such pointers safely.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>You can only dereference a pointer that points into an array.
|
||||
If your array pointer points outside the array -- even to just
|
||||
one past the end -- and you dereference it, Bad Things happen.
|
||||
If your array pointer points outside the array -- even to just
|
||||
one past the end -- and you dereference it, Bad Things happen.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Strictly speaking, simply pointing anywhere else invokes
|
||||
undefined behavior. Most programs won't puke until such a
|
||||
pointer is actually dereferenced, but the standards leave that
|
||||
up to the platform.
|
||||
undefined behavior. Most programs won't puke until such a
|
||||
pointer is actually dereferenced, but the standards leave that
|
||||
up to the platform.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
@ -121,7 +127,7 @@ classes.
|
||||
| | remember to add or subtract one.
|
||||
| | Off-by-one bugs very common here.
|
||||
V V
|
||||
array of N elements
|
||||
array of N elements
|
||||
|---|---|--...--|---|---|
|
||||
| 0 | 1 | ... |N-2|N-1|
|
||||
|---|---|--...--|---|---|
|
||||
@ -134,7 +140,7 @@ classes.
|
||||
beginning end
|
||||
|
||||
</programlisting>
|
||||
<para>See? Everything between the boundary markers is part of the array.
|
||||
<para>See? Everything between the boundary markers is chapter of the array.
|
||||
Simple.
|
||||
</para>
|
||||
<para>Now think back to your junior-high school algebra course, when you
|
||||
@ -175,9 +181,9 @@ classes.
|
||||
<para>Just don't dereference <code>end()</code>.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<!-- Sect1 02 : Stream -->
|
||||
|
||||
</chapter>
|
||||
|
||||
<!-- Chapter 02 : Stream -->
|
||||
|
||||
</part>
|
||||
|
@ -1,6 +1,6 @@
|
||||
<sect1 id="manual.localization.locales.locale" xreflabel="Locale">
|
||||
<section id="std.localization.locales.locale" xreflabel="Locale">
|
||||
|
||||
<sect1info>
|
||||
<sectioninfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
ISO C++
|
||||
@ -9,7 +9,7 @@
|
||||
locale
|
||||
</keyword>
|
||||
</keywordset>
|
||||
</sect1info>
|
||||
</sectioninfo>
|
||||
|
||||
<title>locale</title>
|
||||
|
||||
@ -19,7 +19,7 @@ classes id, facet, and the reference-counted implementation object,
|
||||
class _Impl.
|
||||
</para>
|
||||
|
||||
<sect2 id="locales.locale.req">
|
||||
<section id="locales.locale.req">
|
||||
<title>Requirements</title>
|
||||
|
||||
<para>
|
||||
@ -87,9 +87,9 @@ class id
|
||||
<para>
|
||||
Provides an index for looking up specific facets.
|
||||
</para>
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<sect2 id="locales.locale.design">
|
||||
<section id="locales.locale.design">
|
||||
<title>Design</title>
|
||||
|
||||
<para>
|
||||
@ -103,12 +103,12 @@ Because C and earlier versions of POSIX fall down so completely,
|
||||
portability is an issue.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<sect2 id="locales.locale.impl">
|
||||
<section id="locales.locale.impl">
|
||||
<title>Implementation</title>
|
||||
|
||||
<sect3 id="locale.impl.c">
|
||||
<section id="locale.impl.c">
|
||||
<title>Interacting with "C" locales</title>
|
||||
|
||||
<itemizedlist>
|
||||
@ -467,10 +467,10 @@ global locale" (emphasis Paolo), that is:
|
||||
practice, the set of LC_ALL, LANG, etc. variable of the shell.
|
||||
</para>
|
||||
|
||||
</sect3>
|
||||
</sect2>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<sect2 id="locales.locale.future">
|
||||
<section id="locales.locale.future">
|
||||
<title>Future</title>
|
||||
|
||||
<itemizedlist>
|
||||
@ -508,7 +508,7 @@ global locale" (emphasis Paolo), that is:
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<bibliography id="locales.locale.biblio">
|
||||
<title>Bibliography</title>
|
||||
@ -634,4 +634,4 @@ global locale" (emphasis Paolo), that is:
|
||||
|
||||
</bibliography>
|
||||
|
||||
</sect1>
|
||||
</section>
|
||||
|
@ -1,12 +1,12 @@
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
[ ]>
|
||||
|
||||
<part id="manual.localization" xreflabel="Localization">
|
||||
<chapter id="std.localization" xreflabel="Localization">
|
||||
<?dbhtml filename="localization.html"?>
|
||||
|
||||
<partinfo>
|
||||
|
||||
<chapterinfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
ISO C++
|
||||
@ -15,45 +15,45 @@
|
||||
library
|
||||
</keyword>
|
||||
</keywordset>
|
||||
</partinfo>
|
||||
</chapterinfo>
|
||||
|
||||
<title>
|
||||
Localization
|
||||
<indexterm><primary>Localization</primary></indexterm>
|
||||
</title>
|
||||
|
||||
<!-- Chapter 01 : Locale -->
|
||||
<chapter id="manual.localization.locales" xreflabel="Locales">
|
||||
<!-- Section 01 : Locale -->
|
||||
<section id="std.localization.locales" xreflabel="Locales">
|
||||
<?dbhtml filename="locales.html"?>
|
||||
<title>Locales</title>
|
||||
|
||||
<!-- Section 01 : locale -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="locale.xml">
|
||||
</xi:include>
|
||||
</chapter>
|
||||
</section>
|
||||
|
||||
<!-- Chapter 02 : Facet -->
|
||||
<chapter id="manual.localization.facet" xreflabel="Facets">
|
||||
<!-- Section 02 : Facet -->
|
||||
<section id="std.localization.facet" xreflabel="Facets">
|
||||
<?dbhtml filename="facets.html"?>
|
||||
<title>Facets aka Categories</title>
|
||||
<title>Facets</title>
|
||||
|
||||
<!-- Section 01 : ctype -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="ctype.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Section 02 : codecvt -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="codecvt.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Section 03 : messages -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="messages.xml">
|
||||
</xi:include>
|
||||
</section>
|
||||
|
||||
<!-- Section 03 : Interacting with C -->
|
||||
|
||||
</chapter>
|
||||
|
||||
<!-- Chapter 03 : Interacting with C -->
|
||||
|
||||
</part>
|
||||
|
@ -1,7 +1,7 @@
|
||||
<sect1 id="manual.localization.facet.messages" xreflabel="Messages">
|
||||
<section id="manual.localization.facet.messages" xreflabel="Messages">
|
||||
<?dbhtml filename="messages.html"?>
|
||||
|
||||
<sect1info>
|
||||
<sectioninfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
ISO C++
|
||||
@ -10,7 +10,7 @@
|
||||
messages
|
||||
</keyword>
|
||||
</keywordset>
|
||||
</sect1info>
|
||||
</sectioninfo>
|
||||
|
||||
<title>messages</title>
|
||||
|
||||
@ -20,7 +20,7 @@ equivalent to Java's java.text.MessageFormat .using either GNU gettext
|
||||
or IEEE 1003.1-200 functions.
|
||||
</para>
|
||||
|
||||
<sect2 id="facet.messages.req">
|
||||
<section id="facet.messages.req">
|
||||
<title>Requirements</title>
|
||||
|
||||
<para>
|
||||
@ -106,9 +106,9 @@ be found, returns dfault.
|
||||
</blockquote>
|
||||
|
||||
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<sect2 id="facet.messages.design">
|
||||
<section id="facet.messages.design">
|
||||
<title>Design</title>
|
||||
|
||||
<para>
|
||||
@ -155,12 +155,12 @@ to be written in English, so translations are always from "en_US" to
|
||||
other, explicitly named locales.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<sect2 id="facet.messages.impl">
|
||||
<section id="facet.messages.impl">
|
||||
<title>Implementation</title>
|
||||
|
||||
<sect3 id="messages.impl.models">
|
||||
<section id="messages.impl.models">
|
||||
<title>Models</title>
|
||||
<para>
|
||||
This is a relatively simple class, on the face of it. The standard
|
||||
@ -226,9 +226,9 @@ message catalog. This simplifies calling conventions for the gnu
|
||||
model.
|
||||
</para>
|
||||
|
||||
</sect3>
|
||||
</section>
|
||||
|
||||
<sect3 id="messages.impl.gnu">
|
||||
<section id="messages.impl.gnu">
|
||||
<title>The GNU Model</title>
|
||||
|
||||
<para>
|
||||
@ -318,10 +318,10 @@ model.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</sect3>
|
||||
</sect2>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<sect2 id="facet.messages.use">
|
||||
<section id="facet.messages.use">
|
||||
<title>Use</title>
|
||||
<para>
|
||||
A simple example using the GNU model of message conversion.
|
||||
@ -349,9 +349,9 @@ void test01()
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<sect2 id="facet.messages.future">
|
||||
<section id="facet.messages.future">
|
||||
<title>Future</title>
|
||||
|
||||
<itemizedlist>
|
||||
@ -436,7 +436,7 @@ void test01()
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<bibliography id="facet.messages.biblio">
|
||||
<title>Bibliography</title>
|
||||
@ -585,4 +585,4 @@ Library and Tools.
|
||||
|
||||
</bibliography>
|
||||
|
||||
</sect1>
|
||||
</section>
|
||||
|
@ -1,6 +1,6 @@
|
||||
<sect1 id="manual.ext.allocator.mt" xreflabel="mt allocator">
|
||||
<?dbhtml filename="mt_allocator.html"?>
|
||||
|
||||
|
||||
<sect1info>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
@ -20,7 +20,7 @@
|
||||
<sect2 id="allocator.mt.intro">
|
||||
<title>Intro</title>
|
||||
|
||||
<para>
|
||||
<para>
|
||||
The mt allocator [hereinafter referred to simply as "the allocator"]
|
||||
is a fixed size (power of two) allocator that was initially
|
||||
developed specifically to suit the needs of multi threaded
|
||||
@ -57,7 +57,7 @@ individual pools, and a class inheriting from the policy class that is
|
||||
the actual allocator.
|
||||
</para>
|
||||
|
||||
<para>The datum describing pools characteristics is
|
||||
<para>The datum describing pools characteristics is
|
||||
</para>
|
||||
<programlisting>
|
||||
template<bool _Thread>
|
||||
@ -151,9 +151,9 @@ int main()
|
||||
tune_type t_single(16, 5120, 32, 5120, 1, 10, false);
|
||||
|
||||
tune_type t;
|
||||
t = allocator_type::_M_get_options();
|
||||
t = allocator_type::_M_get_options();
|
||||
allocator_type::_M_set_options(t_opt);
|
||||
t = allocator_type::_M_get_options();
|
||||
t = allocator_type::_M_get_options();
|
||||
|
||||
allocator_type a;
|
||||
allocator_type::pointer p1 = a.allocate(128);
|
||||
@ -193,18 +193,18 @@ The _S_initialize() function:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
- If the GLIBCXX_FORCE_NEW environment variable is not set, both ST and MT
|
||||
- If the GLIBCXX_FORCE_NEW environment variable is not set, both ST and MT
|
||||
applications will:
|
||||
- Calculate the number of bins needed. A bin is a specific power of two size
|
||||
of bytes. I.e., by default the allocator will deal with requests of up to
|
||||
128 bytes (or whatever the value of _S_max_bytes is when _S_init() is
|
||||
called). This means that there will be bins of the following sizes
|
||||
(in bytes): 1, 2, 4, 8, 16, 32, 64, 128.
|
||||
of bytes. I.e., by default the allocator will deal with requests of up to
|
||||
128 bytes (or whatever the value of _S_max_bytes is when _S_init() is
|
||||
called). This means that there will be bins of the following sizes
|
||||
(in bytes): 1, 2, 4, 8, 16, 32, 64, 128.
|
||||
|
||||
- Create the _S_binmap array. All requests are rounded up to the next
|
||||
"large enough" bin. I.e., a request for 29 bytes will cause a block from
|
||||
the "32 byte bin" to be returned to the application. The purpose of
|
||||
_S_binmap is to speed up the process of finding out which bin to use.
|
||||
- Create the _S_binmap array. All requests are rounded up to the next
|
||||
"large enough" bin. I.e., a request for 29 bytes will cause a block from
|
||||
the "32 byte bin" to be returned to the application. The purpose of
|
||||
_S_binmap is to speed up the process of finding out which bin to use.
|
||||
I.e., the value of _S_binmap[ 29 ] is initialized to 5 (bin 5 = 32 bytes).
|
||||
</para>
|
||||
<para>
|
||||
@ -213,37 +213,37 @@ The _S_initialize() function:
|
||||
earlier. I.e., if _S_max_bytes = 128 there will be 8 entries.
|
||||
Each bin_record is then initialized:
|
||||
- bin_record->first = An array of pointers to block_records. There will be
|
||||
as many block_records pointers as there are maximum number of threads
|
||||
(in a ST application there is only 1 thread, in a MT application there
|
||||
as many block_records pointers as there are maximum number of threads
|
||||
(in a ST application there is only 1 thread, in a MT application there
|
||||
are _S_max_threads).
|
||||
This holds the pointer to the first free block for each thread in this
|
||||
bin. I.e., if we would like to know where the first free block of size 32
|
||||
for thread number 3 is we would look this up by: _S_bin[ 5 ].first[ 3 ]
|
||||
|
||||
The above created block_record pointers members are now initialized to
|
||||
The above created block_record pointers members are now initialized to
|
||||
their initial values. I.e. _S_bin[ n ].first[ n ] = NULL;
|
||||
</para>
|
||||
|
||||
<para>
|
||||
- Additionally a MT application will:
|
||||
- Create a list of free thread id's. The pointer to the first entry
|
||||
is stored in _S_thread_freelist_first. The reason for this approach is
|
||||
that the __gthread_self() call will not return a value that corresponds to
|
||||
is stored in _S_thread_freelist_first. The reason for this approach is
|
||||
that the __gthread_self() call will not return a value that corresponds to
|
||||
the maximum number of threads allowed but rather a process id number or
|
||||
something else. So what we do is that we create a list of thread_records.
|
||||
This list is _S_max_threads long and each entry holds a size_t thread_id
|
||||
which is initialized to 1, 2, 3, 4, 5 and so on up to _S_max_threads.
|
||||
Each time a thread calls allocate() or deallocate() we call
|
||||
Each time a thread calls allocate() or deallocate() we call
|
||||
_S_get_thread_id() which looks at the value of _S_thread_key which is a
|
||||
thread local storage pointer. If this is NULL we know that this is a newly
|
||||
created thread and we pop the first entry from this list and saves the
|
||||
pointer to this record in the _S_thread_key variable. The next time
|
||||
we will get the pointer to the thread_record back and we use the
|
||||
thread_record->thread_id as identification. I.e., the first thread that
|
||||
pointer to this record in the _S_thread_key variable. The next time
|
||||
we will get the pointer to the thread_record back and we use the
|
||||
thread_record->thread_id as identification. I.e., the first thread that
|
||||
calls allocate will get the first record in this list and thus be thread
|
||||
number 1 and will then find the pointer to its first free 32 byte block
|
||||
in _S_bin[ 5 ].first[ 1 ]
|
||||
When we create the _S_thread_key we also define a destructor
|
||||
When we create the _S_thread_key we also define a destructor
|
||||
(_S_thread_key_destr) which means that when the thread dies, this
|
||||
thread_record is returned to the front of this list and the thread id
|
||||
can then be reused if a new thread is created.
|
||||
@ -262,7 +262,7 @@ The _S_initialize() function:
|
||||
has made 678 requests (and no deallocations...) of 32-byte blocks this
|
||||
counter will read 678.
|
||||
|
||||
The above created arrays are now initialized with their initial values.
|
||||
The above created arrays are now initialized with their initial values.
|
||||
I.e. _S_bin[ n ].free[ n ] = 0;
|
||||
</para>
|
||||
<para>
|
||||
@ -368,7 +368,7 @@ This is the first two blocks in freelist for thread id 3 in bin 3 (8 bytes):
|
||||
|
||||
<para>
|
||||
With this in mind we simplify things a bit for a while and say that there is
|
||||
only one thread (a ST application). In this case all operations are made to
|
||||
only one thread (a ST application). In this case all operations are made to
|
||||
what is referred to as the global pool - thread id 0 (No thread may be
|
||||
assigned this id since they span from 1 to _S_max_threads in a MT application).
|
||||
</para>
|
||||
@ -377,28 +377,28 @@ When the application requests memory (calling allocate()) we first look at the
|
||||
requested size and if this is > _S_max_bytes we call new() directly and return.
|
||||
</para>
|
||||
<para>
|
||||
If the requested size is within limits we start by finding out from which
|
||||
If the requested size is within limits we start by finding out from which
|
||||
bin we should serve this request by looking in _S_binmap.
|
||||
</para>
|
||||
<para>
|
||||
A quick look at _S_bin[ bin ].first[ 0 ] tells us if there are any blocks of
|
||||
this size on the freelist (0). If this is not NULL - fine, just remove the
|
||||
block that _S_bin[ bin ].first[ 0 ] points to from the list,
|
||||
block that _S_bin[ bin ].first[ 0 ] points to from the list,
|
||||
update _S_bin[ bin ].first[ 0 ] and return a pointer to that blocks data.
|
||||
</para>
|
||||
<para>
|
||||
If the freelist is empty (the pointer is NULL) we must get memory from the
|
||||
If the freelist is empty (the pointer is NULL) we must get memory from the
|
||||
system and build us a freelist within this memory. All requests for new memory
|
||||
is made in chunks of _S_chunk_size. Knowing the size of a block_record and
|
||||
the bytes that this bin stores we then calculate how many blocks we can create
|
||||
is made in chunks of _S_chunk_size. Knowing the size of a block_record and
|
||||
the bytes that this bin stores we then calculate how many blocks we can create
|
||||
within this chunk, build the list, remove the first block, update the pointer
|
||||
(_S_bin[ bin ].first[ 0 ]) and return a pointer to that blocks data.
|
||||
(_S_bin[ bin ].first[ 0 ]) and return a pointer to that blocks data.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Deallocation is equally simple; the pointer is casted back to a block_record
|
||||
pointer, lookup which bin to use based on the size, add the block to the front
|
||||
of the global freelist and update the pointer as needed
|
||||
pointer, lookup which bin to use based on the size, add the block to the front
|
||||
of the global freelist and update the pointer as needed
|
||||
(_S_bin[ bin ].first[ 0 ]).
|
||||
</para>
|
||||
|
||||
@ -414,8 +414,8 @@ faster than maintaining a set of "last pointers" as well.
|
||||
<title>Multiple Thread Example</title>
|
||||
|
||||
<para>
|
||||
In the ST example we never used the thread_id variable present in each block.
|
||||
Let's start by explaining the purpose of this in a MT application.
|
||||
In the ST example we never used the thread_id variable present in each block.
|
||||
Let's start by explaining the purpose of this in a MT application.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -454,12 +454,12 @@ directly and return.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If the requested size is within limits we start by finding out from which
|
||||
If the requested size is within limits we start by finding out from which
|
||||
bin we should serve this request by looking in _S_binmap.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A call to _S_get_thread_id() returns the thread id for the calling thread
|
||||
A call to _S_get_thread_id() returns the thread id for the calling thread
|
||||
(and if no value has been set in _S_thread_key, a new id is assigned and
|
||||
returned).
|
||||
</para>
|
||||
|
@ -1,12 +1,12 @@
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
[ ]>
|
||||
|
||||
<part id="manual.numerics" xreflabel="Numerics">
|
||||
<chapter id="std.numerics" xreflabel="Numerics">
|
||||
<?dbhtml filename="numerics.html"?>
|
||||
|
||||
<partinfo>
|
||||
|
||||
<chapterinfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
ISO C++
|
||||
@ -15,20 +15,20 @@
|
||||
library
|
||||
</keyword>
|
||||
</keywordset>
|
||||
</partinfo>
|
||||
</chapterinfo>
|
||||
|
||||
<title>
|
||||
Numerics
|
||||
<indexterm><primary>Numerics</primary></indexterm>
|
||||
</title>
|
||||
|
||||
<!-- Chapter 01 : Complex -->
|
||||
<chapter id="manual.numerics.complex" xreflabel="complex">
|
||||
<!-- Sect1 01 : Complex -->
|
||||
<sect1 id="std.numerics.complex" xreflabel="complex">
|
||||
<?dbhtml filename="complex.html"?>
|
||||
<title>Complex</title>
|
||||
<para>
|
||||
</para>
|
||||
<sect1 id="numerics.complex.processing" xreflabel="complex Processing">
|
||||
<sect2 id="numerics.complex.processing" xreflabel="complex Processing">
|
||||
<title>complex Processing</title>
|
||||
<para>
|
||||
</para>
|
||||
@ -49,11 +49,11 @@
|
||||
<code>(u)</code>, and <code>(u,v)</code>.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<!-- Chapter 02 : Generalized Operations -->
|
||||
<chapter id="manual.numerics.generalized_ops" xreflabel="Generalized Ops">
|
||||
<!-- Sect1 02 : Generalized Operations -->
|
||||
<sect1 id="std.numerics.generalized_ops" xreflabel="Generalized Ops">
|
||||
<?dbhtml filename="generalized_numeric_operations.html"?>
|
||||
<title>Generalized Operations</title>
|
||||
<para>
|
||||
@ -68,7 +68,7 @@
|
||||
<itemizedlist>
|
||||
<listitem><para><code>accumulate</code></para></listitem>
|
||||
<listitem><para><code>inner_product</code></para></listitem>
|
||||
<listitem><para><code>partial_sum</code></para></listitem>
|
||||
<listitem><para><code>chapterial_sum</code></para></listitem>
|
||||
<listitem><para><code>adjacent_difference</code></para></listitem>
|
||||
</itemizedlist>
|
||||
<para>Here is a simple example of the two forms of <code>accumulate</code>.
|
||||
@ -93,14 +93,14 @@
|
||||
<para>The other three functions have similar dual-signature forms.
|
||||
</para>
|
||||
|
||||
</chapter>
|
||||
</sect1>
|
||||
|
||||
<!-- Chapter 03 : Interacting with C -->
|
||||
<chapter id="manual.numerics.c" xreflabel="Interacting with C">
|
||||
<!-- Sect1 03 : Interacting with C -->
|
||||
<sect1 id="std.numerics.c" xreflabel="Interacting with C">
|
||||
<?dbhtml filename="numerics_and_c.html"?>
|
||||
<title>Interacting with C</title>
|
||||
|
||||
<sect1 id="numerics.c.array" xreflabel="Numerics vs. Arrays">
|
||||
<sect2 id="numerics.c.array" xreflabel="Numerics vs. Arrays">
|
||||
<title>Numerics vs. Arrays</title>
|
||||
|
||||
<para>One of the major reasons why FORTRAN can chew through numbers so well
|
||||
@ -121,9 +121,9 @@
|
||||
libraries before.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
</sect2>
|
||||
|
||||
<sect1 id="numerics.c.c99" xreflabel="C99">
|
||||
<sect2 id="numerics.c.c99" xreflabel="C99">
|
||||
<title>C99</title>
|
||||
|
||||
<para>In addition to the other topics on this page, we'll note here some
|
||||
@ -143,7 +143,7 @@
|
||||
<code>wcstoll</code>.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
</part>
|
||||
</chapter>
|
||||
|
@ -1,11 +1,11 @@
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
[ ]>
|
||||
|
||||
<chapter id="manual.ext.parallel_mode" xreflabel="Parallel Mode">
|
||||
<?dbhtml filename="parallel_mode.html"?>
|
||||
|
||||
|
||||
<chapterinfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
@ -115,7 +115,7 @@ It might work with other compilers, though.</para>
|
||||
flag <literal>-fopenmp</literal>. This will link
|
||||
in <code>libgomp</code>, the GNU
|
||||
OpenMP <ulink url="http://gcc.gnu.org/onlinedocs/libgomp">implementation</ulink>,
|
||||
whose presence is mandatory.
|
||||
whose presence is mandatory.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -635,7 +635,7 @@ For the following algorithms in general, we have
|
||||
<code>__gnu_parallel::parallel_tag</code> and
|
||||
<code>__gnu_parallel::default_parallel_tag</code>, in addition to
|
||||
<code>__gnu_parallel::sequential_tag</code>.
|
||||
<code>__gnu_parallel::default_parallel_tag</code> chooses the default
|
||||
<code>__gnu_parallel::default_parallel_tag</code> chooses the default
|
||||
algorithm at compiletime, as does omitting the tag.
|
||||
<code>__gnu_parallel::parallel_tag</code> postpones the decision to runtime
|
||||
(see next section).
|
||||
@ -654,7 +654,7 @@ Exact and sampling are the two available splitting strategies.
|
||||
For the <code>sort</code> and <code>stable_sort</code> algorithms, there are
|
||||
several additional choices, namely
|
||||
<code>__gnu_parallel::multiway_mergesort_tag</code>,
|
||||
<code>__gnu_parallel::multiway_mergesort_exact_tag</code>,
|
||||
<code>__gnu_parallel::multiway_mergesort_exact_tag</code>,
|
||||
<code>__gnu_parallel::multiway_mergesort_sampling_tag</code>,
|
||||
<code>__gnu_parallel::quicksort_tag</code>, and
|
||||
<code>__gnu_parallel::balanced_quicksort_tag</code>.
|
||||
@ -767,7 +767,7 @@ explicitly sequential:
|
||||
</para>
|
||||
|
||||
<para> Two namespaces contain the parallel mode:
|
||||
<code>std::__parallel</code> and <code>__gnu_parallel</code>.
|
||||
<code>std::__parallel</code> and <code>__gnu_parallel</code>.
|
||||
</para>
|
||||
|
||||
<para> Parallel implementations of standard components, including
|
||||
@ -794,12 +794,12 @@ the generated source documentation.
|
||||
<sect1 id="manual.ext.parallel_mode.test" xreflabel="Testing">
|
||||
<title>Testing</title>
|
||||
|
||||
<para>
|
||||
<para>
|
||||
Both the normal conformance and regression tests and the
|
||||
supplemental performance tests work.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<para>
|
||||
To run the conformance and regression tests with the parallel mode
|
||||
active,
|
||||
</para>
|
||||
@ -807,13 +807,13 @@ the generated source documentation.
|
||||
<screen>
|
||||
<userinput>make check-parallel</userinput>
|
||||
</screen>
|
||||
|
||||
|
||||
<para>
|
||||
The log and summary files for conformance testing are in the
|
||||
<filename class="directory">testsuite/parallel</filename> directory.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<para>
|
||||
To run the performance tests with the parallel mode active,
|
||||
</para>
|
||||
|
||||
@ -859,7 +859,7 @@ the generated source documentation.
|
||||
Workshop on Highly Parallel Processing on a Chip (HPPC) 2007. (LNCS)
|
||||
</publishername>
|
||||
</publisher>
|
||||
</biblioentry>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry>
|
||||
<title>
|
||||
@ -889,7 +889,7 @@ the generated source documentation.
|
||||
Euro-Par 2007: Parallel Processing. (LNCS 4641)
|
||||
</publishername>
|
||||
</publisher>
|
||||
</biblioentry>
|
||||
</biblioentry>
|
||||
|
||||
</bibliography>
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
<sect1 id="manual.intro.setup.prereq" xreflabel="Prerequisites">
|
||||
<?dbhtml filename="prerequisites.html"?>
|
||||
|
||||
|
||||
<sect1info>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
@ -18,7 +18,7 @@
|
||||
Because libstdc++ is part of GCC, the primary source for
|
||||
installation instructions is
|
||||
<ulink url="http://gcc.gnu.org/install/">the GCC install page</ulink>.
|
||||
In particular, list of prerequisite software needed to build the library
|
||||
In particular, list of prerequisite software needed to build the library
|
||||
<ulink url="http://gcc.gnu.org/install/prerequisites.html">
|
||||
starts with those requirements.</ulink> The same pages also list
|
||||
the tools you will need if you wish to modify the source.
|
||||
@ -41,13 +41,13 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Finally, a few system-specific requirements:
|
||||
Finally, a few system-specific requirements:
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>linux</term>
|
||||
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
If gcc 3.1.0 or later on is being used on linux, an attempt
|
||||
@ -109,50 +109,50 @@ zh_TW BIG5
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<listitem>
|
||||
<para>install all locales</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>with RedHat Linux:
|
||||
</para>
|
||||
<para> <code> export LC_ALL=C </code>
|
||||
<para> <code> export LC_ALL=C </code>
|
||||
</para>
|
||||
<para> <code> rpm -e glibc-common --nodeps </code>
|
||||
<para> <code> rpm -e glibc-common --nodeps </code>
|
||||
</para>
|
||||
<para>
|
||||
<para>
|
||||
<code> rpm -i --define "_install_langs all"
|
||||
glibc-common-2.2.5-34.i386.rpm
|
||||
</code>
|
||||
glibc-common-2.2.5-34.i386.rpm
|
||||
</code>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Instructions for other operating systems solicited.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>install just the necessary locales</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>with Debian Linux:</para>
|
||||
<para> Add the above list, as shown, to the file
|
||||
<code>/etc/locale.gen</code> </para>
|
||||
<para> run <code>/usr/sbin/locale-gen</code> </para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<listitem>
|
||||
<para>on most Unix-like operating systems:</para>
|
||||
<para><code> localedef -i de_DE -f ISO-8859-1 de_DE </code></para>
|
||||
<para>(repeat for each entry in the above list) </para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Instructions for other operating systems solicited.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -1,11 +1,11 @@
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
[ ]>
|
||||
|
||||
<chapter id="manual.ext.profile_mode" xreflabel="Profile Mode">
|
||||
<?dbhtml filename="profile_mode.html"?>
|
||||
|
||||
|
||||
<chapterinfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
@ -35,7 +35,7 @@
|
||||
calls to an instrumentation library to record the internal state of
|
||||
various components at interesting entry/exit points to/from the standard
|
||||
library. Process trace, recognize suboptimal patterns, give advice.
|
||||
For details, see
|
||||
For details, see
|
||||
<ulink url="http://dx.doi.org/10.1109/CGO.2009.36">paper presented at
|
||||
CGO 2009</ulink>.
|
||||
</para>
|
||||
@ -43,7 +43,7 @@
|
||||
<emphasis>Strengths: </emphasis>
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
Unintrusive solution. The application code does not require any
|
||||
Unintrusive solution. The application code does not require any
|
||||
modification.
|
||||
</para></listitem>
|
||||
<listitem><para> The advice is call context sensitive, thus capable of
|
||||
@ -178,7 +178,7 @@ vector-size: improvement = 3: call stack = 0x804842c ...
|
||||
<listitem><para>_GLIBCXX_PROFILE_MAX_WARN_COUNT: set it to the maximum
|
||||
number of warnings desired. The default value is 10.</para></listitem>
|
||||
<listitem><para>
|
||||
<code>_GLIBCXX_PROFILE_MAX_STACK_DEPTH</code>: if set to 0,
|
||||
<code>_GLIBCXX_PROFILE_MAX_STACK_DEPTH</code>: if set to 0,
|
||||
the advice will
|
||||
be collected and reported for the program as a whole, and not for each
|
||||
call context.
|
||||
@ -196,7 +196,7 @@ vector-size: improvement = 3: call stack = 0x804842c ...
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<code>_GLIBCXX_PROFILE_NO_THREADS</code>:
|
||||
Make the library not use threads. If thread local storage (TLS) is not
|
||||
Make the library not use threads. If thread local storage (TLS) is not
|
||||
available, you will get a preprocessor error asking you to set
|
||||
-D_GLIBCXX_PROFILE_NO_THREADS if your program is single-threaded.
|
||||
Multithreaded execution without TLS is not supported.
|
||||
@ -258,7 +258,7 @@ vector-size: improvement = 3: call stack = 0x804842c ...
|
||||
<para>
|
||||
</para>
|
||||
|
||||
<sect2 id="manual.ext.profile_mode.design.wrapper"
|
||||
<sect2 id="manual.ext.profile_mode.design.wrapper"
|
||||
xreflabel="Wrapper">
|
||||
<title>Wrapper Model</title>
|
||||
<para>
|
||||
@ -267,13 +267,13 @@ vector-size: improvement = 3: call stack = 0x804842c ...
|
||||
we use the same wrapper model as the debug mode.
|
||||
We subclass entities from the release version. Wherever
|
||||
<code>_GLIBCXX_PROFILE</code> is defined, the release namespace is
|
||||
<code>std::__norm</code>, whereas the profile namespace is
|
||||
<code>std::__norm</code>, whereas the profile namespace is
|
||||
<code>std::__profile</code>. Using plain <code>std</code> translates
|
||||
into <code>std::__profile</code>.
|
||||
</para>
|
||||
<para>
|
||||
Whenever possible, we try to wrap at the public interface level, e.g.,
|
||||
in <code>unordered_set</code> rather than in <code>hashtable</code>,
|
||||
in <code>unordered_set</code> rather than in <code>hashtable</code>,
|
||||
in order not to depend on implementation.
|
||||
</para>
|
||||
<para>
|
||||
@ -288,20 +288,20 @@ vector-size: improvement = 3: call stack = 0x804842c ...
|
||||
</sect2>
|
||||
|
||||
|
||||
<sect2 id="manual.ext.profile_mode.design.instrumentation"
|
||||
<sect2 id="manual.ext.profile_mode.design.instrumentation"
|
||||
xreflabel="Instrumentation">
|
||||
<title>Instrumentation</title>
|
||||
<para>
|
||||
Instead of instrumenting every public entry and exit point,
|
||||
we chose to add instrumentation on demand, as needed
|
||||
by individual diagnostics.
|
||||
The main reason is that some diagnostics require us to extract bits of
|
||||
The main reason is that some diagnostics require us to extract bits of
|
||||
internal state that are particular only to that diagnostic.
|
||||
We plan to formalize this later, after we learn more about the requirements
|
||||
of several diagnostics.
|
||||
</para>
|
||||
<para>
|
||||
All the instrumentation points can be switched on and off using
|
||||
All the instrumentation points can be switched on and off using
|
||||
<code>-D[_NO]_GLIBCXX_PROFILE_<diagnostic></code> options.
|
||||
With all the instrumentation calls off, there should be negligible
|
||||
overhead over the release version. This property is needed to support
|
||||
@ -310,13 +310,13 @@ vector-size: improvement = 3: call stack = 0x804842c ...
|
||||
profiling overhead from polluting time measurements, and thus diagnostics.
|
||||
</para>
|
||||
<para>
|
||||
All the instrumentation on/off compile time switches live in
|
||||
All the instrumentation on/off compile time switches live in
|
||||
<code>include/profile/profiler.h</code>.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
|
||||
<sect2 id="manual.ext.profile_mode.design.rtlib"
|
||||
<sect2 id="manual.ext.profile_mode.design.rtlib"
|
||||
xreflabel="Run Time Behavior">
|
||||
<title>Run Time Behavior</title>
|
||||
<para>
|
||||
@ -338,7 +338,7 @@ vector-size: improvement = 3: call stack = 0x804842c ...
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For details, see
|
||||
For details, see
|
||||
<ulink url="http://dx.doi.org/10.1109/CGO.2009.36">paper presented at
|
||||
CGO 2009</ulink>.
|
||||
</para>
|
||||
@ -364,7 +364,7 @@ vector-size: improvement = 3: call stack = 0x804842c ...
|
||||
xreflabel="Cost Model">
|
||||
<title>Cost Model</title>
|
||||
<para>
|
||||
While it is likely that cost models become complex as we get into
|
||||
While it is likely that cost models become complex as we get into
|
||||
more sophisticated analysis, we will try to follow a simple set of rules
|
||||
at the beginning.
|
||||
</para>
|
||||
@ -393,7 +393,7 @@ vector-size: improvement = 3: call stack = 0x804842c ...
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Show stoppers:</emphasis>
|
||||
We may decide that the presence of an operation nullifies the advice.
|
||||
For instance, when considering switching from <code>set</code> to
|
||||
For instance, when considering switching from <code>set</code> to
|
||||
<code>unordered_set</code>, if we detect use of operator <code>++</code>,
|
||||
we will simply not issue the advice, since this could signal that the use
|
||||
care require a sorted container.</para></listitem>
|
||||
@ -536,9 +536,9 @@ it helps the user focus on the key problems and ignore the uninteresting ones.
|
||||
xreflabel="Using the Standard Library in the Runtime Library">
|
||||
<title>Using the Standard Library in the Instrumentation Implementation</title>
|
||||
<para>
|
||||
As much as we would like to avoid uses of libstdc++ within our
|
||||
instrumentation library, containers such as unordered_map are very
|
||||
appealing. We plan to use them as long as they are named properly
|
||||
As much as we would like to avoid uses of libstdc++ within our
|
||||
instrumentation library, containers such as unordered_map are very
|
||||
appealing. We plan to use them as long as they are named properly
|
||||
to avoid ambiguity.
|
||||
</para>
|
||||
</sect2>
|
||||
@ -573,7 +573,7 @@ it helps the user focus on the key problems and ignore the uninteresting ones.
|
||||
The profiling library state is initialized at the first call to a profiling
|
||||
method. This allows us to record the construction of all global objects.
|
||||
However, we cannot do the same at destruction time. The trace is written
|
||||
by a function registered by <code>atexit</code>, thus invoked by
|
||||
by a function registered by <code>atexit</code>, thus invoked by
|
||||
<code>exit</code>.
|
||||
</para>
|
||||
</sect2>
|
||||
@ -590,21 +590,21 @@ it helps the user focus on the key problems and ignore the uninteresting ones.
|
||||
<title>Big Picture</title>
|
||||
|
||||
<para>The profile mode headers are included with
|
||||
<code>-D_GLIBCXX_PROFILE</code> through preprocessor directives in
|
||||
<code>-D_GLIBCXX_PROFILE</code> through preprocessor directives in
|
||||
<code>include/std/*</code>.
|
||||
</para>
|
||||
|
||||
<para>Instrumented implementations are provided in
|
||||
<para>Instrumented implementations are provided in
|
||||
<code>include/profile/*</code>. All instrumentation hooks are macros
|
||||
defined in <code>include/profile/profiler.h</code>.
|
||||
</para>
|
||||
|
||||
<para>All the implementation of the instrumentation hooks is in
|
||||
<para>All the implementation of the instrumentation hooks is in
|
||||
<code>include/profile/impl/*</code>. Although all the code gets included,
|
||||
thus is publicly visible, only a small number of functions are called from
|
||||
outside this directory. All calls to hook implementations must be
|
||||
done through macros defined in <code>profiler.h</code>. The macro
|
||||
must ensure (1) that the call is guarded against reentrance and
|
||||
must ensure (1) that the call is guarded against reentrance and
|
||||
(2) that the call can be turned off at compile time using a
|
||||
<code>-D_GLIBCXX_PROFILE_...</code> compiler option.
|
||||
</para>
|
||||
@ -618,7 +618,7 @@ it helps the user focus on the key problems and ignore the uninteresting ones.
|
||||
<para>Let's say the diagnostic name is "magic".
|
||||
</para>
|
||||
|
||||
<para>If you need to instrument a header not already under
|
||||
<para>If you need to instrument a header not already under
|
||||
<code>include/profile/*</code>, first edit the corresponding header
|
||||
under <code>include/std/</code> and add a preprocessor directive such
|
||||
as the one in <code>include/std/vector</code>:
|
||||
@ -670,7 +670,7 @@ it helps the user focus on the key problems and ignore the uninteresting ones.
|
||||
This defines the content of a line in the stack table.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
Define class <code>__trace_magic: public __trace_base<__magic_info,
|
||||
Define class <code>__trace_magic: public __trace_base<__magic_info,
|
||||
__magic_stack_info></code>.
|
||||
It defines the content of the trace associated with this diagnostic.
|
||||
</para></listitem>
|
||||
@ -696,7 +696,7 @@ it helps the user focus on the key problems and ignore the uninteresting ones.
|
||||
<code>-D_GLIBCXX_PROFILE_<diagnostic></code>.
|
||||
Groups of related diagnostics can be turned on with a single switch.
|
||||
For instance, <code>-D_GLIBCXX_PROFILE_LOCALITY</code> is equivalent to
|
||||
<code>-D_GLIBCXX_PROFILE_SOFTWARE_PREFETCH
|
||||
<code>-D_GLIBCXX_PROFILE_SOFTWARE_PREFETCH
|
||||
-D_GLIBCXX_PROFILE_RBTREE_LOCALITY</code>.
|
||||
</para>
|
||||
|
||||
@ -881,7 +881,7 @@ it helps the user focus on the key problems and ignore the uninteresting ones.
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<sect2 id="manual.ext.profile_mode.analysis.template"
|
||||
<sect2 id="manual.ext.profile_mode.analysis.template"
|
||||
xreflabel="Template">
|
||||
<title>Diagnostic Template</title>
|
||||
<itemizedlist>
|
||||
@ -915,7 +915,7 @@ advice sample
|
||||
</sect2>
|
||||
|
||||
|
||||
<sect2 id="manual.ext.profile_mode.analysis.containers"
|
||||
<sect2 id="manual.ext.profile_mode.analysis.containers"
|
||||
xreflabel="Containers">
|
||||
<title>Containers</title>
|
||||
|
||||
@ -924,14 +924,14 @@ advice sample
|
||||
<code>_GLIBCXX_PROFILE_CONTAINERS</code>.
|
||||
</para>
|
||||
|
||||
<sect3 id="manual.ext.profile_mode.analysis.hashtable_too_small"
|
||||
<sect3 id="manual.ext.profile_mode.analysis.hashtable_too_small"
|
||||
xreflabel="Hashtable Too Small">
|
||||
<title>Hashtable Too Small</title>
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Switch:</emphasis>
|
||||
<code>_GLIBCXX_PROFILE_HASHTABLE_TOO_SMALL</code>.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Goal:</emphasis> Detect hashtables with many
|
||||
<listitem><para><emphasis>Goal:</emphasis> Detect hashtables with many
|
||||
rehash operations, small construction size and large destruction size.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Fundamentals:</emphasis> Rehash is very expensive.
|
||||
@ -940,10 +940,10 @@ advice sample
|
||||
<listitem><para><emphasis>Sample runtime reduction:</emphasis> 36%.
|
||||
Code similar to example below.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Recommendation:</emphasis>
|
||||
<listitem><para><emphasis>Recommendation:</emphasis>
|
||||
Set initial size to N at construction site S.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>To instrument:</emphasis>
|
||||
<listitem><para><emphasis>To instrument:</emphasis>
|
||||
<code>unordered_set, unordered_map</code> constructor, destructor, rehash.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Analysis:</emphasis>
|
||||
@ -953,7 +953,7 @@ advice sample
|
||||
Record the estimated rehash cost.</para></listitem>
|
||||
<listitem><para><emphasis>Cost model:</emphasis>
|
||||
Number of individual rehash operations * cost per rehash.</para></listitem>
|
||||
<listitem><para><emphasis>Example:</emphasis>
|
||||
<listitem><para><emphasis>Example:</emphasis>
|
||||
<programlisting>
|
||||
1 unordered_set<int> us;
|
||||
2 for (int k = 0; k < 1000000; ++k) {
|
||||
@ -967,7 +967,7 @@ foo.cc:1: advice: Changing initial unordered_set size from 10 to 1000000 saves 1
|
||||
</sect3>
|
||||
|
||||
|
||||
<sect3 id="manual.ext.profile_mode.analysis.hashtable_too_large"
|
||||
<sect3 id="manual.ext.profile_mode.analysis.hashtable_too_large"
|
||||
xreflabel="Hashtable Too Large">
|
||||
<title>Hashtable Too Large</title>
|
||||
<itemizedlist>
|
||||
@ -983,10 +983,10 @@ foo.cc:1: advice: Changing initial unordered_set size from 10 to 1000000 saves 1
|
||||
fewer cache and TLB misses.</para></listitem>
|
||||
<listitem><para><emphasis>Sample runtime reduction:</emphasis> unknown.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Recommendation:</emphasis>
|
||||
<listitem><para><emphasis>Recommendation:</emphasis>
|
||||
Set initial size to N at construction site S.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>To instrument:</emphasis>
|
||||
<listitem><para><emphasis>To instrument:</emphasis>
|
||||
<code>unordered_set, unordered_map</code> constructor, destructor, rehash.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Analysis:</emphasis>
|
||||
@ -996,7 +996,7 @@ foo.cc:1: advice: Changing initial unordered_set size from 10 to 1000000 saves 1
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Cost model:</emphasis>
|
||||
Number of iteration operations + memory saved.</para></listitem>
|
||||
<listitem><para><emphasis>Example:</emphasis>
|
||||
<listitem><para><emphasis>Example:</emphasis>
|
||||
<programlisting>
|
||||
1 vector<unordered_set<int>> v(100000, unordered_set<int>(100)) ;
|
||||
2 for (int k = 0; k < 100000; ++k) {
|
||||
@ -1022,7 +1022,7 @@ bytes of memory and M iteration steps.
|
||||
<listitem><para><emphasis>Goal:</emphasis> Detect hashtables with polarized
|
||||
distribution.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Fundamentals:</emphasis> A non-uniform
|
||||
<listitem><para><emphasis>Fundamentals:</emphasis> A non-uniform
|
||||
distribution may lead to long chains, thus possibly increasing complexity
|
||||
by a factor up to the number of elements.
|
||||
</para></listitem>
|
||||
@ -1042,7 +1042,7 @@ bytes of memory and M iteration steps.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Cost model:</emphasis>
|
||||
Total number of links traversed.</para></listitem>
|
||||
<listitem><para><emphasis>Example:</emphasis>
|
||||
<listitem><para><emphasis>Example:</emphasis>
|
||||
<programlisting>
|
||||
class dumb_hash {
|
||||
public:
|
||||
@ -1059,14 +1059,14 @@ class dumb_hash {
|
||||
</itemizedlist>
|
||||
</sect3>
|
||||
|
||||
<sect3 id="manual.ext.profile_mode.analysis.vector_too_small"
|
||||
<sect3 id="manual.ext.profile_mode.analysis.vector_too_small"
|
||||
xreflabel="Vector Too Small">
|
||||
<title>Vector Too Small</title>
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Switch:</emphasis>
|
||||
<code>_GLIBCXX_PROFILE_VECTOR_TOO_SMALL</code>.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Goal:</emphasis>Detect vectors with many
|
||||
<listitem><para><emphasis>Goal:</emphasis>Detect vectors with many
|
||||
resize operations, small construction size and large destruction size..
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Fundamentals:</emphasis>Resizing can be expensive.
|
||||
@ -1081,26 +1081,26 @@ class dumb_hash {
|
||||
<listitem><para><emphasis>Analysis:</emphasis>
|
||||
For each dynamic instance of <code>vector</code>,
|
||||
record initial size and call context of the constructor.
|
||||
Record size increase, if any, after each relevant operation such as
|
||||
Record size increase, if any, after each relevant operation such as
|
||||
<code>push_back</code>. Record the estimated resize cost.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Cost model:</emphasis>
|
||||
Total number of words copied * time to copy a word.</para></listitem>
|
||||
<listitem><para><emphasis>Example:</emphasis>
|
||||
<listitem><para><emphasis>Example:</emphasis>
|
||||
<programlisting>
|
||||
1 vector<int> v;
|
||||
2 for (int k = 0; k < 1000000; ++k) {
|
||||
3 v.push_back(k);
|
||||
4 }
|
||||
|
||||
foo.cc:1: advice: Changing initial vector size from 10 to 1000000 saves
|
||||
foo.cc:1: advice: Changing initial vector size from 10 to 1000000 saves
|
||||
copying 4000000 bytes and 20 memory allocations and deallocations.
|
||||
</programlisting>
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</sect3>
|
||||
|
||||
<sect3 id="manual.ext.profile_mode.analysis.vector_too_large"
|
||||
<sect3 id="manual.ext.profile_mode.analysis.vector_too_large"
|
||||
xreflabel="Vector Too Large">
|
||||
<title>Vector Too Large</title>
|
||||
<itemizedlist>
|
||||
@ -1126,7 +1126,7 @@ copying 4000000 bytes and 20 memory allocations and deallocations.
|
||||
with its size at destruction time.</para></listitem>
|
||||
<listitem><para><emphasis>Cost model:</emphasis>
|
||||
Total amount of memory saved.</para></listitem>
|
||||
<listitem><para><emphasis>Example:</emphasis>
|
||||
<listitem><para><emphasis>Example:</emphasis>
|
||||
<programlisting>
|
||||
1 vector<vector<int>> v(100000, vector<int>(100)) ;
|
||||
2 for (int k = 0; k < 100000; ++k) {
|
||||
@ -1142,14 +1142,14 @@ bytes of memory and may reduce the number of cache and TLB misses.
|
||||
</itemizedlist>
|
||||
</sect3>
|
||||
|
||||
<sect3 id="manual.ext.profile_mode.analysis.vector_to_hashtable"
|
||||
<sect3 id="manual.ext.profile_mode.analysis.vector_to_hashtable"
|
||||
xreflabel="Vector to Hashtable">
|
||||
<title>Vector to Hashtable</title>
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Switch:</emphasis>
|
||||
<code>_GLIBCXX_PROFILE_VECTOR_TO_HASHTABLE</code>.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Goal:</emphasis> Detect uses of
|
||||
<listitem><para><emphasis>Goal:</emphasis> Detect uses of
|
||||
<code>vector</code> that can be substituted with <code>unordered_set</code>
|
||||
to reduce execution time.
|
||||
</para></listitem>
|
||||
@ -1159,7 +1159,7 @@ bytes of memory and may reduce the number of cache and TLB misses.
|
||||
<listitem><para><emphasis>Sample runtime reduction:</emphasis>factor up
|
||||
to container size.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Recommendation:</emphasis>Replace
|
||||
<listitem><para><emphasis>Recommendation:</emphasis>Replace
|
||||
<code>vector</code> with <code>unordered_set</code> at site S.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>To instrument:</emphasis><code>vector</code>
|
||||
@ -1167,7 +1167,7 @@ bytes of memory and may reduce the number of cache and TLB misses.
|
||||
<listitem><para><emphasis>Analysis:</emphasis>
|
||||
For each dynamic instance of <code>vector</code>,
|
||||
record call context of the constructor. Issue the advice only if the
|
||||
only methods called on this <code>vector</code> are <code>push_back</code>,
|
||||
only methods called on this <code>vector</code> are <code>push_back</code>,
|
||||
<code>insert</code> and <code>find</code>.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Cost model:</emphasis>
|
||||
@ -1189,14 +1189,14 @@ comparisons.
|
||||
</itemizedlist>
|
||||
</sect3>
|
||||
|
||||
<sect3 id="manual.ext.profile_mode.analysis.hashtable_to_vector"
|
||||
<sect3 id="manual.ext.profile_mode.analysis.hashtable_to_vector"
|
||||
xreflabel="Hashtable to Vector">
|
||||
<title>Hashtable to Vector</title>
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Switch:</emphasis>
|
||||
<code>_GLIBCXX_PROFILE_HASHTABLE_TO_VECTOR</code>.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Goal:</emphasis> Detect uses of
|
||||
<listitem><para><emphasis>Goal:</emphasis> Detect uses of
|
||||
<code>unordered_set</code> that can be substituted with <code>vector</code>
|
||||
to reduce execution time.
|
||||
</para></listitem>
|
||||
@ -1204,7 +1204,7 @@ comparisons.
|
||||
Hashtable iterator is slower than vector iterator.</para></listitem>
|
||||
<listitem><para><emphasis>Sample runtime reduction:</emphasis>95%.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Recommendation:</emphasis>Replace
|
||||
<listitem><para><emphasis>Recommendation:</emphasis>Replace
|
||||
<code>unordered_set</code> with <code>vector</code> at site S.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>To instrument:</emphasis><code>unordered_set</code>
|
||||
@ -1212,7 +1212,7 @@ comparisons.
|
||||
<listitem><para><emphasis>Analysis:</emphasis>
|
||||
For each dynamic instance of <code>unordered_set</code>,
|
||||
record call context of the constructor. Issue the advice only if the
|
||||
number of <code>find</code>, <code>insert</code> and <code>[]</code>
|
||||
number of <code>find</code>, <code>insert</code> and <code>[]</code>
|
||||
operations on this <code>unordered_set</code> are small relative to the
|
||||
number of elements, and methods <code>begin</code> or <code>end</code>
|
||||
are invoked (suggesting iteration).</para></listitem>
|
||||
@ -1241,12 +1241,12 @@ indirections and may achieve better data locality.
|
||||
<listitem><para><emphasis>Switch:</emphasis>
|
||||
<code>_GLIBCXX_PROFILE_VECTOR_TO_LIST</code>.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Goal:</emphasis> Detect cases where
|
||||
<listitem><para><emphasis>Goal:</emphasis> Detect cases where
|
||||
<code>vector</code> could be substituted with <code>list</code> for
|
||||
better performance.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Fundamentals:</emphasis>
|
||||
Inserting in the middle of a vector is expensive compared to inserting in a
|
||||
Inserting in the middle of a vector is expensive compared to inserting in a
|
||||
list.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Sample runtime reduction:</emphasis>factor up to
|
||||
@ -1266,14 +1266,14 @@ indirections and may achieve better data locality.
|
||||
(Sum(cost(vector::method)) - Sum(cost(list::method)), for
|
||||
method in [push_back, insert, erase])
|
||||
+ (Cost(iterate vector) - Cost(iterate list))</para></listitem>
|
||||
<listitem><para><emphasis>Example:</emphasis>
|
||||
<listitem><para><emphasis>Example:</emphasis>
|
||||
<programlisting>
|
||||
1 vector<int> v;
|
||||
2 for (int i = 0; i < 10000; ++i) {
|
||||
3 v.insert(v.begin(), i);
|
||||
4 }
|
||||
|
||||
foo.cc:1: advice: Changing "vector" to "list" will save about 5,000,000
|
||||
foo.cc:1: advice: Changing "vector" to "list" will save about 5,000,000
|
||||
operations.
|
||||
</programlisting>
|
||||
</para></listitem>
|
||||
@ -1287,7 +1287,7 @@ operations.
|
||||
<listitem><para><emphasis>Switch:</emphasis>
|
||||
<code>_GLIBCXX_PROFILE_LIST_TO_VECTOR</code>.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Goal:</emphasis> Detect cases where
|
||||
<listitem><para><emphasis>Goal:</emphasis> Detect cases where
|
||||
<code>list</code> could be substituted with <code>vector</code> for
|
||||
better performance.
|
||||
</para></listitem>
|
||||
@ -1307,7 +1307,7 @@ operations.
|
||||
(Sum(cost(vector::method)) - Sum(cost(list::method)), for
|
||||
method in [push_back, insert, erase])
|
||||
+ (Cost(iterate vector) - Cost(iterate list))</para></listitem>
|
||||
<listitem><para><emphasis>Example:</emphasis>
|
||||
<listitem><para><emphasis>Example:</emphasis>
|
||||
<programlisting>
|
||||
1 list<int> l;
|
||||
...
|
||||
@ -1330,7 +1330,7 @@ memory references.
|
||||
<listitem><para><emphasis>Switch:</emphasis>
|
||||
<code>_GLIBCXX_PROFILE_LIST_TO_SLIST</code>.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Goal:</emphasis> Detect cases where
|
||||
<listitem><para><emphasis>Goal:</emphasis> Detect cases where
|
||||
<code>list</code> could be substituted with <code>forward_list</code> for
|
||||
better performance.
|
||||
</para></listitem>
|
||||
@ -1354,7 +1354,7 @@ memory references.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Cost model:</emphasis>
|
||||
Always true.</para></listitem>
|
||||
<listitem><para><emphasis>Example:</emphasis>
|
||||
<listitem><para><emphasis>Example:</emphasis>
|
||||
<programlisting>
|
||||
1 list<int> l;
|
||||
...
|
||||
@ -1380,7 +1380,7 @@ foo.cc:1: advice: Change "list" to "forward_list".
|
||||
associative containers can be replaced with unordered ones.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Fundamentals:</emphasis>
|
||||
Insert and search are quicker in a hashtable than in
|
||||
Insert and search are quicker in a hashtable than in
|
||||
a red-black tree.</para></listitem>
|
||||
<listitem><para><emphasis>Sample runtime reduction:</emphasis>52%.
|
||||
</para></listitem>
|
||||
@ -1436,9 +1436,9 @@ foo.cc:1: advice: Change "list" to "forward_list".
|
||||
Quick Sort for a particular call context.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Fundamentals:</emphasis>
|
||||
See papers:
|
||||
See papers:
|
||||
<ulink url="http://portal.acm.org/citation.cfm?doid=1065944.1065981">
|
||||
A framework for adaptive algorithm selection in STAPL</ulink> and
|
||||
A framework for adaptive algorithm selection in STAPL</ulink> and
|
||||
<ulink url="http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4228227">
|
||||
Optimizing Sorting with Machine Learning Algorithms</ulink>.
|
||||
</para></listitem>
|
||||
@ -1450,7 +1450,7 @@ foo.cc:1: advice: Change "list" to "forward_list".
|
||||
algorithm.</para></listitem>
|
||||
<listitem><para><emphasis>Analysis:</emphasis>
|
||||
Issue the advice if the cost model tells us that another sort algorithm
|
||||
would do better on this input. Requires us to know what algorithm we
|
||||
would do better on this input. Requires us to know what algorithm we
|
||||
are using in our sort implementation in release mode.</para></listitem>
|
||||
<listitem><para><emphasis>Cost model:</emphasis>
|
||||
Runtime(algo) for algo in [radix, quick, merge, ...]</para></listitem>
|
||||
@ -1488,7 +1488,7 @@ foo.cc:1: advice: Change "list" to "forward_list".
|
||||
miss in caches.</para></listitem>
|
||||
<listitem><para><emphasis>Sample runtime reduction:</emphasis>25%.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Recommendation:</emphasis> Insert prefetch
|
||||
<listitem><para><emphasis>Recommendation:</emphasis> Insert prefetch
|
||||
instruction.</para></listitem>
|
||||
<listitem><para><emphasis>To instrument:</emphasis> Vector iterator and
|
||||
access operator [].
|
||||
@ -1496,7 +1496,7 @@ foo.cc:1: advice: Change "list" to "forward_list".
|
||||
<listitem><para><emphasis>Analysis:</emphasis>
|
||||
First, get cache line size and page size from system.
|
||||
Then record iterator dereference sequences for which the value is a pointer.
|
||||
For each sequence within a container, issue a warning if successive pointer
|
||||
For each sequence within a container, issue a warning if successive pointer
|
||||
addresses are not within cache lines and do not form a linear pattern
|
||||
(otherwise they may be prefetched by hardware).
|
||||
If they also step across page boundaries, make the warning stronger.
|
||||
@ -1510,14 +1510,14 @@ foo.cc:1: advice: Change "list" to "forward_list".
|
||||
<para>
|
||||
This analysis is a little oversimplified. A better cost model could be
|
||||
created by understanding the capability of the hardware prefetcher.
|
||||
This model could be trained automatically by running a set of synthetic
|
||||
This model could be trained automatically by running a set of synthetic
|
||||
cases.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem><para><emphasis>Cost model:</emphasis>
|
||||
Total distance between pointer values of successive elements in vectors
|
||||
of pointers.</para></listitem>
|
||||
<listitem><para><emphasis>Example:</emphasis>
|
||||
<listitem><para><emphasis>Example:</emphasis>
|
||||
<programlisting>
|
||||
1 int zero = 0;
|
||||
2 vector<int*> v(10000000, &zero);
|
||||
@ -1547,7 +1547,7 @@ foo.cc:7: advice: Insert prefetch instruction.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Fundamentals:</emphasis>Allocation can be tuned
|
||||
to a specific traversal pattern, to result in better data locality.
|
||||
See paper:
|
||||
See paper:
|
||||
<ulink url="http://www.springerlink.com/content/8085744l00x72662/">
|
||||
Custom Memory Allocation for Free</ulink>.
|
||||
</para></listitem>
|
||||
@ -1557,7 +1557,7 @@ foo.cc:7: advice: Insert prefetch instruction.
|
||||
High scatter score N for container built at site S.
|
||||
Consider changing allocation sequence or choosing a structure conscious
|
||||
allocator.</para></listitem>
|
||||
<listitem><para><emphasis>To instrument:</emphasis> Methods of all
|
||||
<listitem><para><emphasis>To instrument:</emphasis> Methods of all
|
||||
containers using linked structures.</para></listitem>
|
||||
<listitem><para><emphasis>Analysis:</emphasis>
|
||||
First, get cache line size and page size from system.
|
||||
@ -1639,7 +1639,7 @@ the allocation sequence or switching to a structure conscious allocator.
|
||||
container member accesses. Issue advice for elements referenced by
|
||||
multiple threads.
|
||||
See paper: <ulink url="http://portal.acm.org/citation.cfm?id=207110.207148">
|
||||
The LRPD test: speculative run-time parallelization of loops with
|
||||
The LRPD test: speculative run-time parallelization of loops with
|
||||
privatization and reduction parallelization</ulink>.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Cost model:</emphasis>
|
||||
@ -1660,7 +1660,7 @@ the allocation sequence or switching to a structure conscious allocator.
|
||||
<code>_GLIBCXX_PROFILE_FALSE_SHARING</code>.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Goal:</emphasis> Detect elements in the
|
||||
same container which share a cache line, are written by at least one
|
||||
same container which share a cache line, are written by at least one
|
||||
thread, and accessed by different threads.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Fundamentals:</emphasis> Under these assumptions,
|
||||
@ -1676,16 +1676,16 @@ the allocation sequence or switching to a structure conscious allocator.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Analysis:</emphasis>
|
||||
First, get the cache line size.
|
||||
For each shared container, record all the associated iterator dereferences
|
||||
For each shared container, record all the associated iterator dereferences
|
||||
and member access methods with the thread id. Compare the address lists
|
||||
across threads to detect references in two different threads to the same
|
||||
cache line. Issue a warning only if the ratio to total references is
|
||||
significant. Do the same for iterator dereference values if they are
|
||||
across threads to detect references in two different threads to the same
|
||||
cache line. Issue a warning only if the ratio to total references is
|
||||
significant. Do the same for iterator dereference values if they are
|
||||
pointers.</para></listitem>
|
||||
<listitem><para><emphasis>Cost model:</emphasis>
|
||||
Number of accesses to same cache line from different threads.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Example:</emphasis>
|
||||
<listitem><para><emphasis>Example:</emphasis>
|
||||
<programlisting>
|
||||
1 vector<int> v(2, 0);
|
||||
2 #pragma omp parallel for shared(v, SIZE) schedule(static, 1)
|
||||
@ -1694,7 +1694,7 @@ the allocation sequence or switching to a structure conscious allocator.
|
||||
5 }
|
||||
|
||||
OMP_NUM_THREADS=2 ./a.out
|
||||
foo.cc:1: advice: Change container structure or padding to avoid false
|
||||
foo.cc:1: advice: Change container structure or padding to avoid false
|
||||
sharing in multithreaded access at foo.cc:4. Detected N shared cache lines.
|
||||
</programlisting>
|
||||
</para></listitem>
|
||||
@ -1704,7 +1704,7 @@ sharing in multithreaded access at foo.cc:4. Detected N shared cache lines.
|
||||
</sect2>
|
||||
|
||||
|
||||
<sect2 id="manual.ext.profile_mode.analysis.statistics"
|
||||
<sect2 id="manual.ext.profile_mode.analysis.statistics"
|
||||
xreflabel="Statistics">
|
||||
<title>Statistics</title>
|
||||
|
||||
@ -1757,10 +1757,10 @@ sharing in multithreaded access at foo.cc:4. Detected N shared cache lines.
|
||||
<publisher>
|
||||
<publishername>
|
||||
Proceedings of the 2009 International Symposium on Code Generation
|
||||
and Optimization
|
||||
and Optimization
|
||||
</publishername>
|
||||
</publisher>
|
||||
</biblioentry>
|
||||
</biblioentry>
|
||||
</bibliography>
|
||||
|
||||
|
||||
|
@ -1,7 +1,7 @@
|
||||
<sect1 id="manual.util.memory.shared_ptr" xreflabel="shared_ptr">
|
||||
<section id="std.util.memory.shared_ptr" xreflabel="shared_ptr">
|
||||
<?dbhtml filename="shared_ptr.html"?>
|
||||
|
||||
<sect1info>
|
||||
|
||||
<sectioninfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
ISO C++
|
||||
@ -10,7 +10,7 @@
|
||||
shared_ptr
|
||||
</keyword>
|
||||
</keywordset>
|
||||
</sect1info>
|
||||
</sectioninfo>
|
||||
|
||||
<title>shared_ptr</title>
|
||||
|
||||
@ -19,7 +19,7 @@ The shared_ptr class template stores a pointer, usually obtained via new,
|
||||
and implements shared ownership semantics.
|
||||
</para>
|
||||
|
||||
<sect2 id="shared_ptr.req">
|
||||
<section id="shared_ptr.req">
|
||||
<title>Requirements</title>
|
||||
|
||||
<para>
|
||||
@ -39,11 +39,11 @@ and implements shared ownership semantics.
|
||||
apply.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<para>
|
||||
</para>
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<sect2 id="shared_ptr.design_issues">
|
||||
<section id="shared_ptr.design_issues">
|
||||
<title>Design Issues</title>
|
||||
|
||||
|
||||
@ -65,12 +65,12 @@ where the correct dynamic type is known. This is an application of the
|
||||
technique known as type erasure.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<sect2 id="shared_ptr.impl">
|
||||
<section id="shared_ptr.impl">
|
||||
<title>Implementation</title>
|
||||
|
||||
<sect3>
|
||||
<section>
|
||||
<title>Class Hierarchy</title>
|
||||
|
||||
<para>
|
||||
@ -156,9 +156,9 @@ that simplifies the implementation slightly.
|
||||
|
||||
</variablelist>
|
||||
|
||||
</sect3>
|
||||
</section>
|
||||
|
||||
<sect3>
|
||||
<section>
|
||||
<title>Thread Safety</title>
|
||||
|
||||
<para>
|
||||
@ -179,7 +179,7 @@ deprecated in C++0x mode.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The
|
||||
The
|
||||
<ulink url="http://boost.org/libs/smart_ptr/shared_ptr.htm#ThreadSafety">Thread
|
||||
Safety</ulink> section of the Boost shared_ptr documentation says "shared_ptr
|
||||
objects offer the same level of thread safety as built-in types."
|
||||
@ -232,12 +232,12 @@ makes things much simpler: we have an atomic CAS or we don't, see Lock
|
||||
Policy below for details.
|
||||
</para>
|
||||
|
||||
</sect3>
|
||||
</section>
|
||||
|
||||
<sect3>
|
||||
<section>
|
||||
<title>Selecting Lock Policy</title>
|
||||
|
||||
<para>
|
||||
<para>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -300,9 +300,9 @@ used when libstdc++ is built without <literal>--enable-threads</literal>.
|
||||
is multi-threaded. If only one thread of execution exists in
|
||||
the program then less expensive non-atomic operations are used.
|
||||
</para>
|
||||
</sect3>
|
||||
</section>
|
||||
|
||||
<sect3>
|
||||
<section>
|
||||
<title>Dual C++0x and TR1 Implementation</title>
|
||||
|
||||
<para>
|
||||
@ -316,12 +316,12 @@ including <classname>_Sp_counted_base</classname> are shared by both implementat
|
||||
<para>
|
||||
The TR1 implementation is considered relatively stable, so is unlikely to
|
||||
change unless bug fixes require it. If the code that is common to both
|
||||
C++0x and TR1 modes needs to diverge further then it might be necessary to
|
||||
C++0x and TR1 modes needs to diverge further then it might be necessary to
|
||||
duplicate additional classes and only make changes to the C++0x versions.
|
||||
</para>
|
||||
</sect3>
|
||||
</section>
|
||||
|
||||
<sect3>
|
||||
<section>
|
||||
<title>Related functions and classes</title>
|
||||
|
||||
<variablelist>
|
||||
@ -346,7 +346,7 @@ In C++0x mode these constructors and the related tag types are not needed.
|
||||
<para>
|
||||
The clever overload to detect a base class of type
|
||||
<code>enable_shared_from_this</code> comes straight from Boost.
|
||||
There is an extra overload for <code>__enable_shared_from_this</code> to
|
||||
There is an extra overload for <code>__enable_shared_from_this</code> to
|
||||
work smoothly with <code>__shared_ptr<Tp, Lp></code> using any lock
|
||||
policy.
|
||||
</para>
|
||||
@ -382,9 +382,9 @@ be private.
|
||||
|
||||
</variablelist>
|
||||
|
||||
</sect3>
|
||||
</section>
|
||||
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<!--- XXX
|
||||
<listitem>
|
||||
@ -414,20 +414,20 @@ the following types, depending on how the shared_ptr is constructed.
|
||||
</listitem>
|
||||
-->
|
||||
|
||||
<sect2 id="shared_ptr.using">
|
||||
<section id="shared_ptr.using">
|
||||
<title>Use</title>
|
||||
|
||||
<sect3>
|
||||
<section>
|
||||
<title>Examples</title>
|
||||
<para>
|
||||
<para>
|
||||
Examples of use can be found in the testsuite, under
|
||||
<filename class="directory">testsuite/tr1/2_general_utilities/shared_ptr</filename>.
|
||||
</para>
|
||||
</sect3>
|
||||
</section>
|
||||
|
||||
<sect3>
|
||||
<section>
|
||||
<title>Unresolved Issues</title>
|
||||
<para>
|
||||
<para>
|
||||
The resolution to C++ Standard Library issue <ulink url="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</ulink>,
|
||||
"shared_ptr interface changes for consistency with N1856" will
|
||||
need to be implemented after it is accepted into the working
|
||||
@ -481,21 +481,21 @@ the following types, depending on how the shared_ptr is constructed.
|
||||
*_pointer_cast functions. Constructor could be private in TR1
|
||||
mode, with the cast functions as friends.
|
||||
</para>
|
||||
</sect3>
|
||||
</section>
|
||||
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<sect2 id="shared_ptr.ack">
|
||||
<section id="shared_ptr.ack">
|
||||
<title>Acknowledgments</title>
|
||||
|
||||
<para>
|
||||
<para>
|
||||
The original authors of the Boost shared_ptr, which is really nice
|
||||
code to work with, Peter Dimov in particular for his help and
|
||||
invaluable advice on thread safety. Phillip Jordan and Paolo
|
||||
Carlini for the lock policy implementation.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
</section>
|
||||
|
||||
<bibliography id="shared_ptr.biblio">
|
||||
<title>Bibliography</title>
|
||||
@ -511,7 +511,7 @@ the following types, depending on how the shared_ptr is constructed.
|
||||
<subtitle>
|
||||
N2351
|
||||
</subtitle>
|
||||
</biblioentry>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry>
|
||||
<biblioid class="uri">
|
||||
@ -524,7 +524,7 @@ the following types, depending on how the shared_ptr is constructed.
|
||||
<subtitle>
|
||||
N2456
|
||||
</subtitle>
|
||||
</biblioentry>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry>
|
||||
<biblioid class="uri">
|
||||
@ -537,7 +537,7 @@ the following types, depending on how the shared_ptr is constructed.
|
||||
<subtitle>
|
||||
N2461
|
||||
</subtitle>
|
||||
</biblioentry>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry>
|
||||
<biblioid class="uri">
|
||||
@ -550,8 +550,8 @@ the following types, depending on how the shared_ptr is constructed.
|
||||
<subtitle>
|
||||
N2461
|
||||
</subtitle>
|
||||
</biblioentry>
|
||||
</biblioentry>
|
||||
|
||||
</bibliography>
|
||||
|
||||
</sect1>
|
||||
</section>
|
||||
|
@ -1,6 +1,6 @@
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
[ ]>
|
||||
|
||||
<book id="manual-index">
|
||||
@ -24,92 +24,106 @@
|
||||
</bookinfo>
|
||||
|
||||
<!-- Part 01 : Intro -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="intro.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Part 02 : Support -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<!-- Part 02 : Standard Contents -->
|
||||
<part id="manual.std" xreflabel="Standard Contents">
|
||||
<title>
|
||||
Standard Contents
|
||||
</title>
|
||||
|
||||
<!-- Chapter 01 : Support -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="support.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Part 03 : Diagnostics -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
|
||||
<!-- Chapter 02 : Diagnostics -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="diagnostics.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Part 04 : Utilities -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<!-- Chapter 03 : Utilities -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="utilities.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Part 05 : Strings -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<!-- Chapter 04 : Strings -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="strings.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Part 06 : Localization -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<!-- Chapter 05 : Localization -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="localization.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Part 07 : Containers -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<!-- Chapter 06 : Containers -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="containers.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Part 08 : Iterators -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<!-- Chapter 07 : Iterators -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="iterators.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Part 09 : Algorithms -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<!-- Chapter 08 : Algorithms -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="algorithms.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Part 10 : Numerics -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<!-- Chapter 09 : Numerics -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="numerics.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Part 11 : Input Output -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<!-- Chapter 10 : Input Output -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="io.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Part 12 : Extensions -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
</part>
|
||||
|
||||
<!-- Part 03 : Extensions -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="extensions.xml">
|
||||
</xi:include>
|
||||
|
||||
|
||||
<!-- Part 04 : Appendices -->
|
||||
<part id="appendix" xreflabel="Appendices">
|
||||
<title>
|
||||
Appendices
|
||||
</title>
|
||||
|
||||
<!-- Appendix A -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="appendix_contributing.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Appendix B -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="appendix_porting.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Appendix C -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="appendix_free.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Appendix D -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="../gnu/gpl-3.0.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Appendix E -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="../gnu/fdl-1.2.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Index -->
|
||||
<index/>
|
||||
</part>
|
||||
|
||||
</book>
|
||||
|
@ -1,6 +1,6 @@
|
||||
<sect2 id="status.iso.1998" xreflabel="ISO C++ 1998">
|
||||
<?dbhtml filename="status_iso_cxx1998.html"?>
|
||||
|
||||
|
||||
<sect2info>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
@ -27,13 +27,13 @@ particular release.
|
||||
</para>
|
||||
|
||||
<!-- Status is Yes or No, Broken/Partial-->
|
||||
<!--
|
||||
<!--
|
||||
Yes
|
||||
|
||||
No
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
Broken/Partial
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
No
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
Broken/Partial
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
-->
|
||||
<table frame='all'>
|
||||
<title>C++ 1998/2003 Implementation Status</title>
|
||||
@ -1047,8 +1047,8 @@ particular release.
|
||||
<listitem>
|
||||
<para>
|
||||
Behavior, for a well-formed program construct and correct data, that
|
||||
depends on the implementation <emphasis>and that each implementation
|
||||
shall document</emphasis>.
|
||||
depends on the implementation <emphasis>and that each implementation
|
||||
shall document</emphasis>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -1074,11 +1074,11 @@ particular release.
|
||||
discussed in the various sections on multithreading (see above).
|
||||
</para>
|
||||
<!-- [17.4.4.8]/3 says any function that doesn't have an exception-spec
|
||||
can throw whatever we want; see also its footnote. Let's list those
|
||||
in the sections where the function itself occurs.
|
||||
can throw whatever we want; see also its footnote. Let's list those
|
||||
in the sections where the function itself occurs.
|
||||
-->
|
||||
<para><emphasis>[18.1]/4</emphasis> The type of <code>NULL</code> is described
|
||||
<link linkend="manual.support.types.null">here</link>.
|
||||
<link linkend="std.support.types.null">here</link>.
|
||||
</para>
|
||||
<para><emphasis>[18.3]/8</emphasis> Even though it's listed in the library
|
||||
sections, libstdc++ has zero control over what the cleanup code hands
|
||||
@ -1125,12 +1125,12 @@ particular release.
|
||||
</para>
|
||||
<para><emphasis>[21.1.3.1]/5</emphasis> I don't really know about
|
||||
the mbstate_t stuff... see
|
||||
the <link linkend="manual.localization.facet.codecvt">chapter 22
|
||||
the <link linkend="std.localization.facet.codecvt">chapter 22
|
||||
notes</link> for what does exist.
|
||||
</para>
|
||||
<para><emphasis>[22.*]</emphasis> Anything and everything we have on locale
|
||||
implementation will be described
|
||||
<link linkend="manual.localization.locales.locale">over here</link>.
|
||||
<link linkend="std.localization.locales.locale">over here</link>.
|
||||
</para>
|
||||
<para><emphasis>[26.2.8]/9</emphasis> I have no idea what
|
||||
<code>complex<T></code>'s pow(0,0) returns.
|
||||
@ -1152,7 +1152,7 @@ particular release.
|
||||
<para><emphasis>[27.7.1.3]/16</emphasis>,
|
||||
<emphasis>[27.8.1.4]/10</emphasis>
|
||||
The effects of <code>pubsetbuf/setbuf</code> are described
|
||||
<link linkend="manual.io">in this chapter</link>.
|
||||
<link linkend="std.io">in this chapter</link>.
|
||||
</para>
|
||||
<para><emphasis>[27.8.1.4]/16</emphasis> Calling <code>fstream::sync</code> when
|
||||
a get area exists will... whatever <code>fflush()</code> does, I think.
|
||||
|
@ -1,6 +1,6 @@
|
||||
<sect2 id="status.iso.200x" xreflabel="Status C++ 200x">
|
||||
<?dbhtml filename="status_iso_cxx200x.html"?>
|
||||
|
||||
|
||||
<sect2info>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
@ -15,7 +15,7 @@
|
||||
<title>C++ 200x</title>
|
||||
|
||||
<para>
|
||||
This table is based on the table of contents of ISO/IEC
|
||||
This table is based on the table of contents of ISO/IEC
|
||||
Doc No: N3000=09-0190 Date: 2009-11-09
|
||||
Working Draft, Standard for Programming Language C++
|
||||
</para>
|
||||
@ -36,13 +36,13 @@ particular release.
|
||||
</para>
|
||||
|
||||
<!-- Status is Yes or No, Broken/Partial-->
|
||||
<!--
|
||||
<!--
|
||||
Yes
|
||||
|
||||
No
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
Broken/Partial
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
No
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
Broken/Partial
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
-->
|
||||
<table frame='all'>
|
||||
<title>C++ 200x Implementation Status</title>
|
||||
@ -77,7 +77,7 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>18.2</entry>
|
||||
<entry>Types</entry>
|
||||
<entry>Partial</entry>
|
||||
@ -103,21 +103,21 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>18.3.1.2</entry>
|
||||
<entry><code>numeric_limits</code> members</entry>
|
||||
<entry>Partial</entry>
|
||||
<entry>Missing constexpr</entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>18.3.1.3</entry>
|
||||
<entry><code>float_round_style</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>18.3.1.4</entry>
|
||||
<entry><code>float_denorm_style</code></entry>
|
||||
<entry>N</entry>
|
||||
@ -150,14 +150,14 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>18.4.2</entry>
|
||||
<entry>The header <code><stdint.h></code></entry>
|
||||
<entry>Partial</entry>
|
||||
<entry>May use configure-generated stdint.h via GCC_HEADER_STDINT</entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>18.5</entry>
|
||||
<entry>Start and termination</entry>
|
||||
<entry>Partial</entry>
|
||||
@ -182,7 +182,7 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>18.7.2</entry>
|
||||
<entry>Class type_index</entry>
|
||||
<entry>N</entry>
|
||||
@ -261,7 +261,7 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>18.9.3</entry>
|
||||
<entry>Initializer list concept maps</entry>
|
||||
<entry>N</entry>
|
||||
@ -318,14 +318,14 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>19.5.2</entry>
|
||||
<entry>Class <code>error_code</code></entry>
|
||||
<entry>Partial</entry>
|
||||
<entry>Missing concept ErrorCodeEnum</entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>19.5.3</entry>
|
||||
<entry>Class <code>error_condition</code></entry>
|
||||
<entry>Partial</entry>
|
||||
@ -352,14 +352,14 @@ particular release.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>20.1</entry>
|
||||
<entry>General</entry>
|
||||
<entry>Partial</entry>
|
||||
<entry>Missing all concepts</entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>20.2</entry>
|
||||
<entry>Concepts</entry>
|
||||
<entry>N</entry>
|
||||
@ -396,7 +396,7 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>20.3.5</entry>
|
||||
<entry>Range concept maps for <code>pair</code></entry>
|
||||
<entry>N</entry>
|
||||
@ -451,7 +451,7 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>20.5.2</entry>
|
||||
<entry>Class template <code>tuple</code></entry>
|
||||
<entry>Partial</entry>
|
||||
@ -470,7 +470,7 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>20.6.2</entry>
|
||||
<entry>Header <code><type_traits></code> synopsis</entry>
|
||||
<entry></entry>
|
||||
@ -501,7 +501,7 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>20.6.4.3</entry>
|
||||
<entry>Type properties</entry>
|
||||
<entry>Partial</entry>
|
||||
@ -550,7 +550,7 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>20.6.7</entry>
|
||||
<entry>Other transformations</entry>
|
||||
<entry>Partial</entry>
|
||||
@ -587,7 +587,7 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>20.7.6</entry>
|
||||
<entry>Identity operation</entry>
|
||||
<entry>N</entry>
|
||||
@ -672,7 +672,7 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>20.7.18</entry>
|
||||
<entry>Class template <code>reference_closure</code></entry>
|
||||
<entry>N</entry>
|
||||
@ -685,7 +685,7 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>20.8.01</entry>
|
||||
<entry>Allocator argument tag</entry>
|
||||
<entry>N</entry>
|
||||
@ -704,42 +704,42 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>20.8.02.2</entry>
|
||||
<entry>Allocator concept</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>20.8.02.3</entry>
|
||||
<entry>Support for legacy allocators</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>20.8.02.4</entry>
|
||||
<entry>Allocator and Legacy Allocator members</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>20.8.03</entry>
|
||||
<entry>Allocator-related element concepts</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>20.8.04</entry>
|
||||
<entry>Allocator propagation traits</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>20.8.05</entry>
|
||||
<entry>Allocator propagation map</entry>
|
||||
<entry>N</entry>
|
||||
@ -758,35 +758,35 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>20.8.07.1</entry>
|
||||
<entry><code>scoped_allocator_adaptor_base</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>20.8.07.2</entry>
|
||||
<entry><code>scoped_allocator_adaptor constructors</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>20.8.07.3</entry>
|
||||
<entry><code>scoped_allocator_adaptor2</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>20.8.07.3</entry>
|
||||
<entry>scoped_allocator_adaptor members</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>20.8.07.4</entry>
|
||||
<entry><code>scoped_allocator_adaptor globals</code></entry>
|
||||
<entry>N</entry>
|
||||
@ -805,7 +805,7 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>20.8.10</entry>
|
||||
<entry><code>construct_element</code></entry>
|
||||
<entry>N</entry>
|
||||
@ -818,7 +818,7 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>20.8.11.1</entry>
|
||||
<entry><code>addressof</code></entry>
|
||||
<entry>N</entry>
|
||||
@ -868,7 +868,7 @@ particular release.
|
||||
<para>
|
||||
Uses code from
|
||||
<ulink url="http://www.boost.org/libs/smart_ptr/shared_ptr.htm">boost::shared_ptr</ulink>.
|
||||
</para>
|
||||
</para>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
@ -890,21 +890,21 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>20.8.13.6</entry>
|
||||
<entry><code>shared_ptr</code> atomic access</entry>
|
||||
<entry>Partial</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>20.8.13.7</entry>
|
||||
<entry>Pointer safety</entry>
|
||||
<entry>Partial</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>20.8.14</entry>
|
||||
<entry>Align</entry>
|
||||
<entry>N</entry>
|
||||
@ -1143,14 +1143,14 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>22.3.3.2.2</entry>
|
||||
<entry>String</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>22.3.3.2.3</entry>
|
||||
<entry>Buffer</entry>
|
||||
<entry>N</entry>
|
||||
@ -1271,7 +1271,7 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>22.5</entry>
|
||||
<entry>Standard code conversion facets</entry>
|
||||
<entry>N</entry>
|
||||
@ -1292,7 +1292,7 @@ particular release.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>23.1</entry>
|
||||
<entry>General</entry>
|
||||
<entry>Partial</entry>
|
||||
@ -1305,7 +1305,7 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>23.2.1</entry>
|
||||
<entry>General requirements</entry>
|
||||
<entry>Partial</entry>
|
||||
@ -1452,21 +1452,21 @@ particular release.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>24.1</entry>
|
||||
<entry>General</entry>
|
||||
<entry>Partial</entry>
|
||||
<entry>Missing concepts</entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>24.2</entry>
|
||||
<entry>Iterator concepts</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>24.3</entry>
|
||||
<entry>Header <code><iterator></code> synopsis</entry>
|
||||
<entry>Partial</entry>
|
||||
@ -1565,7 +1565,7 @@ particular release.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>25.1</entry>
|
||||
<entry>General</entry>
|
||||
<entry>Partial</entry>
|
||||
@ -1640,14 +1640,14 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>26.5.1</entry>
|
||||
<entry>Header <code><random></code> synopsis</entry>
|
||||
<entry>Partial</entry>
|
||||
<entry>Missing concepts</entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>26.5.2</entry>
|
||||
<entry>Concepts and related requirements</entry>
|
||||
<entry>N</entry>
|
||||
@ -2022,7 +2022,7 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>27.2.3</entry>
|
||||
<entry>Thread safety</entry>
|
||||
<entry>Partial</entry>
|
||||
@ -2091,35 +2091,35 @@ particular release.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>28.01</entry>
|
||||
<entry>General</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>28.02</entry>
|
||||
<entry>Definitions</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>28.03</entry>
|
||||
<entry>Requirements</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>28.04</entry>
|
||||
<entry>Regular expressions summary</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>28.05</entry>
|
||||
<entry>Header <code><regex></code> synopsis</entry>
|
||||
<entry>N</entry>
|
||||
@ -2138,49 +2138,49 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>28.08</entry>
|
||||
<entry>Class template <code>regex_traits</code></entry>
|
||||
<entry>Partial</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>28.09</entry>
|
||||
<entry>Class template <code>basic_regex</code></entry>
|
||||
<entry>Partial</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>28.10</entry>
|
||||
<entry>Class template <code>sub_match</code></entry>
|
||||
<entry>Partial</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>28.11</entry>
|
||||
<entry>Class template <code>match_results</code></entry>
|
||||
<entry>Partial</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>28.12</entry>
|
||||
<entry>Regular expression algorithms</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>28.13</entry>
|
||||
<entry>Regular expression Iterators</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>28.14</entry>
|
||||
<entry>Modified ECMAScript regular expression grammar</entry>
|
||||
<entry>N</entry>
|
||||
@ -2207,7 +2207,7 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>29.3</entry>
|
||||
<entry>Order and consistency</entry>
|
||||
<entry>N</entry>
|
||||
@ -2256,7 +2256,7 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>29.8</entry>
|
||||
<entry>Fences</entry>
|
||||
<entry>N</entry>
|
||||
@ -2289,7 +2289,7 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>30.3.1</entry>
|
||||
<entry>Class <code>thread</code></entry>
|
||||
<entry>Partial</entry>
|
||||
@ -2398,7 +2398,7 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
<entry>30.5.2</entry>
|
||||
<entry>Class <code>condition_variable_any</code></entry>
|
||||
<entry>Partial</entry>
|
||||
@ -2411,56 +2411,56 @@ particular release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>30.6.1</entry>
|
||||
<entry>Overview</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>30.6.2</entry>
|
||||
<entry>Error handling</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>30.6.3</entry>
|
||||
<entry>Class <code>future_error</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>30.6.4</entry>
|
||||
<entry>Class template <code>unique_future</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>30.6.5</entry>
|
||||
<entry>Class template <code>shared_future</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>30.6.6</entry>
|
||||
<entry>Class template <code>promise</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>30.6.7</entry>
|
||||
<entry>Allocator templates</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>30.6.8</entry>
|
||||
<entry>Class template <code>packaged_task</code></entry>
|
||||
<entry>N</entry>
|
||||
|
@ -1,6 +1,6 @@
|
||||
<sect2 id="status.iso.tr1" xreflabel="Status C++ TR1">
|
||||
<?dbhtml filename="status_iso_cxxtr1.html"?>
|
||||
|
||||
|
||||
<sect2info>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
@ -32,13 +32,13 @@ release.
|
||||
</para>
|
||||
|
||||
<!-- Status is Yes or No, Broken/Partial-->
|
||||
<!--
|
||||
<!--
|
||||
Yes
|
||||
|
||||
No
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
Broken/Partial
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
No
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
Broken/Partial
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
-->
|
||||
<table frame='all'>
|
||||
<title>C++ TR1 Implementation Status</title>
|
||||
@ -135,7 +135,7 @@ release.
|
||||
<para>
|
||||
Uses code from
|
||||
<ulink url="http://www.boost.org/libs/smart_ptr/shared_ptr.htm">boost::shared_ptr</ulink>.
|
||||
</para>
|
||||
</para>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
@ -1030,322 +1030,322 @@ release.
|
||||
<entry namest="c2" nameend="c4" align="left"><emphasis>Regular Expressions</emphasis></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.1</entry>
|
||||
<entry>Definitions</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.2</entry>
|
||||
<entry>Requirements</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.3</entry>
|
||||
<entry>Regular expressions summary</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.4</entry>
|
||||
<entry>Header <code><regex></code> synopsis</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.5</entry>
|
||||
<entry>Namespace <code>tr1::regex_constants</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.5.1</entry>
|
||||
<entry>Bitmask Type <code>syntax_option_type</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.5.2</entry>
|
||||
<entry>Bitmask Type <code>regex_constants::match_flag_type</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.5.3</entry>
|
||||
<entry>Implementation defined <code>error_type</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.6</entry>
|
||||
<entry>Class <code>regex_error</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.7</entry>
|
||||
<entry>Class template <code>regex_traits</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.8</entry>
|
||||
<entry>Class template <code>basic_regex</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.8.1</entry>
|
||||
<entry><code>basic_regex</code> constants</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.8.2</entry>
|
||||
<entry><code>basic_regex</code> constructors</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.8.3</entry>
|
||||
<entry><code>basic_regex</code> assign</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.8.4</entry>
|
||||
<entry><code>basic_regex</code> constant operations</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.8.5</entry>
|
||||
<entry><code>basic_regex</code> locale</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.8.6</entry>
|
||||
<entry><code>basic_regex</code> swap</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.8.7</entry>
|
||||
<entry><code>basic_regex</code> non-member functions</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.8.7.1</entry>
|
||||
<entry><code>basic_regex</code> non-member swap</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.9</entry>
|
||||
<entry>Class template <code>sub_match</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.9.1</entry>
|
||||
<entry><code>sub_match</code> members</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.9.2</entry>
|
||||
<entry><code>sub_match</code> non-member operators</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.10</entry>
|
||||
<entry>Class template <code>match_results</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.10.1</entry>
|
||||
<entry><code>match_results</code> constructors</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.10.2</entry>
|
||||
<entry><code>match_results</code> size</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.10.3</entry>
|
||||
<entry><code>match_results</code> element access</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.10.4</entry>
|
||||
<entry><code>match_results</code> formatting</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.10.5</entry>
|
||||
<entry><code>match_results</code> allocator</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.10.6</entry>
|
||||
<entry><code>match_results</code> swap</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.11</entry>
|
||||
<entry>Regular expression algorithms</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.11.1</entry>
|
||||
<entry>exceptions</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.11.2</entry>
|
||||
<entry><code>regex_match</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.11.3</entry>
|
||||
<entry><code>regex_search</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.11.4</entry>
|
||||
<entry><code>regex_replace</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.12</entry>
|
||||
<entry>Regular expression Iterators</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.12.1</entry>
|
||||
<entry>Class template <code>regex_iterator</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.12.1.1</entry>
|
||||
<entry><code>regex_iterator</code> constructors</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.12.1.2</entry>
|
||||
<entry><code>regex_iterator</code> comparisons</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.12.1.3</entry>
|
||||
<entry><code>regex_iterator</code> dereference</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.12.1.4</entry>
|
||||
<entry><code>regex_iterator</code> increment</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.12.2</entry>
|
||||
<entry>Class template <code>regex_token_iterator</code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.12.2.1</entry>
|
||||
<entry><code>regex_token_iterator</code> constructors</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.12.2.2</entry>
|
||||
<entry><code>regex_token_iterator</code> comparisons</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.12.2.3</entry>
|
||||
<entry><code>regex_token_iterator</code> dereference</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.12.2.4</entry>
|
||||
<entry><code>regex_token_iterator</code> increment</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>7.13</entry>
|
||||
<entry>Modified ECMAScript regular expression grammar</entry>
|
||||
<entry>N</entry>
|
||||
@ -1416,14 +1416,14 @@ release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>8.2</entry>
|
||||
<entry>Header <code><ccomplex></code></entry>
|
||||
<entry>N</entry>
|
||||
<entry>DR 551</entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>8.3</entry>
|
||||
<entry>Header <code><complex.h></code></entry>
|
||||
<entry>N</entry>
|
||||
@ -1490,21 +1490,21 @@ release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>8.10</entry>
|
||||
<entry>Additions to header <code><ios></code></entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>8.10.1</entry>
|
||||
<entry>Synopsis</entry>
|
||||
<entry>N</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>8.10.2</entry>
|
||||
<entry>Function <code>hexfloat</code></entry>
|
||||
<entry>N</entry>
|
||||
@ -1547,7 +1547,7 @@ release.
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
<entry>8.15</entry>
|
||||
<entry>Additions to header <code><locale></code></entry>
|
||||
<entry>N</entry>
|
||||
|
@ -1,6 +1,6 @@
|
||||
<sect2 id="status.iso.tr24733" xreflabel="Status C++ TR24733">
|
||||
<?dbhtml filename="status_iso_cxxtr24733.html"?>
|
||||
|
||||
|
||||
<sect2info>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
@ -24,12 +24,12 @@ particular release.
|
||||
</para>
|
||||
|
||||
<!-- Status is Yes or No, Broken/Partial-->
|
||||
<!--
|
||||
<!--
|
||||
Yes
|
||||
|
||||
No
|
||||
No
|
||||
<?dbhtml bgcolor="#C8B0B0" ?>
|
||||
Broken/Partial
|
||||
Broken/Partial
|
||||
<?dbhtml bgcolor="#B0B0B0" ?>
|
||||
-->
|
||||
<table frame='all'>
|
||||
|
@ -1,12 +1,12 @@
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
[ ]>
|
||||
|
||||
<part id="manual.strings" xreflabel="Strings">
|
||||
<chapter id="std.strings" xreflabel="Strings">
|
||||
<?dbhtml filename="strings.html"?>
|
||||
|
||||
<partinfo>
|
||||
|
||||
<chapterinfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
ISO C++
|
||||
@ -15,20 +15,20 @@
|
||||
library
|
||||
</keyword>
|
||||
</keywordset>
|
||||
</partinfo>
|
||||
</chapterinfo>
|
||||
|
||||
<title>
|
||||
Strings
|
||||
<indexterm><primary>Strings</primary></indexterm>
|
||||
</title>
|
||||
|
||||
<!-- Chapter 01 : Character Traits -->
|
||||
<!-- Sect1 01 : Character Traits -->
|
||||
|
||||
<!-- Chapter 02 : String Classes -->
|
||||
<chapter id="manual.strings.string" xreflabel="string">
|
||||
<!-- Sect1 02 : String Classes -->
|
||||
<sect1 id="std.strings.string" xreflabel="string">
|
||||
<title>String Classes</title>
|
||||
|
||||
<sect1 id="strings.string.simple" xreflabel="Simple Transformations">
|
||||
<sect2 id="strings.string.simple" xreflabel="Simple Transformations">
|
||||
<title>Simple Transformations</title>
|
||||
<para>
|
||||
Here are Standard, simple, and portable ways to perform common
|
||||
@ -71,7 +71,7 @@
|
||||
std::string capital_s;
|
||||
capital_s.resize(s.size());
|
||||
std::transform (s.begin(), s.end(), capital_s.begin(), ToUpper());
|
||||
}
|
||||
}
|
||||
</programlisting>
|
||||
<para>
|
||||
<emphasis>Note</emphasis> that these calls all
|
||||
@ -91,7 +91,7 @@
|
||||
<code><locale></code>) so the template-arguments for
|
||||
<code>transform<></code> cannot be deduced, as explained in
|
||||
<ulink url="http://gcc.gnu.org/ml/libstdc++/2002-11/msg00180.html">this
|
||||
message</ulink>.
|
||||
message</ulink>.
|
||||
<!-- section 14.8.2.4 clause 16 in ISO 14882:1998 -->
|
||||
At minimum, you can write short wrappers like
|
||||
</para>
|
||||
@ -115,15 +115,15 @@
|
||||
str.erase(0,notwhite);
|
||||
|
||||
// trim trailing whitespace
|
||||
notwhite = str.find_last_not_of(" \t\n");
|
||||
notwhite = str.find_last_not_of(" \t\n");
|
||||
str.erase(notwhite+1); </programlisting>
|
||||
<para>Obviously, the calls to <code>find</code> could be inserted directly
|
||||
into the calls to <code>erase</code>, in case your compiler does not
|
||||
optimize named temporaries out of existence.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
<sect1 id="strings.string.case" xreflabel="Case Sensitivity">
|
||||
|
||||
</sect2>
|
||||
<sect2 id="strings.string.case" xreflabel="Case Sensitivity">
|
||||
<title>Case Sensitivity</title>
|
||||
<para>
|
||||
</para>
|
||||
@ -174,8 +174,8 @@
|
||||
very good information.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
<sect1 id="strings.string.character_types" xreflabel="Arbitrary Characters">
|
||||
</sect2>
|
||||
<sect2 id="strings.string.character_types" xreflabel="Arbitrary Characters">
|
||||
<title>Arbitrary Character Types</title>
|
||||
<para>
|
||||
</para>
|
||||
@ -193,8 +193,8 @@
|
||||
</para>
|
||||
<programlisting>
|
||||
template <typename CharT,
|
||||
typename Traits = char_traits<CharT>,
|
||||
typename Alloc = allocator<CharT> >
|
||||
typename Traits = char_traits<CharT>,
|
||||
typename Alloc = allocator<CharT> >
|
||||
class basic_string { .... };</programlisting>
|
||||
<para>Now, <code>allocator<CharT></code> will probably Do The Right
|
||||
Thing by default, unless you need to implement your own allocator
|
||||
@ -206,11 +206,11 @@
|
||||
</para>
|
||||
<programlisting>
|
||||
template <typename CharT>
|
||||
struct char_traits
|
||||
{
|
||||
static void foo (type1 x, type2 y);
|
||||
...
|
||||
};</programlisting>
|
||||
struct char_traits
|
||||
{
|
||||
static void foo (type1 x, type2 y);
|
||||
...
|
||||
};</programlisting>
|
||||
<para>and functions such as char_traits<CharT>::foo() are not
|
||||
actually defined anywhere for the general case. The C++ standard
|
||||
permits this, because writing such a definition to fit all possible
|
||||
@ -245,9 +245,9 @@
|
||||
(See how tricky this is?)
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
</sect2>
|
||||
|
||||
<sect1 id="strings.string.token" xreflabel="Tokenizing">
|
||||
<sect2 id="strings.string.token" xreflabel="Tokenizing">
|
||||
<title>Tokenizing</title>
|
||||
<para>
|
||||
</para>
|
||||
@ -275,32 +275,32 @@
|
||||
template <typename Container>
|
||||
void
|
||||
stringtok(Container &container, string const &in,
|
||||
const char * const delimiters = " \t\n")
|
||||
const char * const delimiters = " \t\n")
|
||||
{
|
||||
const string::size_type len = in.length();
|
||||
string::size_type i = 0;
|
||||
string::size_type i = 0;
|
||||
|
||||
while (i < len)
|
||||
{
|
||||
// Eat leading whitespace
|
||||
i = in.find_first_not_of(delimiters, i);
|
||||
if (i == string::npos)
|
||||
// Eat leading whitespace
|
||||
i = in.find_first_not_of(delimiters, i);
|
||||
if (i == string::npos)
|
||||
return; // Nothing left but white space
|
||||
|
||||
// Find the end of the token
|
||||
string::size_type j = in.find_first_of(delimiters, i);
|
||||
// Find the end of the token
|
||||
string::size_type j = in.find_first_of(delimiters, i);
|
||||
|
||||
// Push token
|
||||
if (j == string::npos)
|
||||
// Push token
|
||||
if (j == string::npos)
|
||||
{
|
||||
container.push_back(in.substr(i));
|
||||
return;
|
||||
}
|
||||
}
|
||||
else
|
||||
container.push_back(in.substr(i, j-i));
|
||||
|
||||
// Set up for next loop
|
||||
i = j + 1;
|
||||
// Set up for next loop
|
||||
i = j + 1;
|
||||
}
|
||||
}
|
||||
</programlisting>
|
||||
@ -317,7 +317,7 @@ stringtok(Container &container, string const &in,
|
||||
std::list<string> ls;
|
||||
stringtok (ls, " this \t is\t\n a test ");
|
||||
for (std::list<string>const_iterator i = ls.begin();
|
||||
i != ls.end(); ++i)
|
||||
i != ls.end(); ++i)
|
||||
{
|
||||
std::cerr << ':' << (*i) << ":\n";
|
||||
} </programlisting>
|
||||
@ -345,8 +345,8 @@ stringtok(Container &container, string const &in,
|
||||
</para>
|
||||
|
||||
|
||||
</sect1>
|
||||
<sect1 id="strings.string.shrink" xreflabel="Shrink to Fit">
|
||||
</sect2>
|
||||
<sect2 id="strings.string.shrink" xreflabel="Shrink to Fit">
|
||||
<title>Shrink to Fit</title>
|
||||
<para>
|
||||
</para>
|
||||
@ -366,11 +366,11 @@ stringtok(Container &container, string const &in,
|
||||
entry</link>) but the regular copy constructor cannot be used
|
||||
because libstdc++'s <code>string</code> is Copy-On-Write.
|
||||
</para>
|
||||
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="strings.string.Cstring" xreflabel="CString (MFC)">
|
||||
</sect2>
|
||||
|
||||
<sect2 id="strings.string.Cstring" xreflabel="CString (MFC)">
|
||||
<title>CString (MFC)</title>
|
||||
<para>
|
||||
</para>
|
||||
@ -387,16 +387,16 @@ stringtok(Container &container, string const &in,
|
||||
message</ulink>, Joe Buck points out a few very important things:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem><para>The Standard <code>string</code> supports all the operations
|
||||
that CString does, with three exceptions.
|
||||
</para></listitem>
|
||||
<listitem><para>Two of those exceptions (whitespace trimming and case
|
||||
conversion) are trivial to implement. In fact, we do so
|
||||
on this page.
|
||||
</para></listitem>
|
||||
<listitem><para>The third is <code>CString::Format</code>, which allows formatting
|
||||
in the style of <code>sprintf</code>. This deserves some mention:
|
||||
</para></listitem>
|
||||
<listitem><para>The Standard <code>string</code> supports all the operations
|
||||
that CString does, with three exceptions.
|
||||
</para></listitem>
|
||||
<listitem><para>Two of those exceptions (whitespace trimming and case
|
||||
conversion) are trivial to implement. In fact, we do so
|
||||
on this page.
|
||||
</para></listitem>
|
||||
<listitem><para>The third is <code>CString::Format</code>, which allows formatting
|
||||
in the style of <code>sprintf</code>. This deserves some mention:
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
<para>
|
||||
The old libg++ library had a function called form(), which did much
|
||||
@ -418,11 +418,11 @@ stringtok(Container &container, string const &in,
|
||||
int the_number;
|
||||
|
||||
incoming_stream >> the_word // extract "foo"
|
||||
>> the_number; // extract N
|
||||
>> the_number; // extract N
|
||||
|
||||
ostringstream output_stream;
|
||||
output_stream << "The word was " << the_word
|
||||
<< " and 3*N was " << (3*the_number);
|
||||
<< " and 3*N was " << (3*the_number);
|
||||
|
||||
return output_stream.str();
|
||||
} </programlisting>
|
||||
@ -432,22 +432,22 @@ stringtok(Container &container, string const &in,
|
||||
<programlisting>
|
||||
CString suffers from a common programming error that results in
|
||||
poor performance. Consider the following code:
|
||||
|
||||
|
||||
CString n_copies_of (const CString& foo, unsigned n)
|
||||
{
|
||||
CString tmp;
|
||||
for (unsigned i = 0; i < n; i++)
|
||||
tmp += foo;
|
||||
return tmp;
|
||||
CString tmp;
|
||||
for (unsigned i = 0; i < n; i++)
|
||||
tmp += foo;
|
||||
return tmp;
|
||||
}
|
||||
|
||||
|
||||
This function is O(n^2), not O(n). The reason is that each +=
|
||||
causes a reallocation and copy of the existing string. Microsoft
|
||||
applications are full of this kind of thing (quadratic performance
|
||||
on tasks that can be done in linear time) -- on the other hand,
|
||||
we should be thankful, as it's created such a big market for high-end
|
||||
ix86 hardware. :-)
|
||||
|
||||
|
||||
If you replace CString with string in the above function, the
|
||||
performance is O(n).
|
||||
</programlisting>
|
||||
@ -455,35 +455,35 @@ stringtok(Container &container, string const &in,
|
||||
comparing CString and the Standard string class:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem><para>CString permits access to its internal representation; coders
|
||||
who exploited that may have problems moving to <code>string</code>.
|
||||
</para></listitem>
|
||||
<listitem><para>Microsoft ships the source to CString (in the files
|
||||
MFC\SRC\Str{core,ex}.cpp), so you could fix the allocation
|
||||
bug and rebuild your MFC libraries.
|
||||
<emphasis><emphasis>Note:</emphasis> It looks like the CString shipped
|
||||
with VC++6.0 has fixed this, although it may in fact have been
|
||||
one of the VC++ SPs that did it.</emphasis>
|
||||
</para></listitem>
|
||||
<listitem><para><code>string</code> operations like this have O(n) complexity
|
||||
<emphasis>if the implementors do it correctly</emphasis>. The libstdc++
|
||||
implementors did it correctly. Other vendors might not.
|
||||
</para></listitem>
|
||||
<listitem><para>While parts of the SGI STL are used in libstdc++, their
|
||||
string class is not. The SGI <code>string</code> is essentially
|
||||
<code>vector<char></code> and does not do any reference
|
||||
counting like libstdc++'s does. (It is O(n), though.)
|
||||
So if you're thinking about SGI's string or rope classes,
|
||||
you're now looking at four possibilities: CString, the
|
||||
libstdc++ string, the SGI string, and the SGI rope, and this
|
||||
is all before any allocator or traits customizations! (More
|
||||
choices than you can shake a stick at -- want fries with that?)
|
||||
</para></listitem>
|
||||
<listitem><para>CString permits access to its internal representation; coders
|
||||
who exploited that may have problems moving to <code>string</code>.
|
||||
</para></listitem>
|
||||
<listitem><para>Microsoft ships the source to CString (in the files
|
||||
MFC\SRC\Str{core,ex}.cpp), so you could fix the allocation
|
||||
bug and rebuild your MFC libraries.
|
||||
<emphasis><emphasis>Note:</emphasis> It looks like the CString shipped
|
||||
with VC++6.0 has fixed this, although it may in fact have been
|
||||
one of the VC++ SPs that did it.</emphasis>
|
||||
</para></listitem>
|
||||
<listitem><para><code>string</code> operations like this have O(n) complexity
|
||||
<emphasis>if the implementors do it correctly</emphasis>. The libstdc++
|
||||
implementors did it correctly. Other vendors might not.
|
||||
</para></listitem>
|
||||
<listitem><para>While chapters of the SGI STL are used in libstdc++, their
|
||||
string class is not. The SGI <code>string</code> is essentially
|
||||
<code>vector<char></code> and does not do any reference
|
||||
counting like libstdc++'s does. (It is O(n), though.)
|
||||
So if you're thinking about SGI's string or rope classes,
|
||||
you're now looking at four possibilities: CString, the
|
||||
libstdc++ string, the SGI string, and the SGI rope, and this
|
||||
is all before any allocator or traits customizations! (More
|
||||
choices than you can shake a stick at -- want fries with that?)
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</sect1>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<!-- Sect1 03 : Interacting with C -->
|
||||
|
||||
</chapter>
|
||||
|
||||
<!-- Chapter 03 : Interacting with C -->
|
||||
|
||||
</part>
|
||||
|
@ -1,12 +1,12 @@
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
[ ]>
|
||||
|
||||
<part id="manual.support" xreflabel="Support">
|
||||
<chapter id="std.support" xreflabel="Support">
|
||||
<?dbhtml filename="support.html"?>
|
||||
|
||||
<partinfo>
|
||||
|
||||
<chapterinfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
ISO C++
|
||||
@ -15,15 +15,13 @@
|
||||
library
|
||||
</keyword>
|
||||
</keywordset>
|
||||
</partinfo>
|
||||
</chapterinfo>
|
||||
|
||||
<title>
|
||||
Support
|
||||
<indexterm><primary>Support</primary></indexterm>
|
||||
</title>
|
||||
|
||||
<preface>
|
||||
<title></title>
|
||||
<para>
|
||||
This part deals with the functions called and objects created
|
||||
automatically during the course of a program's existence.
|
||||
@ -35,12 +33,11 @@
|
||||
homepage for help), we can mention a couple of changes in what
|
||||
kind of support a C++ program gets from the Standard Library.
|
||||
</para>
|
||||
</preface>
|
||||
|
||||
<chapter id="manual.support.types" xreflabel="Types">
|
||||
<sect1 id="std.support.types" xreflabel="Types">
|
||||
<?dbhtml filename="fundamental_types.html"?>
|
||||
<title>Types</title>
|
||||
<sect1 id="manual.support.types.fundamental" xreflabel="Fundamental Types">
|
||||
<sect2 id="std.support.types.fundamental" xreflabel="Fundamental Types">
|
||||
<title>Fundamental Types</title>
|
||||
<para>
|
||||
C++ has the following builtin types:
|
||||
@ -100,9 +97,9 @@
|
||||
Specializing parts of the library on these types is prohibited:
|
||||
instead, use a POD.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
<sect1 id="manual.support.types.numeric_limits" xreflabel="Numeric Properties">
|
||||
|
||||
</sect2>
|
||||
<sect2 id="std.support.types.numeric_limits" xreflabel="Numeric Properties">
|
||||
<title>Numeric Properties</title>
|
||||
|
||||
|
||||
@ -117,8 +114,8 @@
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
template<typename T>
|
||||
struct class
|
||||
template<typename T>
|
||||
struct class
|
||||
{
|
||||
static const bool is_specialized;
|
||||
static T max() throw();
|
||||
@ -156,9 +153,9 @@
|
||||
static const float_round_style round_style;
|
||||
};
|
||||
</programlisting>
|
||||
</sect1>
|
||||
</sect2>
|
||||
|
||||
<sect1 id="manual.support.types.null" xreflabel="NULL">
|
||||
<sect2 id="std.support.types.null" xreflabel="NULL">
|
||||
<title>NULL</title>
|
||||
<para>
|
||||
The only change that might affect people is the type of
|
||||
@ -191,15 +188,15 @@
|
||||
<constant>NULL</constant> that will match pointers before it
|
||||
matches integers.
|
||||
</para>
|
||||
<para>See
|
||||
<para>See
|
||||
<ulink url="http://www.awprofessional.com/titles/0-201-31015-5/">the
|
||||
Effective C++ CD example</ulink>
|
||||
</para>
|
||||
</sect1>
|
||||
</sect2>
|
||||
|
||||
</chapter>
|
||||
</sect1>
|
||||
|
||||
<chapter id="manual.support.memory" xreflabel="Dynamic Memory">
|
||||
<sect1 id="std.support.memory" xreflabel="Dynamic Memory">
|
||||
<?dbhtml filename="dynamic_memory.html"?>
|
||||
<title>Dynamic Memory</title>
|
||||
<para>
|
||||
@ -262,8 +259,8 @@
|
||||
{
|
||||
delete[] safety;
|
||||
popup_window ("Dude, you are running low on heap memory. You
|
||||
should, like, close some windows, or something.
|
||||
The next time you run out, we're gonna burn!");
|
||||
should, like, close some windows, or something.
|
||||
The next time you run out, we're gonna burn!");
|
||||
set_new_handler (old_handler);
|
||||
return;
|
||||
}
|
||||
@ -277,14 +274,14 @@
|
||||
</programlisting>
|
||||
<para>
|
||||
<classname>bad_alloc</classname> is derived from the base <classname>exception</classname>
|
||||
class defined in Chapter 19.
|
||||
class defined in Sect1 19.
|
||||
</para>
|
||||
</chapter>
|
||||
</sect1>
|
||||
|
||||
<chapter id="manual.support.termination" xreflabel="Termination">
|
||||
<sect1 id="std.support.termination" xreflabel="Termination">
|
||||
<?dbhtml filename="termination.html"?>
|
||||
<title>Termination</title>
|
||||
<sect1 id="support.termination.handlers" xreflabel="Termination Handlers">
|
||||
<sect2 id="support.termination.handlers" xreflabel="Termination Handlers">
|
||||
<title>Termination Handlers</title>
|
||||
<para>
|
||||
Not many changes here to <filename
|
||||
@ -310,32 +307,32 @@
|
||||
<listitem>
|
||||
<para>
|
||||
Functions registered with <function>atexit()</function> are called in
|
||||
reverse order of registration, once per registration call.
|
||||
(This isn't actually new.)
|
||||
reverse order of registration, once per registration call.
|
||||
(This isn't actually new.)
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
The previous two actions are <quote>interleaved,</quote> that is,
|
||||
given this pseudocode:
|
||||
given this pseudocode:
|
||||
</para>
|
||||
<programlisting>
|
||||
extern "C or C++" void f1 (void);
|
||||
extern "C or C++" void f2 (void);
|
||||
|
||||
|
||||
static Thing obj1;
|
||||
atexit(f1);
|
||||
static Thing obj2;
|
||||
atexit(f2);
|
||||
</programlisting>
|
||||
<para>
|
||||
then at a call of <function>exit()</function>,
|
||||
<varname>f2</varname> will be called, then
|
||||
<varname>obj2</varname> will be destroyed, then
|
||||
<varname>f1</varname> will be called, and finally
|
||||
<varname>obj1</varname> will be destroyed. If
|
||||
<varname>f1</varname> or <varname>f2</varname> allow an
|
||||
exception to propagate out of them, Bad Things happen.
|
||||
then at a call of <function>exit()</function>,
|
||||
<varname>f2</varname> will be called, then
|
||||
<varname>obj2</varname> will be destroyed, then
|
||||
<varname>f1</varname> will be called, and finally
|
||||
<varname>obj1</varname> will be destroyed. If
|
||||
<varname>f1</varname> or <varname>f2</varname> allow an
|
||||
exception to propagate out of them, Bad Things happen.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
@ -345,9 +342,9 @@
|
||||
those slots. If you think you may run out, we recommend using
|
||||
the <function>xatexit</function>/<function>xexit</function> combination from <literal>libiberty</literal>, which has no such limit.
|
||||
</para>
|
||||
</sect1>
|
||||
</sect2>
|
||||
|
||||
<sect1 id="support.termination.verbose" xreflabel="Verbose Terminate Handler">
|
||||
<sect2 id="support.termination.verbose" xreflabel="Verbose Terminate Handler">
|
||||
<?dbhtml filename="verbose_termination.html"?>
|
||||
<title>Verbose Terminate Handler</title>
|
||||
<para>
|
||||
@ -358,7 +355,7 @@
|
||||
|
||||
<programlisting>
|
||||
#include <exception>
|
||||
|
||||
|
||||
int main()
|
||||
{
|
||||
std::set_terminate(__gnu_cxx::__verbose_terminate_handler);
|
||||
@ -390,7 +387,7 @@ int main()
|
||||
#include <stdexcept>
|
||||
|
||||
struct argument_error : public std::runtime_error
|
||||
{
|
||||
{
|
||||
argument_error(const std::string& s): std::runtime_error(s) { }
|
||||
};
|
||||
|
||||
@ -436,7 +433,7 @@ int main(int argc)
|
||||
std::set_terminate(std::abort);
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
<para>
|
||||
After this, all calls to <function>terminate</function> will use
|
||||
<function>abort</function> as the terminate handler.
|
||||
</para>
|
||||
@ -449,7 +446,7 @@ int main(int argc)
|
||||
an unspecified manner.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
</part>
|
||||
</chapter>
|
||||
|
@ -1042,7 +1042,7 @@ namespace gtk
|
||||
<filename class="headerfile">cstdlib</filename>
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<filename class="headerfile">exception</filename>
|
||||
@ -1075,7 +1075,7 @@ namespace gtk
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
In addition, throw in
|
||||
In addition, throw in
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
@ -1103,12 +1103,12 @@ namespace gtk
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
<para> There exists a library that offers runtime support for
|
||||
just these headers, and it is called
|
||||
<filename class="libraryfile">libsupc++.a</filename>. To use it, compile with <command>gcc</command> instead of <command>g++</command>, like so:
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
<command>gcc foo.cc -lsupc++</command>
|
||||
</para>
|
||||
@ -1501,7 +1501,7 @@ gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
|
||||
this at application run-time
|
||||
see <link linkend="manual.intro.using.macros">here</link>. Also
|
||||
useful are details
|
||||
on <link linkend="manual.util.memory.allocator">allocator</link>
|
||||
on <link linkend="std.util.memory.allocator">allocator</link>
|
||||
options and capabilities.
|
||||
</para>
|
||||
|
||||
|
@ -1,12 +1,12 @@
|
||||
<?xml version='1.0'?>
|
||||
<!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
|
||||
[ ]>
|
||||
|
||||
<part id="manual.util" xreflabel="Utilities">
|
||||
<chapter id="std.util" xreflabel="Utilities">
|
||||
<?dbhtml filename="utilities.html"?>
|
||||
|
||||
<partinfo>
|
||||
|
||||
<chapterinfo>
|
||||
<keywordset>
|
||||
<keyword>
|
||||
ISO C++
|
||||
@ -15,28 +15,28 @@
|
||||
library
|
||||
</keyword>
|
||||
</keywordset>
|
||||
</partinfo>
|
||||
</chapterinfo>
|
||||
|
||||
<title>
|
||||
Utilities
|
||||
<indexterm><primary>Utilities</primary></indexterm>
|
||||
</title>
|
||||
|
||||
<!-- Chapter 01 : Functors -->
|
||||
<chapter id="manual.util.functors" xreflabel="Functors">
|
||||
<!-- Section 01 : Functors -->
|
||||
<section id="std.util.functors" xreflabel="Functors">
|
||||
<?dbhtml filename="functors.html"?>
|
||||
<title>Functors</title>
|
||||
<para>If you don't know what functors are, you're not alone. Many people
|
||||
get slightly the wrong idea. In the interest of not reinventing
|
||||
the wheel, we will refer you to the introduction to the functor
|
||||
concept written by SGI as part of their STL, in
|
||||
concept written by SGI as chapter of their STL, in
|
||||
<ulink url="http://www.sgi.com/tech/stl/functors.html">their
|
||||
http://www.sgi.com/tech/stl/functors.html</ulink>.
|
||||
</para>
|
||||
</chapter>
|
||||
</section>
|
||||
|
||||
<!-- Chapter 02 : Pairs -->
|
||||
<chapter id="manual.util.pairs" xreflabel="Pairs">
|
||||
<!-- Section 02 : Pairs -->
|
||||
<section id="std.util.pairs" xreflabel="Pairs">
|
||||
<?dbhtml filename="pairs.html"?>
|
||||
<title>Pairs</title>
|
||||
<para>The <code>pair<T1,T2></code> is a simple and handy way to
|
||||
@ -76,7 +76,7 @@
|
||||
</para>
|
||||
<programlisting>
|
||||
x.first < y.first ||
|
||||
( !(y.first < x.first) && x.second < y.second )
|
||||
( !(y.first < x.first) && x.second < y.second )
|
||||
</programlisting>
|
||||
<para>The other operators are not defined using the <code>rel_ops</code>
|
||||
functions above, but their semantics are the same.
|
||||
@ -89,10 +89,10 @@
|
||||
pair<int,MyClass> p = make_pair(4,myobject);
|
||||
</programlisting>
|
||||
|
||||
</chapter>
|
||||
</section>
|
||||
|
||||
<!-- Chapter 03 : Memory -->
|
||||
<chapter id="manual.util.memory" xreflabel="Memory">
|
||||
<!-- Section 03 : Memory -->
|
||||
<section id="std.util.memory" xreflabel="Memory">
|
||||
<?dbhtml filename="memory.html"?>
|
||||
<title>Memory</title>
|
||||
<para>
|
||||
@ -104,28 +104,28 @@
|
||||
</para>
|
||||
|
||||
<!-- Section 01 : allocator -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="allocator.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Section 02 : auto_ptr -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="auto_ptr.xml">
|
||||
</xi:include>
|
||||
|
||||
<!-- Section 03 : shared_ptr -->
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
parse="xml" href="shared_ptr.xml">
|
||||
</xi:include>
|
||||
|
||||
</chapter>
|
||||
</section>
|
||||
|
||||
<!-- Chapter 04 : Traits -->
|
||||
<chapter id="manual.util.traits" xreflabel="Traits">
|
||||
<!-- Section 04 : Traits -->
|
||||
<section id="std.util.traits" xreflabel="Traits">
|
||||
<?dbhtml filename="traits.html"?>
|
||||
<title>Traits</title>
|
||||
<para>
|
||||
</para>
|
||||
</chapter>
|
||||
</section>
|
||||
|
||||
</part>
|
||||
</chapter>
|
||||
|
@ -1,4 +1,4 @@
|
||||
// Copyright (C) 2007, 2009 Free Software Foundation, Inc.
|
||||
// Copyright (C) 2007, 2009, 2010 Free Software Foundation, Inc.
|
||||
//
|
||||
// This file is part of the GNU ISO C++ Library. This library is free
|
||||
// software; you can redistribute it and/or modify it under the
|
||||
@ -20,7 +20,7 @@
|
||||
// see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
|
||||
// <http://www.gnu.org/licenses/>.
|
||||
|
||||
/** @file include/c++0x_warning.h
|
||||
/** @file c++0x_warning.h
|
||||
* This is a Standard C++ Library header.
|
||||
*/
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user