bzr 1.14 release schedule and manager

[Tom Widmer]

John Arbash Meinel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Alexander Belchenko wrote:
>> John Arbash Meinel пишет:
>>>> c:\work\Bazaar\mydev.packs\brisbane-core\bzrlib\delta.h(87) : error
>>>> C2054: expected '(' to follow 'inline'
>>> It sounds like we just need to remove the "inline" statement. Can you
>>> try removing that and see if it still compiles? I don't think this
>>> particular code is performance critical enough that we *need* inline.
>> Yes, this helps.
>> IIUC, inline it's C99 extension, but MSVC understand C89 only.
> 
> Well, I think MSVC uses something like __inline, or maybe _inline, or
> some other directive to handle it. I know it *does* support it, just not
> like GCC. :(
> 
> Anyway, I went ahead and removed the 'inline' declaration, and also
> removed 'const' because that was causing compiler warnings. I don't
> really understand why:
> 
> 
> void my_func(const unsigned char **bar)
> {
> }
> 
> void other()
> {
>   unsigned char *foo = "some stuff";
> 
>   my_func(&foo);
> }
> 
> 
> complains about 'const' issues. Since under normal circumstances an
> 'unsigned char *' can be freely sent to a 'const unsigned char*'. I
> guess I'll chalk it up to compilers being stupid, but if someone has
> better info, I'm listening.

The compiler is right (and it is logical). See 
http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.17.
http://c-faq.com/ansi/constmismatch.html
	
> 
> I also know there is something about the difference between:
> 
> const unsigned char *
> 
> and
> 
> unsigned char const *

No, they are the same.

> Especially versus
> 
> unsigned char const * const *

That is different.

> Which I believe is the correct way to say that you have a pointer you
> shouldn't modify pointing to data you shouldn't modify.

That's a modifiable pointer to a non-modifiable pointer to 
non-modifiable data.

> What we want is a pointer that we can assign to, which references data
> that we shouldn't assign to. For which "const unsigned char **" seems to
> work, as would "unsigned char const **". But it seems to think that
> "&(unsigned char*)" is not valid for... :(

If you read http://www.parashift.com/c++-faq-lite/const-correctness.html 
you'll know everything you need to know about const in C++. C should be 
much the same.

Tom