Would Gcc 4.8 and 4.7 Peacefully Coexist on The Same Machine

Would GCC 4.8 and 4.7 Peacefully Coexist on the Same Machine?

First off: Yes, you can have multiple installations of gcc on your machine.

If you install gcc from the default Ubuntu repositories you can call the different versions using gcc-4.6, gcc-4.7, .... The Ubuntu toolchain test repository ubuntu-toolchain-r/test has a gcc-4.7 package. AFAIK it does not have a gcc-4.8 package yet. There exist other repositories which maintain gcc packages (even for the current 4.8 development versions; just google for ubuntu gcc repository).

Other than that you can always also compile gcc from source ( http://gcc.gnu.org/install/index.html ) and have multiple versions ( http://gcc.gnu.org/faq.html#multiple ).

GCC on Cygwin coexisting with MinGW

Psychic debugging suggests you have one or both in your global path. Take both out of your global path (gcc should yield "bad command or file name" or similar run directly from cmd.exe) and set up the shortcuts so they load the proper environment for each.

#defined bitflags and enums - peaceful coexistence in c

As others have said, your problem (a) is resolvable by using <stdint.h> and either uint32_t or uint_least32_t (if you want to worry about Burroughs mainframes which have 36-bit words). Note that MSVC does not support C99, but @DigitalRoss shows where you can obtain a suitable header to use with MSVC.

Your problem (b) is not an issue; C will type convert safely for you if it is necessary, but it probably isn't even necessary.

The area of most concern is (c) and in particular the format sub-field. There, 3 values are valid. You can handle this by allocating 3 bits and requiring that the 3-bit field is one of the values 1, 2, or 4 (any other value is invalid because of too many or too few bits set). Or you could allocate a 2-bit number, and specify that either 0 or 3 (or, if you really want to, one of 1 or 2) is invalid. The first approach uses one more bit (not currently a problem since you're only using 20 of 32 bits) but is a pure bitflag approach.

When writing function calls, there is no particular problem writing:

some_function(FORMAT_A | STORAGE_INTERNAL, ...);

This will work whether FORMAT_A is a #define or an enum (as long as you specify the enum value correctly). The called code should check whether the caller had a lapse in concentration and wrote:

some_function(FORMAT_A | FORMAT_B, ...);

But that is an internal check for the module to worry about, not a check for users of the module to worry about.

If people are going to be switching bits in the flags member around a lot, the macros for setting and unsetting the format field might be beneficial. Some might argue that any pure boolean fields barely need it, though (and I'd sympathize). It might be best to treat the flags member as opaque and provide 'functions' (or macros) to get or set all the fields. The less people can get wrong, the less will go wrong.

Consider whether using bit-fields works for you. My experience is that they lead to big code and not necessarily very efficient code; YMMV.

Hmmm...nothing very definitive here, so far.

• I would use enums for everything because those are guaranteed to be visible in a debugger where #define values are not.
• I would probably not provide macros to get or set bits, but I'm a cruel person at times.
• I would provide guidance on how to set the format part of the flags field, and might provide a macro to do that.

Like this, perhaps:

enum { ..., FORMAT_A = 0x0010, FORMAT_B = 0x0020, FORMAT_C = 0x0040, ... };
enum { FORMAT_MASK = FORMAT_A | FORMAT_B | FORMAT_C };

#define SET_FORMAT(flag, newval)    (((flag) & ~FORMAT_MASK) | (newval))
#define GET_FORMAT(flag)            ((flag) & FORMAT_MASK)

SET_FORMAT is safe if used accurately but horrid if abused. One advantage of the macros is that you could replace them with a function that validated things thoroughly if necessary; this works well if people use the macros consistently.

How to I get Python 2.x and 3.x to co-exist?

I'm not sure I understand your question, but I'll take a shot. I'm also assuming you're on Windows.

It's simple -- just install both. They will install to different directories, create different start menu folders, etc. I'd also reccomend PyWin32 for the PythonWin editor installed in both 2.7 and 3.2,

• http://sourceforge.net/projects/pywin32/files/pywin32/Build216/pywin32-216.1.win32-py3.2.exe/download &
• http://sourceforge.net/projects/pywin32/files/pywin32/Build216/pywin32-216.win32-py2.7.exe/download

If you mean how do you write one script that works with either Python 2 or Python 3, look at http://docs.python.org/library/2to3.html

In the Itanium C++ ABI, why does the mangled name for template functions not resolve dependent typedefs?

The issue comes from the <unresolved-name> construct in the ABI. Why would we ever want to use an unresolved name? It's all about declaration matching and overloads. C++14 §14.5.6.1/3 notes,

Two distinct function templates may have identical function return types and function parameter lists, even if overload resolution alone cannot distinguish them.

You can have another function in a different file,

template <typename T>
void baz(int quux) { std::abort(); }

Although this signature can't peacefully coexist in the same file — it cannot be named because of overload ambiguity — it can exist in a different file so it needs a distinct mangling.

(Even this level of coexistence is not guaranteed by the standard for all templates. It's a matter of QOI that the compiler uses the exact form of a function template declaration to perform declaration matching, so that copy-pasting a declaration into a definition will tend to provide an exact match and not a surprising conflict with another function template that resolves to the same signature. See §14.5.6.1/5-6.)

As for raining on default_order's parade, the problem is that template-ids implicitly pull default arguments from templates. So the user could unintentionally have a dependent typename in a signature just by mentioning std::set.

---

Related Topics