Bits & Bytes

Archive for December, 2010

Operator Overloading in C++ – part 1

Operator overloading in C++ is a topic that is full of confusion arising from two main sources: differences with other languages and chronic misuse. The rich and distinct structure of C++ provides the language with many features that have no counterpart in other languages. Hence, operator overloading is often seen from outside of C++ as unnecessary complexity; frequent misuse of this feature only serves to reinforce this perception. In reality, the peculiar strucure of C++ gives operator overloading a particularly powerful role in developing algorithms.

With all of the confusion surrounding operator overloading, it has frequently been refered as “syntactic sugar”–meaning that it serves to make code look nice. It may true that “a + b” is nicer looking than “sum(a, b)”, but the implications of the signature on the function that is being overloaded are far more significant.

Consider this simple bubblesort function:

template <typename PData>
void Bubblesort(PData xaArray[], int iLength) {
     for (int iEnd = iLength - 1; iEnd > 0; --iEnd) {
          for (int iIndex = 0; iIndex < iEnd; ++iIndex) {
               if (xaArray[iIndex] > xaArray[iIndex + 1]) {
                    PData xTemp  = xaArray[iIndex];
                    xaArray[iIndex]  = xaArray[iIndex + 1];
                    xaArray[iIndex + 1] = xTemp;
               }
           }
     }
}

Nevermind that this is a slow bubblesort, it could easily be any sorting algorithm. The important thing to note is that the algorithm works to sort any fundamental data type (int, double, etc.). It also works to sort any other data type that has overloaded the “>” and “=” operators.

That’s the power of operator overloading. It allows our algorithms to work on both fundamental and programmer-defined types. Better still, this algorithm uses the built-in operators for fundamental types so that no additional function call is needed for comparisons. Additionally, if we inline our overloaded operators on our programmer-defined types, we can avoid an expensive function call for comparisons on those types as well. Prior to C++ and operator overloading, C programmers used functions like qsort(), which is now in the file <cstdlib>, to sort arrays of any type of item. The declaration for qsort() looks like this:

void qsort( const void* kvpArray,
            size_t qNumberOfItems,
            size_t qItemSizeInBytes,
            int (*pfnCompareFn) ( const void *, const void *));

Notice that the last argument is a function pointer to a comparison function that is passed in. Since this is a function pointer, the comparison function cannot be inlined and that makes a quicksort in C much slower than a comparable version in C++ with operator overloading. Of course, you can get around this in C by writing a version of the sort for fundamental types and one for each new data type that you create. However, this was clearly seen as unmanageable, even by C programmers, or the qsort() function would not exist.

To be continued . . .

Tips on Making HTML Emails

For email campaigns, people usually like to send out HTML emails because they bring interest and color through their use of images and HTML coding. When done well, the emails look professional and get more click-throughs (clicking on links that you put into the email body text) than plain text emails.

However, for web developers who code HTML to display in IE 8, IE 7, Firefox, Chrome, etc., to take on coding  HTML emails is a painful, annoying, glitchy, and very old-school process. Why? Because there are over 20 mail clients generally in use today, all of which render an HTML email a little, or a lot, differently. And, most mail clients render HTML as if it were 2001. So, the important thing to remember is, code with a few caveats in mind and things will hopefully becomes more understandable and straightforward. The following list is by no means exhaustive, but I’m trying to put forth those fundamental things that helped me make consistently-rendered HTML emails.

A note on design. I admit I’m not a designer, but nevertheless this is important: use a lot of actual text in the HTML, and use the images to display pictures or design, but try to keep as much text as possible rendered as actual HTML text. If a user opens your email, but does not download the images, what will they see? If you put a lot of text into the email body, they will at least be able to read your information and then be more willing or interested to download the images, and then perhaps click through to on of your links. If your entire email is images, then unless the user clicks “download images” in their mail client, your email will greet them as a blank page which they will more likely than not just ignore and delete. And, add a background color that coordinates with the design so that if the user does not download your images, they will see a “lite” version that still has color and textual information.

The first thing to know about creating an HTML email: use tables, tables, and more tables. Years ago, web developers used tables for layout on web pages. Now, it’s a good idea to use divs and other generic containers for maximum control. However, for HTML emails, you will get more consistent renderings across all mail clients by using tables to lay out your images and text.

Second, there are quite a few tags and CSS styles that are not supported. Use as few as possible, and do not do anything too fancy, or some mail client will render the email horribly. For instance, do not use rowspan or colspan attributes in your tables–they are not supported in some clients. Do not specify a width on the <p> or <div> tag; some clients will just ignore it (like Outlook 2007)–use a <br/> tag to put hard breaks in your text.

Beware of Outlook 2007. It will not render anything in the same way as other mail clients. This is because, unlike older and some newer versions of Outlook, this version unfortunately uses the Microsoft Word engine to render the HTML. There are many things that are not supported. See Microsoft’s page on the Outlook 2007 rendering engine capabilities to see what tags and styles are supported, and to what extent.

Fourth, put all of your CSS inline. That means, put the style attribute into each tag, and don’t put styles in the head section of your HTML. Some campaign services, like Campaign Monitor, will inline all of your styles for you. To be on the safe side, inline all styles yourself.

Very importantly, use a campaign service like Campaign Monitor, MailChimp, or iContact. For a small fee, they will help you test your HTML email in many of the mail clients that are in use today, including mobile device clients. Also, they keep you on this side of the law, and usually the email they send out does not get put into the Junk folder of your recipients.

On every block element that you can, specify a height and width. This includes every image, table, tr, td, thead, and th element.

For your tables, specify cellpadding and cellspacing as zero.

For general layout, specify padding, border, and margin as zero or none on everything possible. If you need spacing, you can set it and it will usually work. What I’m referring to here is for all the elements that you do not want any spacing on. Some mail clients have spacing set on some elements by default.

One last note: on images, keep a few things in mind, such as: use the alt attribute on the <img> element, and use these CSS styles to get consistent rendering:

  • display: block;
  • border: none;
  • padding: 0px;
  • margin: 0px

And, a final note: test, test, and keep testing. It’s not good enough always to just use a service’s testing engine to see results. Send emails to yourself and your friends in different mail clients, as many as possible.

Yes, it is possible to create good HTML emails. Though it may seem mind-numbing and glitchy, the product you can get after following these rules is a beautiful, well-designed and good-acting HTML email that will get you more click-throughs.

 

© 2007–2026 XoaX.net LLC. All rights reserved.