DragonFly BSD
DragonFly commits List (threaded) for 2006-10
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: cvs commit: src/sys/arch/amd64/include pcb_ext.h reloc.h src/sys/arch/i386/acpica5 acpi_machdep.c src/sys/arch/i386/apic apic_abi.c apic_ipl.h apic_vector.s mpapic.c mpapic.h src/sys/arch/i386/apm apm.c src/sys/arch/i386/i386 autoconf.c ...

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 23 Oct 2006 15:31:59 -0700 (PDT)

:How about starting to use the #pragma once directive instead of
:regular include guards. Gcc is cabable of this as of 3.4 and it's a
:clean way to do it. Is there any particular reasons for not switching
:to this "new" directive?

    I really don't like #pragma once.  GCC has a *LOT* of crap in it that
    creates a mess out of an otherwise fairly clean language.  I try to
    avoid as much of that as I can.  It just blows my mind that GCC-4.x
    is not using an internal implementation symbol to zero out structures,
    let alone the stupidity of implementing inline functions for common
    operations without requiring them to be declared in a header file,
    and the stupidity of trying to parse printf() arguments and generate
    warnings using information that is compiled into the compiler itself
    instead of declared in a header.  There are literally four different
    varargs implementations, for reasons I cannot discern.  The number
    of hacks are just astounding.  It's best to avoid them whenever possible.
    Even if they seem to make life easier the usual result is instead to
    either allow the programmer to write sloppy code, or to create unexpected
    side effects for people trying to use the C language without linking
    against libc, or to make it impossible to port your code to other


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]