www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - STLSoft 1.9.80 released

reply Matt Wilson <matthewwilson acm.org> writes:
Download from http://stlsoft.org/

============================================================================

Changes for 1.9.80 (6th May 2009)

Summary:
========

 * now recognises support for variadic macros and #pragma once for later
versions of Borland C/C++
 * SunPro compatibility improvements for UNIXSTL synchronisation components
 * fixes to defects in stlsoft::basic_simple_string at() and 5-parameter
compare() methods
 * basic_path class templates (both UNIXSTL and WinSTL versions) now implement
assignment operator differently to avoid possibilities of infinite loops (which
can happen when a type with an opposing string encoding is used)
 * correction to stlsoft::auto_buffer to ensure allocators are involved in
swap() operations
 * correction to struct in_addr string access shims for compatibility with
big-endian architectures
 * various changes for compatibility with "safe string" library

Changes:
========

 STLSoft:
 ========

 ~ include/stlsoft/algorithms/std/alt.hpp:
    ~ "safe string" library compatibility (via a workaround that just ignores
it wrt std::find())

 ~ include/stlsoft/internal/cccap/borland.h:
    ~ STLSOFT_CF_PRAGMA_ONCE_SUPPORT support
    ~ STLSOFT_CF_SUPPORTS_VARIADIC_MACROS support

 ~ include/stlsoft/iterators/null_output_iterator.hpp:
    ~ suppression of compiler warning

 ~ include/stlsoft/memory/auto_buffer.hpp:
    ~ now swaps allocators

 ~ include/stlsoft/string/simple_string.hpp:
    ~ more "safe string" compatibility
    ~ fixed defective 5-parameter compare() method
    ~ fixed defect in non-mutating version of at(), whereby specifying the
index == length did not throw, but returned a reference to the terminating nul
character (which is what the subscript operator should do (and does do))

 ~ include/stlsoft/string/split_functions.hpp:
    ~ trivial formatting change

 InetSTL:
 ========

 ~ include/inetstl/shims/access/string/std/in_addr.hpp:
    ~ use of ntohl(), so compatible with big-endian as well as little
    ~ compatibility with "safe string" library

 UNIXSTL:
 ========

 ~ include/unixstl/filesystem/path.hpp:
    ~ changed implementation of generic operator =() in order to avoid
possibilities of infinite loops (which can happen when a type with an opposing
string encoding is used)
    ~ trivial documentation markup changes

 ~ include/unixstl/synch/process_mutex.hpp:
    ~ SunPro support (partially complete)

 ~ include/unixstl/synch/thread_mutex.hpp:
    ~ SunPro support (partially complete)

 WinSTL:
 =======

 ~ include/winstl/filesystem/path.hpp:
    ~ changed implementation of generic operator =() in order to avoid
possibilities of infinite loops (which can happen when a type with an opposing
string encoding is used)

============================================================================
May 06 2009
parent reply Sam Fisher <infest21h gmail.com> writes:
Hello!

Can you add recursive delete key function into Registry library?
(RegDeleteTree on Vista SDK / SHDeleteKey)


/WBR, Sam Fisher.
May 06 2009
parent reply "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
Hi Sam

The problem here is that other OSs don't have such a function, so we'd either
have to simulate it for the others, or provide it as a
Vista-only function, which presents a problem in itself, since I don't own (and
won't own!) a copy of the execrable Vista.

Probably it would be better to just simulate it for all.

Coincidentally, I did in fact write an article about such a thing for WDJ
several years ago - see
http://www.ddj.com/architect/184405591 - so it shouldn't be too hard to knock
one up. Do you fancy having a go? :-)

Matt

"Sam Fisher" <infest21h gmail.com> wrote in message
news:gtsesl$qlr$1 digitalmars.com...

 Hello!

 Can you add recursive delete key function into Registry library?
 (RegDeleteTree on Vista SDK / SHDeleteKey)


 /WBR, Sam Fisher.
May 06 2009
parent reply "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
Ok, I'm a dum-dum. I forgot about SHDeleteKey.

Well, fine, let's just use dl_call to try RegDeleteTree, and then fall back to
SHDeleteKey, and only throw if neither is available.

How do you see the delete function fitting into the library? I ask because
 (i) I am pretty rusty on the reg library, as I've not made any changes to it
in a long time, nor have I used it much, and
 (ii) it's one of the libraries whose interfaces I'm planning to substantially
change with STLSoft 1.10, so I'm interested in how
people think it should look and behave

Cheers

Matt

"Matthew Wilson" <matthew hat.stlsoft.dot.org> wrote in message
news:gttj5p$2r8q$1 digitalmars.com...

 Hi Sam

 The problem here is that other OSs don't have such a function, so we'd either
have to simulate it for the others, or provide it as


a

 Vista-only function, which presents a problem in itself, since I don't own
(and won't own!) a copy of the execrable Vista.

 Probably it would be better to just simulate it for all.

 Coincidentally, I did in fact write an article about such a thing for WDJ
several years ago - see
 http://www.ddj.com/architect/184405591 - so it shouldn't be too hard to knock
one up. Do you fancy having a go? :-)

 Matt

 "Sam Fisher" <infest21h gmail.com> wrote in message
news:gtsesl$qlr$1 digitalmars.com...

 Hello!

 Can you add recursive delete key function into Registry library?
 (RegDeleteTree on Vista SDK / SHDeleteKey)


 /WBR, Sam Fisher.
May 06 2009
parent reply Sam Fisher <infest21h gmail.com> writes:
Matthew Wilson wrote:


 Ok, I'm a dum-dum. I forgot about SHDeleteKey.
 
 Well, fine, let's just use dl_call to try RegDeleteTree, and then fall back to
SHDeleteKey, and only throw if neither is available.


I think this is the best way.


 
 How do you see the delete function fitting into the library? I ask because


As usual, the registry traits
i.e.
struct reg_traits<...>
{
...
	static result_type reg_delete_tree(hkey_type hkey, char_type const* 
sub_key_name)
	{
		...
	}
}


  (i) I am pretty rusty on the reg library, as I've not made any changes to it
in a long time, nor have I used it much, and
  (ii) it's one of the libraries whose interfaces I'm planning to substantially
change with STLSoft 1.10, so I'm interested in how
 people think it should look and behave


Unfortunately I am not so skilled in reg library to give you any advices.

PS. Bug possible?


The problem occurs when trying to read empty REG_SZ value.
In function basic_reg_value<>::value_sz():

...

ws_long_t   res         =   traits_type::reg_query_info(m_hkey, NULL, 
NULL, NULL, NULL, NULL, NULL, NULL, &data_size, NULL, NULL);
...

if (some error)
{
    ...
}
else if(data_size > 0)
{
     read value
}
else
{
    >>> We have empty value <<<

    WINSTL_ASSERT(0 != data_size);

    --data_size; // This is required since the size contains space for 
the nul-terminator

    buffer[data_size / sizeof(char_type)] = 0; // The site of a former 
bug. Thanks to Diego Chanoux for spotting this

   ret.assign(buffer.data(), data_size / sizeof(char_type));
}

In debug: assert works
in release: access violation error

(Sorry for English, it's not my native)

/WBR, Sam Fisher
May 07 2009
parent reply "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
 PS. Bug possible?


 The problem occurs when trying to read empty REG_SZ value.
 In function basic_reg_value<>::value_sz():

 ...

 ws_long_t   res         =   traits_type::reg_query_info(m_hkey, NULL,
 NULL, NULL, NULL, NULL, NULL, NULL, &data_size, NULL, NULL);
 ...

 if (some error)
 {
     ...
 }
 else if(data_size > 0)
 {
      read value
 }
 else
 {
     >>> We have empty value <<<

     WINSTL_ASSERT(0 != data_size);

     --data_size; // This is required since the size contains space for
 the nul-terminator

     buffer[data_size / sizeof(char_type)] = 0; // The site of a former
 bug. Thanks to Diego Chanoux for spotting this

    ret.assign(buffer.data(), data_size / sizeof(char_type));
 }


I can't reproduce this. Can you let me know the following information:
 * what OS you're on
 * what compiler you've used
 * which hive the value is being retrieved from
 * what the key path it

Also, if you can, can you extract the key in a Win98 (ANSI text) format, and
send to me, so I can attempt to reproduce here?

Thanks

Matt
May 18 2009
parent reply "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
 I can't reproduce this. Can you let me know the following information:
  * what OS you're on
  * what compiler you've used
  * which hive the value is being retrieved from
  * what the key path it

 Also, if you can, can you extract the key in a Win98 (ANSI text) format,


and send to me, so I can attempt to reproduce here?

Also, what version of STLSoft are you using?
May 18 2009
parent "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
"Matthew Wilson" <matthew hat.stlsoft.dot.org> wrote in message
news:gur38j$5j0$1 digitalmars.com...

 I can't reproduce this. Can you let me know the following information:
  * what OS you're on
  * what compiler you've used
  * which hive the value is being retrieved from
  * what the key path it

 Also, if you can, can you extract the key in a Win98 (ANSI text) format,


 and send to me, so I can attempt to reproduce here?

 Also, what version of STLSoft are you using?


Scratch all that. I can reproduce it after all.

A fix will be in the offing soon ...

Matt
May 18 2009