C++: Interoperability of Libraries Compiled by Different Compilers

Is it possible to link to libraries compiled with different compilers? I get asked this question a lot. Usually I ramble about this or that; I won't do that here. Rather, here's a nice concise answer from Rob K on stackoverflow. Quote:

• If the library is written in C++ and exposes a C++ interface: no (because the name-mangling differs between g++ and VC++).
• If the library is a static library written in C (or with an extern "C" interface): yes, but certain caveats apply.
• If the library is a DLL with a C interface: yes, but you'll have to create your own import library.

The above quote is specific to MinGW and Visual Studio, but in general the same rules apply between any two compilers. Speaking of MinGW, the Mixing Compiler page on MinGW's Wiki (and the older page here) also address this issue.

Here are more resources:

•  C++ Dynamic Library Compiling/Linking
• Interoperability of Libraries Created by Different Compiler Brands 
• C++: Dll compatibility between compilers 
• Importing a dll from a different compiler 
• Using C++ DLLs with different compiler versions 
• Can I link object files made by one compile to those made by another one? 
• Building Windows DLLs with MinGW 

PyDev: Workaround for the Undefined Class/Static Attribute Error

PyDev will incorrectly identify class (static) attributes as "undefined" if they are dynamically added to a class. Consider the following class:

class Quantity:
    def __init__(self, name, unit):
        self.name = name
        self.unit = unit

# Add some class/static attributes after class creation

Quantity.VOLTAGE = Quantity("Voltage", "volts")
Quantity.COUNTS = Quantity("Counts" , "counts")

Now, if we use a class attribute, such as VOLTAGE, PyDev will flag it with an "Undefined variable from import: VOLTAGE" error, even though it is valid.

print(Quantity.VOLTAGE) # <-- Flagged as an error

To work around this, add the annotation @DynamicAttrs to the class's docstring, as follows:

class Quantity:
    """ @DynamicAttrs """
    def __init__(self, name, unit):
        self.name = name
        self.unit = unit

Reference: Fabio on PyDev's user list.

Joel Spolsky's Talk on Being Number One (Business of Software)

Can be viewed here. Some main points I captured from the presentation:

• Make people happy.
• Put the user in control.
• Positive feedback.
• Obsess over aesthetics.
• Skins are not the answer.
• Modernist architecture is not the answer (decadence is still important in the software industry).
• Not the same as being pretty; capture and convey some message or theme.
• Observe the culture code.
• If necessary, define one and develop it.
• Care about it, embrace it.

Links: Some C++ Smart/Auto Pointer Implementations

QT
Standard Library (STL)

• Example
• Tutorial 

Boost

On Professionalism: Welcome to the Family

I've always maintained the necessity of creating a true, organized profession out of software development/engineering and computer science. One aspect of making that a reality is creating a unified "family". Sadly, the lack of professionalism and unified identity is keeping some from joining our profession and encouraging those already in it to leave. David Alan Grier in his article "Welcome to the Family" [1] writes:

Computer science has generally felt more comfortable with families of technology than with families of professionals.

professional life ... [involves] discipline, loyalty, competition, common knowledge. It [is not] something that [can] be turned into a desirable activity with some fun and games.  Becoming a professional means joining the family, with all the rights, responsibilities, and discipline that come with membership.

The field of computer science is defined not only by technical accomplishments but also by those who take the name of computer scientist.  As has happened in the past, and as will likely happen in the future, we are seeing both researchers and practical innovators question the value of identifying themselves with our discipline.  Their answers will largely depend on whether they think we have anything to offer them.

We might see a rise in membership if we offered vengeance for a child wronged, but we are more likely to be successful if we can offer an identity that promises a better and exciting future.

If we want to encourage others to join our profession, or those in it to remain, we most make sure he/she "finds value in our companionship."

References
[1] Grier, David Alan, "Welcome to the Family" in IEEE Computer, Volume 42, Issue 8, 2009

Cobain Backup: Example of How to Exclude Directories Using Masks

Cobain Backup is a very useful file backup tool. I have been using it for years without any problems. In general it's easy to use. However, I find its mask syntax for excluding directories and all contents in those directories a little confusing. Here's some help.

Exclude masks (or include masks):

• *\*svn\*\* - Exclude all subdirectories and files in them below any directory with a suffix of svn
  
• *\*svn\* - Exclude any files in directories with svn as a suffix
• *\*svn - Exclude empty directories with svn as its suffix
  
• Note that slash direction is important

To exclude .svn directories and all files in them:

• If empty directory pruning is enabled, two masks are required: *\*svn\*\* and *\*svn\*
• Otherwise three masks are required: *\*svn\*\* and *\*svn\* and *\*svn

Software Engineering Dead Tidbit

There has been conflicting conclusions ("take-aways" if you like) from Tom DeMaroc's article Software Engineering: An Idea Whose Time Has Come and Gone? [1]. As an example, see Jeff Atwood's blog Software Engineering: Dead? and the many comments at the end. I won't re-hash any of what was said there. But I will says this: regardless of whether SE is dead or not, we must continue to strive for the professionalism found in other engineering fields. This includes establishing best engineering practices, forming professional organizations, defining our responsibilities to the public, defining paths of entry, defining codes of ethics and enforcing them, requiring certification and/or licensing, and more.

That aside, my own tidbit from this article is the project management advice captured in these quotes:

Can I really be saying that it’s OK to run projects without control or with relatively little control? Almost. I’m suggesting that first we need to select projects where precise control won’t matter so much.

and

So, how do you manage a project without controlling it? Well, you manage the people and control the time and money.You say to your team leads, for example, “I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you have to be ready to package up and deliver what you’ve got as the final product. Your job is to go about the project incrementally, adding pieces to the whole in the order of their relative value, and doing integration and documentation and acceptance testing incrementally as you go.”

[1] Tom DeMarco, Software Engineering: An Idea Whose Time Has Come and Gone?, IEEE Software, 2009.