Just want to let you know about, and simultaneously give thanks to Sergey Nikulov for, FreeBSD compatibility in STLSoft (as of 1.9.36) and Pantheios (as of 1.0.1 beta 128).
I'm still working on Win64, and will continue with that effort. But it's now very cool that Pantheios is working on Win32, Linux 32, Linux 64, Solaris 32, Solaris 64 and FreeBSD.
Musings of an STL-extension library designer (who's renowned for producing high-quality software with low-quality documentation).
Wednesday, April 30, 2008
Sunday, April 27, 2008
1.9.x roadmap (Apr / May 08)
Ok, yes, 1.9 should have been dead and buried a year ago, to be surplanted by the wonderful 1.10, but the real world's got this bad habit of getting in the way. (And I've been putting in heaps on Pantheios.)
So 1.9.x is still living, and there's quite a bit to do on it. The currently envisioned roadmap is as follows:
So 1.9.x is still living, and there's quite a bit to do on it. The currently envisioned roadmap is as follows:
- 1.9.35 will be released in the next 24 hours, and will contain an update to the Windows Registry library's winstl::basic_reg_value, comprising the new value_multi_sz() method, whose original implementation was kindly provided by Austin Ziegler
- 1.9.36 A first stab at full x64 support
- 1.9.37 getting all the Safe String library compatibility done. This is going to be a big effort. :-(
- 1.9.38 A second stab at full x64 support, since I'm unlikely to have it down pat the first go.
- 1.9.39 This'll likely comprise the ATL/MFC stuff that Claudio's been asking for since, er, early last year :$
- 1.9.40 This'll probably include a (#define-reenableable) removal of the stuff in stlsoft/std/*.hpp, as this is eminently bettered by the new flecxx library, that is due to be released very, very soon.
Other than that, I'm going to try and get the 1.10 preview releases started. Given the time ... ;-)
Thursday, April 24, 2008
Sun Pro C/C++ compatibility with 1.9.33: step 1
The latest release - 1.9.33 - is now available, and contains modifications to enable compatibility with the Sun Pro C and C++ compilers (version 5.9).
The modifications were something of a marathon effort, and it might be good to spread the information around for anyone contemplating porting STLSoft to another C++ compiler.
In this post, I'll discuss how to get the basic support in there, which is basically recognising the Sun Pro compilers and defining their features
Recognising the Sun Pro compilers
I began with the position that I was confident on, based on Jonathan Wakely's efforts with Pantheios, to whit: Pantheios and STLSoft work with Sun Pro when the -library=stlport4 flag is defined to sunCC (the Sun Pro C++ compiler).
In order to achieve this, all that was required was to discriminate the Sun Pro compiler in include/stlsoft/stlsoft.h, and provide a compiler compatibility file: include/stlsoft/internal/cccap/sunpro.h.
In include/stlsoft/stlsoft.h, insert the following between the Metrowerks and VectorC discriminations:
In include/stlsoft/stlsoft.h, insert the following between the Metrowerks and VectorC compiler compatibility inclusions
Defining the Sun Pro compilers' features
Define a new file include/stlsoft/internal/cccap/sunpro.h, containing all the required definitions that describe the capabilities of the C and C++ compilers. The important bits are:
I hope that's clear. ;-)
In the next post I'll discuss the other changes required to get Pantheios built with the -library=libCstd
The modifications were something of a marathon effort, and it might be good to spread the information around for anyone contemplating porting STLSoft to another C++ compiler.
In this post, I'll discuss how to get the basic support in there, which is basically recognising the Sun Pro compilers and defining their features
Recognising the Sun Pro compilers
I began with the position that I was confident on, based on Jonathan Wakely's efforts with Pantheios, to whit: Pantheios and STLSoft work with Sun Pro when the -library=stlport4 flag is defined to sunCC (the Sun Pro C++ compiler).
In order to achieve this, all that was required was to discriminate the Sun Pro compiler in include/stlsoft/stlsoft.h, and provide a compiler compatibility file: include/stlsoft/internal/cccap/sunpro.h.
In include/stlsoft/stlsoft.h, insert the following between the Metrowerks and VectorC discriminations:
#elif defined(__SUNPRO_C) || \
defined(__SUNPRO_CC)
/* Sanity check on language/compiler */
# ifdef __cplusplus
# ifdef __SUNPRO_C
# error __SUNPRO_C should not be defined by the Sun C compiler in C++ compilation
# endif /* __SUNPRO_C */
# ifndef __SUNPRO_CC
# error __SUNPRO_CC should be defined by the Sun C++ compiler in C++ compilation
# endif /* !__SUNPRO_CC */
# else /* ? __cplusplus */
# ifndef __SUNPRO_C
# error __SUNPRO_C should be defined by the Sun C compiler in C compilation
# endif /* !__SUNPRO_C */
# ifdef __SUNPRO_CC
# error __SUNPRO_CC should not be defined by the Sun C++ compiler in C compilation
# endif /* __SUNPRO_CC */
# endif /* __cplusplus */
# define STLSOFT_COMPILER_IS_SUNPRO
# ifdef __cplusplus
# define STLSOFT_COMPILER_LABEL_STRING "Sun Pro C++"
# if (0x0590 == (__SUNPRO_CC & 0xFFF0))
# define STLSOFT_COMPILER_VERSION_STRING "Sun Pro C++ v5.9"
# else /* ? __SUNPRO_CC */
# error Currently only version v5.9 of the Sun Pro C++ compiler is supported by the STLSoft libraries
# endif /* __SUNPRO_CC */
# else /* ? __cplusplus */
# define STLSOFT_COMPILER_LABEL_STRING "Sun Pro C"
# if (0x0590 == (__SUNPRO_C & 0xFFF0))
# define STLSOFT_COMPILER_VERSION_STRING "Sun Pro C v5.9"
# else /* ? __SUNPRO_CC */
# error Currently only version v5.9 of the Sun Pro C compiler is supported by the STLSoft libraries
# endif /* __SUNPRO_CC */
# endif /* __cplusplus */
In include/stlsoft/stlsoft.h, insert the following between the Metrowerks and VectorC compiler compatibility inclusions
#elif defined(STLSOFT_COMPILER_IS_SUNPRO)
# include <stlsoft/internal/cccap/sunpro.h>
Defining the Sun Pro compilers' features
Define a new file include/stlsoft/internal/cccap/sunpro.h, containing all the required definitions that describe the capabilities of the C and C++ compilers. The important bits are:
/* /////////////////////////////////////////////////////////////////////////
* File: stlsoft/internal/cccap/sunpro.h
*
* Purpose: Compiler feature discrimination for SunPro C / SunPro C++.
*
* Created: 24th April 2008
* Updated: 25th April 2008
*
* Thanks: To Jonathan Wakeley and Lars Ivar Igesund for help with
* getting STLSoft (and Pantheios) compatible with Solaris.
*
* Home: http://stlsoft.org/
*
* Copyright (c) 2008, Matthew Wilson and Synesis Software
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* - Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
* - Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
* - Neither the name(s) of Matthew Wilson and Synesis Software nor the names of
* any contributors may be used to endorse or promote products derived from
* this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*
* ////////////////////////////////////////////////////////////////////// */
#ifndef STLSOFT_INCL_STLSOFT_H_STLSOFT
# error This file must not be included independently of stlsoft/stlsoft.h
#endif /* !STLSOFT_INCL_STLSOFT_H_STLSOFT */
/** \file stlsoft/internal/cccap/sunpro.h
*
* Compiler feature discrimination for SunPro C / SunPro C++.
* (\ref group__library__internal).
*/
#ifdef STLSOFT_INCL_H_STLSOFT_CCCAP_SUNPRO
# error This file cannot be included more than once in any compilation unit
#endif /* STLSOFT_INCL_H_STLSOFT_CCCAP_SUNPRO */
/* ////////////////////////////////////////////////////////////////////// */
#ifndef STLSOFT_DOCUMENTATION_SKIP_SECTION
# define STLSOFT_VER_H_STLSOFT_CCCAP_SUNPRO_MAJOR 1
# define STLSOFT_VER_H_STLSOFT_CCCAP_SUNPRO_MINOR 0
# define STLSOFT_VER_H_STLSOFT_CCCAP_SUNPRO_REVISION 2
# define STLSOFT_VER_H_STLSOFT_CCCAP_SUNPRO_EDIT 2
#endif /* !STLSOFT_DOCUMENTATION_SKIP_SECTION */
/* /////////////////////////////////////////////////////////////////////////
* Auto-generation and compatibility
*/
/*
[<[STLSOFT-AUTO:NO-DOCFILELABEL]>]
[<[STLSOFT-AUTO:NO-UNITTEST]>]
*/
/* /////////////////////////////////////////////////////////////////////////
* Helper definitions
*
* NOTE: These are #undef'd at the end of this file
*/
#ifdef __cplusplus
# define _STLSOFT_SUNPRO_VER_ __SUNPRO_CC
#else /* ? __cplusplus */
# define _STLSOFT_SUNPRO_VER_ __SUNPRO_C
#endif /* __cplusplus */
#define _STLSOFT_SUNPRO_VER_MAJOR ((_STLSOFT_SUNPRO_VER_ & 0xff00) >> 8)
#define _STLSOFT_SUNPRO_VER_MINOR ((_STLSOFT_SUNPRO_VER_ & 0x00f0) >> 4)
/* /////////////////////////////////////////////////////////////////////////
* Compiler features
*/
#if (5 != _STLSOFT_SUNPRO_VER_MAJOR) || \
(9 != _STLSOFT_SUNPRO_VER_MINOR)
# error The STLSoft libraries have only been verified with Sun Pro 5.9.x. Please contact Synesis Software
#endif /* major.minor */
/* ///////////////////////////////////////////////
* Pre-processor / compiler
*/
/* Messaging
*/
/* #define STLSOFT_CF_PRAGMA_MESSAGE_SUPPORT */
/* Support for #pragma once
*/
/* #define STLSOFT_CF_PRAGMA_ONCE_SUPPORT */
/* Support for __FUNCTION__
*/
/* #define STLSOFT_CF_FUNCTION_SYMBOL_SUPPORT */
/* Variadic Macros
*
* Feature was buggy at one point, require 5.5 to be safe.
*/
#if _STLSOFT_SUNPRO_VER_ > 0x0550
# define STLSOFT_CF_SUPPORTS_VARIADIC_MACROS
#endif /* _STLSOFT_SUNPRO_VER_ */
/* ///////////////////////////////////////////////
* Types
*/
/* bool */
#if defined(__cplusplus) && \
defined(_BOOL)
# define STLSOFT_CF_NATIVE_BOOL_SUPPORT
#endif /* __cplusplus */
/* char (sign) */
/* #define STLSOFT_CF_CHAR_IS_UNSIGNED */
/* wchar_t */
#ifdef _WCHAR_T
# define STLSOFT_CF_NATIVE_WCHAR_T_SUPPORT
#endif
/* /////////////////////////////////////
* Integral types
*
* The purpose of this section is to define the following types:
*
* - 8-bit signed and unsigned integers
* - 16-bit signed and unsigned integers
* - 32-bit signed and unsigned integers
* - (optionally) 64-bit signed and unsigned integers
*
* and to define, where appropriate the following symbols (used for
* overloading):
*
* - STLSOFT_CF_CHAR_DISTINCT_INT_TYPE
* - STLSOFT_CF_SHORT_DISTINCT_INT_TYPE
* - STLSOFT_CF_INT_DISTINCT_INT_TYPE
* - STLSOFT_CF_LONG_DISTINCT_INT_TYPE
* - STLSOFT_CF_LONG_LONG_DISTINCT_INT_TYPE
*
* which indicate that a given type is not used in the size-specific types.
*/
#if defined(_LP64) || \
defined(__LP64__)
# define _STLSOFT_SIZEOF_CHAR (1)
# define _STLSOFT_SIZEOF_SHORT (2)
# define _STLSOFT_SIZEOF_INT (4)
# define _STLSOFT_SIZEOF_LONG (8)
# define _STLSOFT_SIZEOF_LONG_LONG (8)
#else /* ? data model */
# define _STLSOFT_SIZEOF_CHAR (1)
# define _STLSOFT_SIZEOF_SHORT (2)
# define _STLSOFT_SIZEOF_INT (4)
# define _STLSOFT_SIZEOF_LONG (4)
# define _STLSOFT_SIZEOF_LONG_LONG (8)
#endif /* data model */
#if 0
#if defined(__sparcv9)
# error Use of Sun Pro has not yet been verified on 64-bit Sparc. Please contact Synesis Software
#elif defined(__amd64)
# error Use of Sun Pro has not yet been verified on x64. Please contact Synesis Software
# ifndef __LP64__
# error LP64 memory model is assumed on x64. Please contact Synesis Software
# endif /* __LP64__ */
# define _STLSOFT_SIZEOF_CHAR (1)
# define _STLSOFT_SIZEOF_SHORT (2)
# define _STLSOFT_SIZEOF_INT (4)
# define _STLSOFT_SIZEOF_LONG (8)
# define _STLSOFT_SIZEOF_LONG_LONG (8)
#elif defined(__sparc) || \
defined(__i386)
# define _STLSOFT_SIZEOF_CHAR (1)
# define _STLSOFT_SIZEOF_SHORT (2)
# define _STLSOFT_SIZEOF_INT (4)
# define _STLSOFT_SIZEOF_LONG (4)
# define _STLSOFT_SIZEOF_LONG_LONG (8)
#else /* ? data model */
# error Use of Sun Pro has not been verified on any operation system other than x86, x64 and Sparc. Please contact Synesis Software
#endif /* data model */
#endif /* 0 */
/* 8-bit integer */
#define STLSOFT_CF_8BIT_INT_SUPPORT
#define STLSOFT_SI08_T_BASE_TYPE signed char
#define STLSOFT_UI08_T_BASE_TYPE unsigned char
/* 16-bit integer */
#define STLSOFT_CF_16BIT_INT_SUPPORT
#define STLSOFT_SI16_T_BASE_TYPE signed short
#define STLSOFT_UI16_T_BASE_TYPE unsigned short
/* 32-bit integer */
#define STLSOFT_CF_32BIT_INT_SUPPORT
#define STLSOFT_SI32_T_BASE_TYPE signed int
#define STLSOFT_UI32_T_BASE_TYPE unsigned int
#define STLSOFT_CF_LONG_DISTINCT_INT_TYPE
/* 64-bit integer */
#define STLSOFT_CF_64BIT_INT_SUPPORT
#define STLSOFT_CF_64BIT_INT_IS_long_long
#define STLSOFT_SI64_T_BASE_TYPE signed long long
#define STLSOFT_UI64_T_BASE_TYPE unsigned long long
/* ///////////////////////////////////////////////
* Language features
*/
/* Anonymous unions */
#ifdef __cplusplus
# define STLSOFT_CF_ANONYMOUS_UNION_SUPPORT
#endif /* __cplusplus */
/* Member constants */
#ifdef __cplusplus
# define STLSOFT_CF_MEMBER_CONSTANT_SUPPORT
#endif /* __cplusplus */
/* Static assertions */
#define STLSOFT_CF_STATIC_ASSERT_SUPPORT
/* sign of modulus of negative numbers */
#define STLSOFT_CF_NEGATIVE_MODULUS_POSITIVE_GIVES_NEGATIVE_RESULT
/* RTTI support */
#ifdef __cplusplus
# define STLSOFT_CF_RTTI_SUPPORT
#endif /* __cplusplus */
/* Exception support */
#ifdef __cplusplus
# define STLSOFT_CF_EXCEPTION_SUPPORT
#endif /* __cplusplus */
#ifdef __cplusplus
# define STLSOFT_CF_THROW_BAD_ALLOC
#endif /* __cplusplus */
/* Namespace support */
#ifdef __cplusplus
# define STLSOFT_CF_NAMESPACE_SUPPORT
#endif /* __cplusplus */
#ifdef __cplusplus
# define STLSOFT_CF_std_NAMESPACE
#endif /* __cplusplus */
/* return void */
#ifdef __cplusplus
# define STLSOFT_CF_COMPILER_SUPPORTS_RETURN_VOID
#endif /* __cplusplus */
/* Template support */
#ifdef __cplusplus
# define STLSOFT_CF_TEMPLATE_SUPPORT
#endif /* __cplusplus */
/* #define STLSOFT_CF_TEMPLATE_TYPE_REQUIRED_IN_ARGS */
/* */
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_FUNCTION_SIGNATURE_FULL_ARG_QUALIFICATION_REQUIRED
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_EXCEPTION_SIGNATURE_SUPPORT
/* !!! Assumed. Not yet verified !!! */ /* #define STLSOFT_CF_EXCEPTION_SPEC_EXPENSIVE */
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_TEMPLATE_CLASS_DEFAULT_FUNDAMENTAL_ARGUMENT_SUPPORT
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_TEMPLATE_CLASS_DEFAULT_CLASS_ARGUMENT_SUPPORT
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_MEM_FUNC_AS_TEMPLATE_PARAM_SUPPORT
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_MEMBER_TEMPLATE_FUNCTION_SUPPORT
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_MEMBER_TEMPLATE_OVERLOAD_DISCRIMINATED
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_MEMBER_TEMPLATE_CTOR_SUPPORT
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_MEMBER_TEMPLATE_CTOR_OVERLOAD_DISCRIMINATED
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_MEMBER_TEMPLATE_RANGE_METHOD_SUPPORT
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_MEMBER_TEMPLATE_CLASS_SUPPORT
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_TEMPLATE_SPECIALISATION_SYNTAX
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_TEMPLATE_PARTIAL_SPECIALISATION_SUPPORT
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_TEMPLATE_OUTOFCLASSFN_QUALIFIED_TYPE_SUPPORT
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_std_char_traits_AVAILABLE
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_PARENT_TYPES_CAN_BE_USED_IN_NON_TEMPLATE
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_PARENT_TYPES_CAN_BE_USED_IN_TEMPLATE
#define STLSOFT_CF_EXPLICIT_KEYWORD_SUPPORT
#define STLSOFT_CF_MUTABLE_KEYWORD_SUPPORT
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_TYPENAME_PARAM_KEYWORD_SUPPORT
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_TYPENAME_TYPE_KEYWORD_SUPPORT
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_TYPENAME_TYPE_DEF_KEYWORD_SUPPORT
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_TYPENAME_TYPE_MIL_KEYWORD_SUPPORT
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_TYPENAME_TYPE_RET_KEYWORD_SUPPORT
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_TEMPLATE_QUALIFIER_KEYWORD_SUPPORT
/* !!! Assumed. Not yet verified !!! */ /* #define STLSOFT_CF_MOVE_CONSTRUCTOR_SUPPORT */
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_ADL_LOOKUP_SUPPORT
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_TEMPLATE_TEMPLATE_SUPPORT
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_STATIC_ARRAY_SIZE_DETERMINATION_SUPPORT
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_VENEER_SUPPORT
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_ALLOCATOR_BASE_EXPENSIVE
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_COMPILER_WARNS_NO_PUBLIC_DTOR
/* Shims are supported?
*/
/* #define STLSOFT_CF_TEMPLATE_SHIMS_NOT_SUPPORTED */
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_OPERATOR_BOOL_AS_OPERATOR_POINTER_TO_MEMBER_SUPPORT
/* !!! Assumed. Not yet verified !!! */ #define STLSOFT_CF_OPERATOR_NOT_VIA_OPERATOR_POINTER_TO_MEMBER_SUPPORT
#if defined(_STLSOFT_CUSTOM_ASSERT)
/* You have defined the pre-processor symbol _STLSOFT_CUSTOM_ASSERT,
* which stipulates that you will be providing your own assert. This
* requires that you have defined _STLSOFT_CUSTOM_ASSERT() as a macro
* taking 1 parameter (the condition to assert).
*
* Suppose you have a function _DisplayAssert(), which has the
* following signature:
*
* void _DisplayAssert(char const* file, int line, char const* expression);
*
* Presumably you would also have your own assert macro, say MY_ASSERT(),
* defined as:
*
* #define MY_ASSERT(_x) ((void)((!(_x)) ? ((void)(_DisplayAssert(__FILE__, __LINE__, #_x))) : ((void)0)))
*
* so you would simply need to define _STLSOFT_CUSTOM_ASSERT() in terms of
* MY_ASSERT(), as in:
*
* #define _STLSOFT_CUSTOM_ASSERT(_x) MY_ASSERT(_x)
*
* where
*/
# define __STLSOFT_CF_ASSERT_SUPPORT
# define STLSOFT_CF_ASSERT_SUPPORT
# define STLSOFT_ASSERT(_x) _STLSOFT_CUSTOM_ASSERT(_x)
# if defined(_STLSOFT_CUSTOM_ASSERT_INCLUDE)
# define __STLSOFT_CF_ASSERT_INCLUDE_NAME _STLSOFT_CUSTOM_ASSERT_INCLUDE
# else
# error You must define _STLSOFT_CUSTOM_ASSERT_INCLUDE along with _STLSOFT_CUSTOM_ASSERT()
# endif /* !_STLSOFT_CUSTOM_ASSERT_INCLUDE */
#else /* ? _STLSOFT_CUSTOM_ASSERT */
# define __STLSOFT_CF_ASSERT_SUPPORT
# define STLSOFT_CF_ASSERT_SUPPORT
/* # define __STLSOFT_CF_USE_cassert */
# define __STLSOFT_CF_ASSERT_INCLUDE_NAME <assert.h>
# define STLSOFT_ASSERT(_x) assert(_x)
#endif /* _STLSOFT_CUSTOM_ASSERT */
/* /////////////////////////////////////////////////////////////////////////
* Calling convention
*/
#define STLSOFT_CF_CDECL_SUPPORTED
#ifdef STLSOFT_CF_CDECL_SUPPORTED
# define STLSOFT_CDECL
#endif /* STLSOFT_CF_CDECL_SUPPORTED */
/* /////////////////////////////////////////////////////////////////////////
* Inline assembler
*/
/* #define STSLSOFT_INLINE_ASM_SUPPORTED */
/* #define STSLSOFT_ASM_IN_INLINE_SUPPORTED */
/* /////////////////////////////////////////////////////////////////////////
* inline support
*/
#define STLSOFT_CF_C99_INLINE
/* /////////////////////////////////////////////////////////////////////////
* If <cwchar> gets included after <stdio.h> or <cstdio> then it fails to
* declare mbstate_t and various wchar functions, so include it now to try
* and reduce problem (too late if <stdio.h> has already been included.)
* http://forum.java.sun.com/thread.jspa?messageID=10035724
*/
#ifdef STLSOFT_LINUX_STDIO_ORDER_BUG
# ifdef __cplusplus
# include <cwchar>
# endif /* __cplusplus */
#endif /* STLSOFT_LINUX_STDIO_ORDER_BUG */
/* /////////////////////////////////////////////////////////////////////////
* Compiler warning suppression
*/
/* /////////////////////////////////////////////////////////////////////////
* Helper definitions
*/
#undef _STLSOFT_SUNPRO_VER_
#undef _STLSOFT_SUNPRO_VER_MAJOR
#undef _STLSOFT_SUNPRO_VER_MINOR
/* ////////////////////////////////////////////////////////////////////// */
I hope that's clear. ;-)
In the next post I'll discuss the other changes required to get Pantheios built with the -library=libCstd
Monday, April 14, 2008
Fit vs Fat
No, this has nothing to do with my ongoing exploits in eeking out greater and greater performance of my aging hulk.
Rather, it's about an approach to library design that errs on the side of providing the minimum possible, rather than the maximum potential permutations of functionality.
Of course, age, learning, evolving paradigms, and backwards-compatibility all tend to result in accretion of functionality. And there's nothing going to happen in 1.9.x to start removing code. But as of 1.10 I'd like to rewrite several popular libraries to address the crustification.
To guide me in this, I'm looking for users to write in and make their complaints/requests.
Obvious (to me) candidates for face-lifts include:
Rather, it's about an approach to library design that errs on the side of providing the minimum possible, rather than the maximum potential permutations of functionality.
Of course, age, learning, evolving paradigms, and backwards-compatibility all tend to result in accretion of functionality. And there's nothing going to happen in 1.9.x to start removing code. But as of 1.10 I'd like to rewrite several popular libraries to address the crustification.
To guide me in this, I'm looking for users to write in and make their complaints/requests.
Obvious (to me) candidates for face-lifts include:
- FileSystem Library
- System Library
- Windows Registry Library (see include/winstl/registry/*)
- Windows Controls
- Error Library (in fact this is already happening)
- Containers Library
- String Library (see this post)
Do you have any more? If so, please let me know, either here or on the STLSoft newsgroup.
static_string semantics redux
I'm currently using stlsoft::static_string to test the soon-to-be-released FastFormat library. (btw, if you're a user/reader of mine, you're probably heartily sick of the phrase "soon-to-be-released", I hear ya!)
static_string is a std::string-like string class that has a fixed internal buffer. It relies on contracts to force on the user respect for its limitations, to whit you may not attempt to cause the string contents to exceed the internal size.
That's all very well and good, as it's clear. What's probably not so cool is that people tend not to either grok, or want to respect, the principles of contract programming.
So it's occuring to me that static_string should evolve for STLSoft 1.10 and change its contracts from "you may not try to expand me beyond my capacity limit" to "if you try and expand me beyond my capacity limit" I will inform you (by an exception).
There's another evolution that would be good, and that's one that would be able to work atop an external character buffer. But that brings the notion of policy classes into play, and they suck in general.
So, I'm starting to think that we'll have either a separate class (template), or a base utility template that gets specialised in two different ways by, say, static_string and external_string class templates.
Watch this space ...
static_string is a std::string-like string class that has a fixed internal buffer. It relies on contracts to force on the user respect for its limitations, to whit you may not attempt to cause the string contents to exceed the internal size.
That's all very well and good, as it's clear. What's probably not so cool is that people tend not to either grok, or want to respect, the principles of contract programming.
So it's occuring to me that static_string should evolve for STLSoft 1.10 and change its contracts from "you may not try to expand me beyond my capacity limit" to "if you try and expand me beyond my capacity limit" I will inform you (by an exception).
There's another evolution that would be good, and that's one that would be able to work atop an external character buffer. But that brings the notion of policy classes into play, and they suck in general.
So, I'm starting to think that we'll have either a separate class (template), or a base utility template that gets specialised in two different ways by, say, static_string and external_string class templates.
Watch this space ...
Saturday, April 12, 2008
STLSoft 1.10 preview
There're several things that've been waiting to go into the 1.10 release for quite a while - some over 2 years! - and it's beyond ridiculous.
So, from the end of this week onwards, I'm going to make a preview release of the next version of the library available alongside the main release. The first version of this will contain only the platformstl::properties_file component, whic his needed for the soon-to-be-released alpha release of the much-delayed FastFormat library.
This simple but sophisticated properties file reader class provides a non-mutable vector like interface, along the following lines:
class properties_file
{
public: /// Member Types
typedef stlsoft::string_view view_type;
typedef values_map_type::value_type value_type;
typedef values_map_type::const_iterator const_iterator;
typedef size_t size_type;
public: /// Construction
explicit properties_file(char const* fileName);
public: /// Accessors
view_type operator [](char const* propertyName) const;
size_type size() const;
const_iterator begin() const;
const_iterator end() const;
. . .
};
The only exotic part of it is the use of stlsoft::string_view, rather than a string value type. I'll discuss this in more depth in a future post; for now you can rest assured that it's to do with not allocating any memory we don't need to. ;-)
So, from the end of this week onwards, I'm going to make a preview release of the next version of the library available alongside the main release. The first version of this will contain only the platformstl::properties_file component, whic his needed for the soon-to-be-released alpha release of the much-delayed FastFormat library.
This simple but sophisticated properties file reader class provides a non-mutable vector
class properties_file
{
public: /// Member Types
typedef stlsoft::string_view view_type;
typedef values_map_type::value_type value_type;
typedef values_map_type::const_iterator const_iterator;
typedef size_t size_type;
public: /// Construction
explicit properties_file(char const* fileName);
public: /// Accessors
view_type operator [](char const* propertyName) const;
size_type size() const;
const_iterator begin() const;
const_iterator end() const;
. . .
};
The only exotic part of it is the use of stlsoft::string_view, rather than a string value type. I'll discuss this in more depth in a future post; for now you can rest assured that it's to do with not allocating any memory we don't need to. ;-)
STLSoft 1.9.31 released
This release includes some refactoring of the exception hierarchy of the main project (STLSoft) and several sub-projects (COMSTL, UNIXSTL and WinSTL).
The root exception used to be stlsoft::os_exception, as a nod to the fact that the two main sub-projects - UNIXSTL and WinSTL - are STL extensions over UNIX and Windows APIs. However, that's never seemed to sit comfortably, so this is now changes. The root exception is stlsoft::project_exception, from which stlsoft::os_exception derives.
The exceptions in UNIXSTL and WinSTL continue to derive from stlsoft::os_exception, but those of COMSTL now derive direct from stlsoft::project_exception.
Coming up:
This refactoring underpins further refactoring around exception/error handling, in the Windows Registry library in particular, which itself will underpin functional enhancements to that library (originally requested (and implemented) by Austin Ziegler). This stuff's likely to appear in 1.9.33
The next release (1.9.32) is likely to contain compatibility fixes for SunStudio (on Intel at first; the Solaris stuff's likely to be another week or so).
The root exception used to be stlsoft::os_exception, as a nod to the fact that the two main sub-projects - UNIXSTL and WinSTL - are STL extensions over UNIX and Windows APIs. However, that's never seemed to sit comfortably, so this is now changes. The root exception is stlsoft::project_exception, from which stlsoft::os_exception derives.
The exceptions in UNIXSTL and WinSTL continue to derive from stlsoft::os_exception, but those of COMSTL now derive direct from stlsoft::project_exception.
Coming up:
This refactoring underpins further refactoring around exception/error handling, in the Windows Registry library in particular, which itself will underpin functional enhancements to that library (originally requested (and implemented) by Austin Ziegler). This stuff's likely to appear in 1.9.33
The next release (1.9.32) is likely to contain compatibility fixes for SunStudio (on Intel at first; the Solaris stuff's likely to be another week or so).
Kicking it off, I suppose
Well, I've created the blog, so I guess I'd better put something up.
I'm still fighting with the time/invention conundrum: too many things to do and too little time.
At the moment, I'm engaged (as I have been for 18 months) in getting Pantheios to non-beta status, getting a first public FastFormat, and a whole of other things.
As for STLSoft itself, there're a few things waiting to be added, in particular the Solaris/SunStudio compatibility that Jon Wakely and some other users have been asking for. As I've not yet got my Solaris box set up, or SunStudio successfully installed on the Ubuntu 64 box, I'm probably going to have to take a punt and go with adding in the partially complete SunStudio support that my Pantheios users have kindly added into STLSoft. But this is probably better than making other users wait much longer. Such are the quandaries ...
I'm still fighting with the time/invention conundrum: too many things to do and too little time.
At the moment, I'm engaged (as I have been for 18 months) in getting Pantheios to non-beta status, getting a first public FastFormat, and a whole of other things.
As for STLSoft itself, there're a few things waiting to be added, in particular the Solaris/SunStudio compatibility that Jon Wakely and some other users have been asking for. As I've not yet got my Solaris box set up, or SunStudio successfully installed on the Ubuntu 64 box, I'm probably going to have to take a punt and go with adding in the partially complete SunStudio support that my Pantheios users have kindly added into STLSoft. But this is probably better than making other users wait much longer. Such are the quandaries ...
Subscribe to:
Posts (Atom)