On 12/15/2011 03:20 AM, Avi Kivity wrote:
On 12/14/2011 07:55 PM, Stefan Weil wrote:
Would 's' instead of '_' work?
struct sCamelCase;
typedef struct sCamelCase {
// ...
} CamelCase;
It does not violate any standard...
Would '' instead of 's' work?
typedes struct CamelCase {
...
}
On 12/14/2011 07:55 PM, Stefan Weil wrote:
>
>
> Would 's' instead of '_' work?
>
> struct sCamelCase;
>
> typedef struct sCamelCase {
> // ...
> } CamelCase;
>
> It does not violate any standard...
Would '' instead of 's' work?
typedes struct CamelCase {
...
} CamelCase;
--
error compilin
On 12/14/2011 04:23 PM, Stefan Weil wrote:
Am 14.12.2011 22:51, schrieb Anthony Liguori:
Look carefully at:
http://qemu.weilnetz.de/gtkdoc/QEMU-Memory-API.html#MemoryRegionOps
vs:
http://wiki.qemu.org/docs-internal/QEMU-Memory-API.html#MemoryRegionOps
There's a significant difference :-)
R
Am 14.12.2011 22:51, schrieb Anthony Liguori:
Look carefully at:
http://qemu.weilnetz.de/gtkdoc/QEMU-Memory-API.html#MemoryRegionOps
vs:
http://wiki.qemu.org/docs-internal/QEMU-Memory-API.html#MemoryRegionOps
There's a significant difference :-)
Regards,
Anthony Liguori
I tried the follo
On 12/14/2011 03:26 PM, Stefan Weil wrote:
Am 14.12.2011 21:54, schrieb Anthony Liguori:
On 12/14/2011 02:48 PM, Stefan Weil wrote:
Am 14.12.2011 20:03, schrieb Anthony Liguori:
On 12/14/2011 12:54 PM, Stefan Weil wrote:
Am 14.12.2011 17:34, schrieb malc:
On Wed, 14 Dec 2011, Anthony Liguori
Am 14.12.2011 21:54, schrieb Anthony Liguori:
On 12/14/2011 02:48 PM, Stefan Weil wrote:
Am 14.12.2011 20:03, schrieb Anthony Liguori:
On 12/14/2011 12:54 PM, Stefan Weil wrote:
Am 14.12.2011 17:34, schrieb malc:
On Wed, 14 Dec 2011, Anthony Liguori wrote:
GTK/glib uses a convenient of:
ty
On 12/14/2011 02:48 PM, Stefan Weil wrote:
Am 14.12.2011 20:03, schrieb Anthony Liguori:
On 12/14/2011 12:54 PM, Stefan Weil wrote:
Am 14.12.2011 17:34, schrieb malc:
On Wed, 14 Dec 2011, Anthony Liguori wrote:
GTK/glib uses a convenient of:
typedef struct _CamelCase CamelCase;
The reason
On 12/14/2011 02:23 PM, Eric Blake wrote:
On 12/14/2011 11:54 AM, Stefan Weil wrote:
It does violate the standard _ followed by upper case letter is reserved
in all contexts.
sCamelCase instead of _CamelCase seems to work, too.
What about _camelCase instead of _CamelCase? That preserves the
Am 14.12.2011 20:03, schrieb Anthony Liguori:
On 12/14/2011 12:54 PM, Stefan Weil wrote:
Am 14.12.2011 17:34, schrieb malc:
On Wed, 14 Dec 2011, Anthony Liguori wrote:
GTK/glib uses a convenient of:
typedef struct _CamelCase CamelCase;
The reason that they use a separate struct name is that
On Wed, 14 Dec 2011, Eric Blake wrote:
> On 12/14/2011 11:54 AM, Stefan Weil wrote:
> >> It does violate the standard _ followed by upper case letter is reserved
> >> in all contexts.
> >
> > sCamelCase instead of _CamelCase seems to work, too.
>
> What about _camelCase instead of _CamelCase? T
On 12/14/2011 11:54 AM, Stefan Weil wrote:
>> It does violate the standard _ followed by upper case letter is reserved
>> in all contexts.
>
> sCamelCase instead of _CamelCase seems to work, too.
What about _camelCase instead of _CamelCase? That preserves the leading
underscore, but no longer us
Am 14.12.2011 17:34, schrieb malc:
On Wed, 14 Dec 2011, Anthony Liguori wrote:
GTK/glib uses a convenient of:
typedef struct _CamelCase CamelCase;
The reason that they use a separate struct name is that in C++, the
struct
namespace not a separate namespace from the type namespace. This is
a
On 12/14/2011 12:54 PM, Stefan Weil wrote:
Am 14.12.2011 17:34, schrieb malc:
On Wed, 14 Dec 2011, Anthony Liguori wrote:
GTK/glib uses a convenient of:
typedef struct _CamelCase CamelCase;
The reason that they use a separate struct name is that in C++, the struct
namespace not a separate na
On 12/14/2011 11:26 AM, Peter Maydell wrote:
On 14 December 2011 17:19, Anthony Liguori wrote:
If you have a better suggestion, I'm all for it.
Shrug. I'm not sure what problem you're solving here.
To introduce the infrastructure such that we can have high quality internal
documentation su
Am 14.12.2011 18:19, schrieb Anthony Liguori:
On 12/14/2011 11:11 AM, Peter Maydell wrote:
On 14 December 2011 16:55, Anthony Liguori
wrote:
I think in this case, we're just going to have to deviate from the
standard.
The benefit is great, the practice is widespread, and there's no
immediate
On 14 December 2011 17:19, Anthony Liguori wrote:
> If you have a better suggestion, I'm all for it.
Shrug. I'm not sure what problem you're solving here. The bits
of QEMU that are the worst to understand are the ones which aren't
documented at all, and the bits where the general structure and
un
On 12/14/2011 11:11 AM, Peter Maydell wrote:
On 14 December 2011 16:55, Anthony Liguori wrote:
I think in this case, we're just going to have to deviate from the standard.
The benefit is great, the practice is widespread, and there's no immediate
likelihood of changing glib's coding style pract
On 14 December 2011 16:55, Anthony Liguori wrote:
> I think in this case, we're just going to have to deviate from the standard.
> The benefit is great, the practice is widespread, and there's no immediate
> likelihood of changing glib's coding style practices.
>
> I still think we should adhere t
On 12/14/2011 10:34 AM, malc wrote:
On Wed, 14 Dec 2011, Anthony Liguori wrote:
GTK/glib uses a convenient of:
typedef struct _CamelCase CamelCase;
The reason that they use a separate struct name is that in C++, the struct
namespace not a separate namespace from the type namespace. This
On Wed, 14 Dec 2011, Anthony Liguori wrote:
> GTK/glib uses a convenient of:
>
> typedef struct _CamelCase CamelCase;
>
> The reason that they use a separate struct name is that in C++, the struct
> namespace not a separate namespace from the type namespace. This is actually
> a
> reasonab
GTK/glib uses a convenient of:
typedef struct _CamelCase CamelCase;
The reason that they use a separate struct name is that in C++, the struct
namespace not a separate namespace from the type namespace. This is actually a
reasonable policy for QEMU to adopt as we eventually start exporting C
21 matches
Mail list logo