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)

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

Hello!

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


/WBR, Sam Fisher.

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.

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.
>
>

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

> 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

> 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?

"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