At 2005-07-27T14:57:48-0700, Nathaniel Smith wrote:
> Of course, we don't compile on VC++ at all ATM, so I'm not sure how
> problematic this is :-).
And if or when we do, it's likely to be VC++ 7.1 upwards--the surgery
required to work with VC++ 6.0 would probably be quite ugly. VC++ 6.0
is offic
On Wed, Jul 27, 2005 at 08:28:28AM -0500, Brian Downing wrote:
> Traditionally Visual C++ (6 at least) has had __LINE__ not expand into a
> literal number when the "Fix and Continue" debugging option is on. This
> is so all the __LINE__ references can be kept up to date as the code
> changes. Yes
On Tue, Jul 26, 2005 at 06:40:09PM -0700, Nathaniel Smith wrote:
> So we have something like
> void invert_changeset(change_set const & cs, change_set & inverted)
> {
>M(cs);
>M(inverted);
>// code goes here
> }
> very low impact, easy to convince people to sprinkle around, etc.
> Wh
On Tue, Jul 26, 2005 at 10:40:53PM +0200, Florian Weimer wrote:
> * Nathaniel Smith:
>
> > Well, yes, it's good advice. But since M _cannot_ be a non-macro,
>
> What is it doing, actually? Maybe there's a completely different way
> to get things done.
It marks a variable as "being of interest"
* Nathaniel Smith:
> Well, yes, it's good advice. But since M _cannot_ be a non-macro,
What is it doing, actually? Maybe there's a completely different way
to get things done.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.no
On Mon, Jul 25, 2005 at 11:33:49AM -0700, Steven E. Harris wrote:
> Funny, just last night I read Item 0 in /C++ Coding Standards/ by
> Sutter and Alexandrescu?:
>
> [A]lways use ONLY_UPPERCASE_NAMES for macros and never think about
> writing a macro that is a common word or abbreviation (incl
Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> writes:
> Personally, I find it pretty damn lame to use a public symbol like M
> in a public (i.e. library) header file. There's just too much
> chance someone else will us such a symbol... But I guess the C++
> community likes to forget there a