In the following example, the compiler will concatenate the two strings into a single string:

printf("This is a string " "and this is another string.");

Which is probably what you intended anyway.

Because C and C++ are free form languages, adjacent strings can appear in many different formats – as this string table shows:

char *array[] = {
    "str_1",
    "str_2",
    "str_3"
    "str_4",
    "str_5",
    NULL};

Did you notice the missing comma (,) after "str_3"? It can be a hard one to spot.

This is the type of bug that can result in something like a simple parser failing:

if (strcmp(array[i], test_string) == 0)

because str_3 and str_4 will never be matched, but the others will.

The post Programming Error – Unintended String Concatenation appeared first on Complete, Concrete, Concise.

These instructions are for WordPress 3.X that is being hosted on a web server that provides access via cPanel version 11.34.1.

The instructions may be the same or similar for other version combinations or interfaces other than cPanel, but no guarantees are made.

Possible Symptoms

You may encounter one or more of the following symptoms:

• All content and comments on your WordPress site have vanished:
  
• All content and comments show as having vanished in the dashboard:
  

• Trying to go to a particular page (that you know exists) results in an Http 404 Not Found message:

  

• You get a database connection error message:
  

Possible Cause – Corrupted Database

While it is possible that you have been hacked, it is far more likely that your WordPress database has become corrupted and is no longer able to serve up content.

I am not sure why this happens, but between November-2012 and March-2013 this has happened four times to me.

Fixing the Problem

There are two ways to fix this problem: (1) restore the database from a backup copy (preferred), (2) fix the database (only if you don’t have a backup).

Checking if the Database is Corrupted

Before doing anything rash, it is always best to check that a corrupt database is the problem.

1) Log into your web hosting account (this is not your WordPress powered website). If you web host provides a cPanel interface, it might look something like this:

2) Click on MySQL® Databases:

3) Locate the section titled Modify Databases. Select your database in the Check DB listbox and click on the Check DB button:

4) Verify whether the database has errors or not. If the database comes up without warnings or errors then you have a different problem that will not be fixed by this tutorial. If it does have warnings or errors, then the steps in this tutorial may help:

Fixing the Database

1) Click on MySQL® Databases:

2) Locate the section titled Modify Databases. Select your database in the Repair DB listbox and click on the Repair DB button:

As the database is being repaired, confirm that there are no errors. If there are errors, then run the Repair DB again (I have had to run it up to two times to repair a database):

Restoring the Database from a Backup

1) Click on Backups:

2) Locate the section called Restore a MySQL Database and click on Browse… and select the backup database from your computer. Click to upload the database.

During this process, not much may seem to be happening.

The backup database has to be uploaded from your system to your service provider.

Once it is uploaded to the service provider, the existing database is rebuilt from the uploaded one.

The whole process looks something like this:

The post WordPress – All Your Content has Vanished / Error 404 on All Pages appeared first on Complete, Concrete, Concise.

I am probably one of the few, if only people around who use w.bloggar for my blogging needs. While it is an old and outdated program, it has three essential features for me: (1) customizable edit keys (that’s how I input these coloured sections without typing in HTML code), (2) it is easy to upload images and (3) it doesn’t add bloat to the images (the images I upload are in no way, shape, or form modified by w.bloggar).

For most people, though, I would still recommend Windows Live Writer.

A few days ago, I began having problems with w.bloggar when trying to post or upload images. It would return the message: “Unable to parse the XML response.Parser Reason:Invalid at the top level”:

At first, I thought it was something funny happening at the server end of this site. I figured it would go away in a few hours. It didn’t.

Then I tried using Windows Live Writer. It worked.

Then I created a new account in w.bloggar through File -> Add Account…. This solved the problem.

For some reason, my original blog account info / setup / configuration has gone wonky. Creating a new account clears up the problem. (Of course, I still have the bother of recustomizing w.bloggar to my tastes again)

The post w.bloggar – How to Fix "Unable to parse the XML response" Error appeared first on Complete, Concrete, Concise.

Purpose

The #error directive terminates compilation and outputs the text following the directive.

Format

#error text

All preprocessor directives begin with the # symbol. It must be the first character on the line or the first character on the line following optional white space.

Spaces or tabs are permitted between the # and error, but not escape characters or other symbols or macros. The preprocessor removes white space and concatenates the # and error together.

If anything follows the #error directive (other than white space) then the program is malformed.

The following are valid uses:

#error some error message text
# error some error text to display
# /* comments are white space */ error some error message to display

The following are invalid uses:

// #\ is not a valid preprocessor directive
# \t error text to output
// #" is not a valid preprocessor directive
# "" text to output

Use

It is used to render a program malformed and output the text following the #error directive. The text may be quoted or unquoted (it doesn’t matter). No macro expansion takes place.

There are many times when it is useful to halt compilation:

1. code is incomplete
2. code requires particular library versions
3. code uses compiler dependent features
4. code has specific compiler requirements

Incomplete Code

When developing code, it is common to create stub functions. For the final release, these stub functions need to be implemented. We can let the compiler help us catch unimplemented functions:

int my_function( void )
{
 #error my_function not implemented
 return 0;
}

The above code will fail for every compile. It might be more useful to allow compiling during development, but break the compile when we try to compile a release version. In the following example, we assume that during development, the macro DEBUG is defined:

int my_function( void )
{
#ifndef DEBUG
 #error my_function not implemented
#endif
 return 0;
}

During development, we can compile the code, but when we do a release build (one in which DEBUG is not defined, then we catch unimplemented functions.

Version Checking

Sometimes code is dependent on particular versions of a library. It is useful to be able to stop compilation if an incorrect library version is included:

#if library_version < 2
#error requires library_version 2 or better
#endif

Compiler Dependency

Sometimes, code uses compiler specific features (for example, GCC allows nesting a #define within another #define – this is a non-standard compiler feature).

#ifdef __GCC__
// some GCC specific code goes here
#else
#error requires GCC compiler to compile
#endif

Compiler Requirements

Sometimes code makes relies on certain assumptions about the target environment (for example, the size of an integer):

#include 
#if UINT_MAX != 4294967295
 #error this application requires 32 bit integers
#endif

The post Preprocessor – the #error Directive appeared first on Complete, Concrete, Concise.

Macros are a simple text substitution done by the preprocessor. Whenever the macro name is encountered in your code, the preprocessor replaces it with the text to the right of the macro name (plugging in any optional parameters you may have passed).

A macro is composed of three parts:

1. #define – this introduces the macro
2. macro name and optional parameter list. The macro name cannot have any spaces and the parameter list cannot be separated from the macro name with any spaces.
3. text that will replace the macro – everything following the macro name (and optional parameter list), until the end of the line, is what the preprocessor will use to replace the macro name. For long macros, or for better formatting, the macro can be defined over several lines by ending each line with a backslash character (\) and a new line (enter) (extra spaces between the backslash character and new line means the macro ends there – so be careful of extra spaces following the backslash).

Working Examples:

#define my_macro // preprocessor will replace my_macro with this comment.

#define my_macro // when the preprocessor encounters my_macro, \
                    it will replace it with everything on this \
                    line that is to the right of the definition \
                    (which is this comment). Fortunately, \
                    it is possible to spread the line over several \
                    lines by using the backslash character

Not Working Examples:

The following macro won’t compile following expansion (it is supposed to replace the macro with the contents of the parameter list):

The (unhelpful but correct) error message from the compiler (GCC v.4.4.1) is:

The problem is the space between the macro name and the parameter list – there should be none.

Here’s another macro that won’t compile (like the one above, it is supposed to replace the macro with the parameters passed) :

The (unhelpful but correct) from the compiler (GCC v.4.4.1) is:

Again, the problem is a space between the macro name and the parameter list. Removing the space fixes the problem.

The post Compilation Error – Improperly Defined Macro appeared first on Complete, Concrete, Concise.

This is useful in functions when we don’t know in advance how large the array should be or if we want to allocate the array in the heap instead of the stack (the equivalent in C would be to use malloc() or calloc() to allocate the array)

A common programming error (because it looks very similar and is perfectly valid) is to replace the [] with ().

In this case, we have allocated a single char and initialized its value to 50 – which is not what was intended.

This leads to those hard to track down bugs of corrupted data and / or random crashes.

NOTE: when freeing an array created with new, remember to call delete[] instead of delete to avoid memory leaks (and definitely never call free())

The post Programming Error – Incorrect Array Declaration appeared first on Complete, Concrete, Concise.