I'm writing a test program - which is used with Borland 5.6.4, CodeWarrior 8, Comeau 4.3.3, DMC++ 8.38, GCC 3.2, Intel 8.0, VC++ 6 & 7.1, VectorC 2.06 - that uses the WinSTL reg_key_sequence class. It works correctly for all compilers except DMC++.

For DMC++, the function reg_traits<> function key_dup() fails. It is defined
as:

    static hkey_type key_dup(hkey_type hkey, REGSAM samDesired =
KEY_ALL_ACCESS)
    {
        hkey_type   hkeyDup;
        ws_long_t   res = ::RegOpenKeyExA(hkey, "", 0, samDesired,
&hkeyDup);

        if(res != ERROR_SUCCESS)
        {
            hkeyDup = NULL;
        }

        return hkeyDup;
    }

    (hkey_type is HKEY)

(FYI, this technique is described in
http://www.windevnet.com/documents/win0304f/)

For some reason, with DMC++ only, the call to RegOpenKeyExA() fails, and
GetLastError return 6 (ERROR_INVALID_HANDLE).

After much jiggery pokery, I have got a work around for DMC++ that simply calls RegOpenKey(). However, this then loses the ability to specify different access rights.

Clearly, this must be a bug in DMC++'s code generation, since all exes, irrespective of compiler, use the same system library ADVAPI32.LIB.

Cheers


-- 
Matthew Wilson

Director, Synesis Software
    (www.synesis.com.au)
STLSoft moderator
    (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
    (www.synesis.com.au/articles.html#columns)

-----------------------------------------------------

Amazingly, several hours of debugging later, this is actually DMC++'s failure to properly deal with holding temporaries around when a const reference is placed on them.

The code looks like

    void iterate_recurse(reg_key_sequence::const_iterator from,
reg_key_sequence::const_iterator to, int &found, int &total)
    {
        for(; from != to; ++from)
        {
            const reg_key       &key = *from;
// The temporary '*from' is destroyed HERE!
            reg_key_sequence    keys(key);

            ++total;
            if(key.name() == "Settings")
            {
                ++found;
            }
            iterate_recurse(keys.begin(), keys.end(), found, total);

// But it should be destroyed HERE!
        }
    }

I can't remember which bit of the standard this is in, but I know for a fact it is standard C++.

The fix for the moment is to change key from a reference to a value. But this should be fixed asap, as I know several libs, e.g. loki, use it, and I use it in client code from time to time


"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c0jjmr$fci$1@digitaldaemon.com...
> I'm writing a test program - which is used with Borland 5.6.4, CodeWarrior 8, Comeau 4.3.3, DMC++ 8.38, GCC 3.2, Intel 8.0, VC++ 6 & 7.1, VectorC 2.06 - that uses the WinSTL reg_key_sequence class. It works correctly for all compilers except DMC++.
>
> For DMC++, the function reg_traits<> function key_dup() fails. It is
defined
> as:
>
>     static hkey_type key_dup(hkey_type hkey, REGSAM samDesired =
> KEY_ALL_ACCESS)
>     {
>         hkey_type   hkeyDup;
>         ws_long_t   res = ::RegOpenKeyExA(hkey, "", 0, samDesired,
> &hkeyDup);
>
>         if(res != ERROR_SUCCESS)
>         {
>             hkeyDup = NULL;
>         }
>
>         return hkeyDup;
>     }
>
>     (hkey_type is HKEY)
>
> (FYI, this technique is described in
> http://www.windevnet.com/documents/win0304f/)
>
> For some reason, with DMC++ only, the call to RegOpenKeyExA() fails, and
> GetLastError return 6 (ERROR_INVALID_HANDLE).
>
> After much jiggery pokery, I have got a work around for DMC++ that simply calls RegOpenKey(). However, this then loses the ability to specify different access rights.
>
> Clearly, this must be a bug in DMC++'s code generation, since all exes, irrespective of compiler, use the same system library ADVAPI32.LIB.
>
> Cheers
>
>
> -- 
> Matthew Wilson
>
> Director, Synesis Software
>     (www.synesis.com.au)
> STLSoft moderator
>     (http://www.stlsoft.org)
> Contributing editor, C/C++ Users Journal
>     (www.synesis.com.au/articles.html#columns)
>
> -----------------------------------------------------
>
>

That came about because of a bug fix where temporaries are supposed to be destructed at the next sequence point.

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c0jps3$og6$1@digitaldaemon.com...
> Amazingly, several hours of debugging later, this is actually DMC++'s failure to properly deal with holding temporaries around when a const reference is placed on them.
>
> The code looks like
>
>     void iterate_recurse(reg_key_sequence::const_iterator from,
> reg_key_sequence::const_iterator to, int &found, int &total)
>     {
>         for(; from != to; ++from)
>         {
>             const reg_key       &key = *from;
> // The temporary '*from' is destroyed HERE!
>             reg_key_sequence    keys(key);
>
>             ++total;
>             if(key.name() == "Settings")
>             {
>                 ++found;
>             }
>             iterate_recurse(keys.begin(), keys.end(), found, total);
>
> // But it should be destroyed HERE!
>         }
>     }
>
> I can't remember which bit of the standard this is in, but I know for a
fact
> it is standard C++.
>
> The fix for the moment is to change key from a reference to a value. But this should be fixed asap, as I know several libs, e.g. loki, use it, and
I
> use it in client code from time to time
>
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c0jjmr$fci$1@digitaldaemon.com...
> > I'm writing a test program - which is used with Borland 5.6.4,
CodeWarrior
> > 8, Comeau 4.3.3, DMC++ 8.38, GCC 3.2, Intel 8.0, VC++ 6 & 7.1, VectorC 2.06 - that uses the WinSTL reg_key_sequence class. It works correctly
for
> > all compilers except DMC++.
> >
> > For DMC++, the function reg_traits<> function key_dup() fails. It is
> defined
> > as:
> >
> >     static hkey_type key_dup(hkey_type hkey, REGSAM samDesired =
> > KEY_ALL_ACCESS)
> >     {
> >         hkey_type   hkeyDup;
> >         ws_long_t   res = ::RegOpenKeyExA(hkey, "", 0, samDesired,
> > &hkeyDup);
> >
> >         if(res != ERROR_SUCCESS)
> >         {
> >             hkeyDup = NULL;
> >         }
> >
> >         return hkeyDup;
> >     }
> >
> >     (hkey_type is HKEY)
> >
> > (FYI, this technique is described in
> > http://www.windevnet.com/documents/win0304f/)
> >
> > For some reason, with DMC++ only, the call to RegOpenKeyExA() fails, and
> > GetLastError return 6 (ERROR_INVALID_HANDLE).
> >
> > After much jiggery pokery, I have got a work around for DMC++ that
simply
> > calls RegOpenKey(). However, this then loses the ability to specify
> > different access rights.
> >
> > Clearly, this must be a bug in DMC++'s code generation, since all exes, irrespective of compiler, use the same system library ADVAPI32.LIB.
> >
> > Cheers
> >
> >
> > --
> > Matthew Wilson
> >
> > Director, Synesis Software
> >     (www.synesis.com.au)
> > STLSoft moderator
> >     (http://www.stlsoft.org)
> > Contributing editor, C/C++ Users Journal
> >     (www.synesis.com.au/articles.html#columns)
> >
> > -----------------------------------------------------
> >
> >
>
>
>

Do you mean the standard behaviour, or DMC++'s behaviour?

Is it going to be fixed for 8.39? Pretty please. :)


"Walter" <walter@digitalmars.com> wrote in message news:c0ju27$uhj$1@digitaldaemon.com...
> That came about because of a bug fix where temporaries are supposed to be destructed at the next sequence point.
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c0jps3$og6$1@digitaldaemon.com...
> > Amazingly, several hours of debugging later, this is actually DMC++'s failure to properly deal with holding temporaries around when a const reference is placed on them.
> >
> > The code looks like
> >
> >     void iterate_recurse(reg_key_sequence::const_iterator from,
> > reg_key_sequence::const_iterator to, int &found, int &total)
> >     {
> >         for(; from != to; ++from)
> >         {
> >             const reg_key       &key = *from;
> > // The temporary '*from' is destroyed HERE!
> >             reg_key_sequence    keys(key);
> >
> >             ++total;
> >             if(key.name() == "Settings")
> >             {
> >                 ++found;
> >             }
> >             iterate_recurse(keys.begin(), keys.end(), found, total);
> >
> > // But it should be destroyed HERE!
> >         }
> >     }
> >
> > I can't remember which bit of the standard this is in, but I know for a
> fact
> > it is standard C++.
> >
> > The fix for the moment is to change key from a reference to a value. But this should be fixed asap, as I know several libs, e.g. loki, use it,
and
> I
> > use it in client code from time to time
> >
> >
> > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c0jjmr$fci$1@digitaldaemon.com...
> > > I'm writing a test program - which is used with Borland 5.6.4,
> CodeWarrior
> > > 8, Comeau 4.3.3, DMC++ 8.38, GCC 3.2, Intel 8.0, VC++ 6 & 7.1, VectorC 2.06 - that uses the WinSTL reg_key_sequence class. It works correctly
> for
> > > all compilers except DMC++.
> > >
> > > For DMC++, the function reg_traits<> function key_dup() fails. It is
> > defined
> > > as:
> > >
> > >     static hkey_type key_dup(hkey_type hkey, REGSAM samDesired =
> > > KEY_ALL_ACCESS)
> > >     {
> > >         hkey_type   hkeyDup;
> > >         ws_long_t   res = ::RegOpenKeyExA(hkey, "", 0, samDesired,
> > > &hkeyDup);
> > >
> > >         if(res != ERROR_SUCCESS)
> > >         {
> > >             hkeyDup = NULL;
> > >         }
> > >
> > >         return hkeyDup;
> > >     }
> > >
> > >     (hkey_type is HKEY)
> > >
> > > (FYI, this technique is described in
> > > http://www.windevnet.com/documents/win0304f/)
> > >
> > > For some reason, with DMC++ only, the call to RegOpenKeyExA() fails,
and
> > > GetLastError return 6 (ERROR_INVALID_HANDLE).
> > >
> > > After much jiggery pokery, I have got a work around for DMC++ that
> simply
> > > calls RegOpenKey(). However, this then loses the ability to specify
> > > different access rights.
> > >
> > > Clearly, this must be a bug in DMC++'s code generation, since all
exes,
> > > irrespective of compiler, use the same system library ADVAPI32.LIB.
> > >
> > > Cheers
> > >
> > >
> > > --
> > > Matthew Wilson
> > >
> > > Director, Synesis Software
> > >     (www.synesis.com.au)
> > > STLSoft moderator
> > >     (http://www.stlsoft.org)
> > > Contributing editor, C/C++ Users Journal
> > >     (www.synesis.com.au/articles.html#columns)
> > >
> > > -----------------------------------------------------
> > >
> > >
> >
> >
> >
>
>

That's supposed to be standard behavior.

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c0ka8e$1i7d$1@digitaldaemon.com...
> Do you mean the standard behaviour, or DMC++'s behaviour?
>
> Is it going to be fixed for 8.39? Pretty please. :)
>
>
> "Walter" <walter@digitalmars.com> wrote in message news:c0ju27$uhj$1@digitaldaemon.com...
> > That came about because of a bug fix where temporaries are supposed to
be
> > destructed at the next sequence point.
> >
> > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c0jps3$og6$1@digitaldaemon.com...
> > > Amazingly, several hours of debugging later, this is actually DMC++'s failure to properly deal with holding temporaries around when a const reference is placed on them.
> > >
> > > The code looks like
> > >
> > >     void iterate_recurse(reg_key_sequence::const_iterator from,
> > > reg_key_sequence::const_iterator to, int &found, int &total)
> > >     {
> > >         for(; from != to; ++from)
> > >         {
> > >             const reg_key       &key = *from;
> > > // The temporary '*from' is destroyed HERE!
> > >             reg_key_sequence    keys(key);
> > >
> > >             ++total;
> > >             if(key.name() == "Settings")
> > >             {
> > >                 ++found;
> > >             }
> > >             iterate_recurse(keys.begin(), keys.end(), found, total);
> > >
> > > // But it should be destroyed HERE!
> > >         }
> > >     }
> > >
> > > I can't remember which bit of the standard this is in, but I know for
a
> > fact
> > > it is standard C++.
> > >
> > > The fix for the moment is to change key from a reference to a value.
But
> > > this should be fixed asap, as I know several libs, e.g. loki, use it,
> and
> > I
> > > use it in client code from time to time
> > >
> > >
> > > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c0jjmr$fci$1@digitaldaemon.com...
> > > > I'm writing a test program - which is used with Borland 5.6.4,
> > CodeWarrior
> > > > 8, Comeau 4.3.3, DMC++ 8.38, GCC 3.2, Intel 8.0, VC++ 6 & 7.1,
VectorC
> > > > 2.06 - that uses the WinSTL reg_key_sequence class. It works
correctly
> > for
> > > > all compilers except DMC++.
> > > >
> > > > For DMC++, the function reg_traits<> function key_dup() fails. It is
> > > defined
> > > > as:
> > > >
> > > >     static hkey_type key_dup(hkey_type hkey, REGSAM samDesired =
> > > > KEY_ALL_ACCESS)
> > > >     {
> > > >         hkey_type   hkeyDup;
> > > >         ws_long_t   res = ::RegOpenKeyExA(hkey, "", 0, samDesired,
> > > > &hkeyDup);
> > > >
> > > >         if(res != ERROR_SUCCESS)
> > > >         {
> > > >             hkeyDup = NULL;
> > > >         }
> > > >
> > > >         return hkeyDup;
> > > >     }
> > > >
> > > >     (hkey_type is HKEY)
> > > >
> > > > (FYI, this technique is described in
> > > > http://www.windevnet.com/documents/win0304f/)
> > > >
> > > > For some reason, with DMC++ only, the call to RegOpenKeyExA() fails,
> and
> > > > GetLastError return 6 (ERROR_INVALID_HANDLE).
> > > >
> > > > After much jiggery pokery, I have got a work around for DMC++ that
> > simply
> > > > calls RegOpenKey(). However, this then loses the ability to specify
> > > > different access rights.
> > > >
> > > > Clearly, this must be a bug in DMC++'s code generation, since all
> exes,
> > > > irrespective of compiler, use the same system library ADVAPI32.LIB.
> > > >
> > > > Cheers
> > > >
> > > >
> > > > --
> > > > Matthew Wilson
> > > >
> > > > Director, Synesis Software
> > > >     (www.synesis.com.au)
> > > > STLSoft moderator
> > > >     (http://www.stlsoft.org)
> > > > Contributing editor, C/C++ Users Journal
> > > >     (www.synesis.com.au/articles.html#columns)
> > > >
> > > > -----------------------------------------------------
> > > >
> > > >
> > >
> > >
> > >
> >
> >
>
>