Wednesday, May 29, 2024
05:44 PM (GMT +5)

Go Back   CSS Forums > CSS Optional subjects > Group I > Computer Science

Reply Share Thread: Submit Thread to Facebook Facebook     Submit Thread to Twitter Twitter     Submit Thread to Google+ Google+    
LinkBack Thread Tools Search this Thread
Old Wednesday, August 31, 2005
Medal of Appreciation: Awarded to appreciate member's contribution on forum. (Academic and professional achievements do not make you eligible for this medal) - Issue reason: Appreciation
Join Date: Jul 2005
Posts: 1,221
Thanks: 349
Thanked 428 Times in 261 Posts
sibgakhan is a jewel in the roughsibgakhan is a jewel in the roughsibgakhan is a jewel in the roughsibgakhan is a jewel in the rough
Post C++ portability guide

C++ portability guide
version 0.8
originally by David Williams, 27 March 1998

Updated and maintained by Scott Collins, Christopher Blizzard, and David Baron

What follows is a set of rules, guidelines, and tips that we have found to be useful in making C++ code portable across many machines and compilers.

This information is the result of porting large amounts of code across about 25 different machines, and at least a dozen different C++ compilers. Some of these things will frustrate you and make you want to throw your hands up and say, ``well, that's just a stupid compiler if it doesn't do <insert favorite C++ feature>.'' But this is the reality of portable code. If you play by the rules, your code will seamlessly work on all of the Mozilla platforms and will be easy to port to newer machines.

We will endeavor to keep the information up to date (for example, sometimes a new compiler revision will lift a restriction). If you have updates on any of these tips, more information, more ideas, please forward them to Christopher Blizzard, Scott Collins, or David Baron.

If you find code in Mozilla that violates any of these rules, please report it as a bug. You can use bonsai to find the author.

None of these rules is absolute. If patch authors can demonstrate that what they want to do works on all the compilers we support, they're welcome to break, and revise, these rules. However, this is a lot of work, and is not recommended unless you have a very good reason for wanting to do it.


C++ portability rules.
Be very careful when writing C++ templates. Don't use static constructors. Don't use exceptions. Don't use Run-time Type Information. Don't use C++ standard library features, including iostream Don't use namespace facility. main() must be in a C++ file. Use the common denominator between members of a C/C++ compiler family. Don't put C++ comments in C code. Don't put carriage returns in XP code. Put a new line at end-of-file. Don't put extra top-level semi-colons in code. C++ filename extension is .cpp. Don't mix varargs and inlines. Don't use initializer lists with objects. Always have a default constructor. Be careful with inner (nested) classes. Be careful of variable declarations that require construction or initialization. Make header files compatible with C and C++. Be careful of the scoping of variables declared inside for() statements. Declare local initialized aggregates as static. Expect complex inlines to be non-portable. Don't use return statements that have an inline function in the return expression. Be careful with the include depth of files and file size. Use virtual declaration on all subclass virtual member functions. Always declare a copy constructor and assignment operator. Be careful of overloaded methods with like signatures. Type scalar constants to avoid unexpected ambiguities. Always use PRBool for boolean variables in XP code. Use macros for C++ style casts. Don't use mutable. Use nsCOMPtr in XPCOM code. Don't use reserved words as identifiers.
Stuff that is good to do for C or C++.
Always use the nspr types for intrinsic types. Do not wrap include statements with an #ifdef. #include statements should include only simple filenames. Macs complain about assignments in boolean expressions. Every source file must have a unique name. Use #if 0 rather than comments to temporarily kill blocks of code. Turn on warnings for your compiler, and then write warning free code.

Revision History.

Further Reading.


C++ portability rules.
Be very careful when writing C++ templates.

Don't use C++ templates unless you do only things already known to be portable because they are already used in Mozilla (such as patterns used by nsCOMPtr or CallQueryInterface) or are willing to test your code carefully on all of the compilers we support and be willing to back it out if it breaks.

Don't use static constructors.

Non-portable example:

FooBarClass static_object(87, 92);

if (static_object.count > 15) {

Static constructors don't work reliably either. A static initialized object is an object which is instanciated at startup time (just before main() is called). Usually there are two components to these objects. First there is the data segment which is static data loaded into the global data segment of the program. The second part is a initializer function that is called by the loader before main() is called. We've found that many compilers do not reliably implement the initializer function. So you get the object data, but it is never initialized. One workaround for this limitation is to write a wrapper function that creates a single instance of an object, and replace all references to the static initialized object with a call to the wrapper function:
Portable example:

static FooBarClass* static_object;

if (!static_object)
static_object =
new FooBarClass(87, 92);
return static_object;

if (getStaticObject()->count > 15) {

Don't use exceptions.

Exceptions are another C++ feature which is not very widely implemented, and as such, their use is not portable C++ code. Don't use them. Unfortunately, there is no good workaround that produces similar functionality.

One exception to this rule (don't say it) is that it's probably ok, and may be necessary to use exceptions in some machine specific code. If you do use exceptions in machine specific code you must catch all exceptions there because you can't throw the exception across XP (cross platform) code.

Don't use Run-time Type Information.

Run-time type information (RTTI) is a relatively new C++ feature, and not supported in many compilers. Don't use it.

If you need runtime typing, you can achieve a similar result by adding a classOf() virtual member function to the base class of your hierarchy and overriding that member function in each subclass. If classOf() returns a unique value for each class in the hierarchy, you'll be able to do type comparisons at runtime.

Don't use C++ standard library features, including iostream

Using C++ standard library features involves significant portability problems because newer compilers require the use of namespaces and of headers without .h, whereas older compilers require the opposite. This includes iostream features, such as cin and cout.

Furthermore, using the C++ standard library imposes difficulties on those attempting to use Mozilla on small devices.

There is one exception to this rule: it is acceptable to use placement new. To use it, include the standard header <new> by writing #include NEW_H.

Don't use namespace facility.

Support of namespaces (through the namespace and using keywords) is a relatively new C++ feature, and not supported in many compilers. Don't use it.

main() must be in a C++ file.

The first C++ compiler, Cfront, was in fact a very fancy preprocessor for a C compiler. Cfront reads the C++ code, and generates C code that would do the same thing. C++ and C startup sequences are different (for example static constructor functions must be called for C++), and Cfront implements this special startup by noticing the function called "main()", converting it to something else (like "__cpp__main()"), adding another main() that does the special C++ startup things and then calls the original function. Of course for all this to work, Cfront needs to see the main() function, hence main() must be in a C++ file. Most compilers lifted this restriction years ago, and deal with the C++ special initialization duties as a linker issue. But there are a few commercial compilers shipping that are still based on Cfront: HP, and SCO, are examples.

So the workaround is quite simple. Make sure that main() is in a C++ file. On the Unix version of Mozilla, we did this by adding a new C++ file which has only a few lines of code, and calls the main main() which is actually in a C file.

Use the common denominator between members of a C/C++ compiler family.

For many of the compiler families we use, the implementation of the C and C++ compilers are completely different, sometimes this means that there are things you can do in the C language, that you cannot do in the C++ language on the same machine. One example is the 'long long' type. On some systems (IBM's compiler used to be one, but I think it's better now), the C compiler supports long long, while the C++ compiler does not. This can make porting a pain, as often times these types are in header files shared between C and C++ files. The only thing you can do is to go with the common denominator that both compilers support. In the special case of long long, we developed a set of macros for supporting 64 bit integers when the long long type is not available. We have to use these macros if either the C or the C++ compiler does not support the special 64 bit type.

Don't put C++ comments in C code.

The quickest way to raise the blood pressure of a Netscape Unix engineer is to put C++ comments (// comments) into C files. Yes, this might work on your Microsoft Visual C compiler, but it's wrong, and is not supported by the vast majority of C compilers in the world. Just do not go there.

Many header files will be included by C files and included by C++ files. We think it's a good idea to apply this same rule to those headers. Don't put C++ comments in header files included in C files. You might argue that you could use C++ style comments inside #ifdef __cplusplus blocks, but we are not convinced that is always going to work (some compilers have weird interactions between comment stripping and pre-processing), and it hardly seems worth the effort. Just stick to C style /**/ comments for any header file that is ever likely to be included by a C file.

Don't put carriage returns in XP code.

While this is not specific to C++, we have seen this as more of an issue with C++ compilers, see Use the common denominator between members of a C/C++ compiler family. In particular, it causes bustage on at least the IRIX native compiler.

On unix systems, the standard end of line character is line feed ('\n'). The standard on many PC editors is carriage return and line feed ("\r\n"), while the standard on Mac is carriage return ("\r"). The PC compilers seem to be happy either way, but some Unix compilers just choke when they see a carriage return (they do not recognize the character as white space). So, we have a rule that you cannot check in carriage returns into any cross platform code. This rule is not enforced on the Windows front end code, as that code is only ever compiled on a PC. The Mac compilers seem to be happy either way, but the same rule applies as for the PC - no carriage returns in cross platform code.

MacCVS, WinCVS, and cygwin CVS when configured to use DOS line endings automatically convert to and from platform line endings, so you don't need to worry. However, if you use cygwin CVS configured for Unix line endings, or command line cvs on Mac OS X, you need to be somewhat careful.

Put a new line at end-of-file.

Not having a new-line char at the end of file breaks .h files with the Sun WorkShop compiler and it breaks .cpp files on HP.

Don't put extra top-level semi-colons in code.

Non-portable example:


This is another problem that seems to show up more on C++ than C code. This problem is really a bit of a drag. That extra little semi-colon at the end of the function is ignored by most compilers, but it is not permitted by the standard and it makes some compilers report errors (in particular, gcc 3.4, and also perhaps old versions of the AIX native compiler). Don't do it.
Portable example:


C++ filename extension is .cpp.

This one is another plain annoying problem. What's the name of a C++ file? file.cpp,, file.C, file.cxx, file.c++, file.C++? Most compilers could care less, but some are very particular. We have not been able to find one file extension which we can use on all the platforms we have ported Mozilla code to. For no great reason, we've settled on file.cpp, probably because the first C++ code in Mozilla code was checked in with that extension. Well, it's done. The extension we use is .cpp. This extension seems to make most compilers happy, but there are some which do not like it. On those systems we have to create a wrapper for the compiler (see STRICT_CPLUSPLUS_SUFFIX in ns/config/ and ns/build/*), which actually copies the file.cpp file to another file with the correct extension, compiles the new file, then deletes it. If in porting to a new system, you have to do something like this, make sure you use the #line directive so that the compiler generates debug information relative to the original .cpp file.

Don't mix varargs and inlines.

Non-portable example:

class FooBar {
void va_inline(char* p, ...) {
// something

The subject says it all, varargs and inline functions do not seem to mix very well. If you must use varargs (which can cause portability problems on their own), then ensure that the vararg member function is a non-inline function.
Portable example:

// foobar.h
class FooBar {
va_non_inline(char* p, ...);

// foobar.cpp
FooBar::va_non_inline(char* p, ...)
// something

Don't use initializer lists with objects.

Non-portable example:

FooClass myFoo = {10, 20};

Some compilers won't allow this syntax for objects (HP-UX won't), actually only some will allow it. So don't do it. Again, use a wrapper function, see Don't use static constructors.
Always have a default constructor.

Always have a default constructor, even if it doesn't make sense in terms of the object structure/hierarchy. HP-UX will barf on statically initialized objects that don't have default constructors.

Be careful with inner (nested) classes.

When using nested classes, be careful with access control. While most compilers implement (whether intentionally or not) the rules in the 2003 version of the C++ standard that give nested classes special access to the members of their enclosing class, some compilers implement what is described in the 1998 version of the standard, which is that nested classes have no special access to members of their enclosing class.

Non-portable example:

class Enclosing {
int x;
struct Nested {
void do_something(Enclosing *E) {

portable example:

class Enclosing {
int x;
struct Nested; // forward declare |Nested| so the |friend|
// declaration knows what scope it's in.
friend struct Nested; // make |Nested| a friend of its enclosing
// class
struct Nested {
void do_something(Enclosing *E) {

A second non-portable example:

class Enclosing {
struct B;
struct A {
B *mB;
struct B {
A *mA;

and the equivalent portable example:

class Enclosing {
struct A;
friend struct A;
struct B;
friend struct B;
struct A {
B *mB;
struct B {
A *mA;

Be careful of variable declarations that require construction or initialization.

Non-portable example:

A::foo(int c)
switch(c) {
case FOOBAR_1:
XyzClass buf(100);
// stuff

Be careful with variable placement around if blocks and switch statements. Some compilers (HP-UX) require that any variable requiring a constructor/initializer to be run, needs to be at the start of the method -- it won't compile code when a variable is declared inside a switch statement and needs a default constructor to run.
Portable example:

A::foo(int c)
XyzClass buf(100);

switch(c) {
case FOOBAR_1:
// stuff

Make header files compatible with C and C++.

Non-portable example:

int existingCfunction(char*);
int anotherExistingCfunction(char*);

/* oldCfile.c */
#include "oldCheader.h"

// new file.cpp
extern "C" {
#include "oldCheader.h"

If you make new header files with exposed C interfaces, make the header files work correctly when they are included by both C and C++ files. If you start including an existing C header in new C++ files, fix the C header file to support C++ (as well as C), don't just extern "C" {} the old header file. Do this:
Portable example:

int existingCfunction(char*);
int anotherExistingCfunction(char*);

/* oldCfile.c */
#include "oldCheader.h"

// new file.cpp
#include "oldCheader.h"

There are number of reasons for doing this, other than just good style. For one thing, you are making life easier for everyone else, doing the work in one common place (the header file) instead of all the C++ files that include it. Also, by making the C header safe for C++, you document that "hey, this file is now being included in C++". That's a good thing. You also avoid a big portability nightmare that is nasty to fix...
Some systems include C++ in system header files that are designed to be included by C or C++. Not just extern "C" {} guarding, but actual C++ code, usually in the form of inline functions that serve as "optimizations". While we question the wisdom of vendors doing this, there is nothing we can do about it. Changing system header files, is not a path we wish to take. Anyway, so why is this a problem? Take for example the following code fragment:

Non-portable example:

#ifdef __cplusplus
/* optimization */
inline int sqr(int x) {return(x*x);}

#include <system.h>
int existingCfunction(char*);

// file.cpp
extern "C" {
#include "header.h"

What's going to happen? When the C++ compiler finds the extern "C" declaration in file.cpp, it will switch dialects to C, because it's assumed all the code inside is C code, and C's type free name rules need to be applied. But the __cplusplus pre-processor macro is still defined (that's seen by the pre-processor, not the compiler). In the system header file the C++ code inside the #ifdef __cplusplus block will be seen by the compiler (now running in C mode). Syntax Errors galore! If instead the extern "C" was done in the header file, the C functions can be correctly guarded, leaving the systems header file out of the equation. This works:
Portable example:

#ifdef __cplusplus
/* optimization */
inline int sqr(int x) {return(x*x);}

#include <system.h>
extern "C" {
int existingCfunction(char*);

// file.cpp
#include "header.h"

One more thing before we leave the extern "C" segment of the program. Sometimes you're going to have to extern "C" system files. This is because you need to include C system header files that do not have extern "C" guarding themselves. Most vendors have updated all their headers to support C++, but there are still a few out there that won't grok C++. You might have to do this only for some platforms, not for others (using #ifdef SYSTEM_X). The safest place to do extern "C" a system header file (in fact the safest place to include a system header file) is at the lowest place possible in the header file inclusion hierarchy. That is, push all this stuff down to the header files closer to the system code, don't do this stuff in the mail header files. Ideally the best place to do this is in the NSPR or XP header files - which sit directly on the system code.
Be careful of the scoping of variables declared inside for() statements.

Non-portable example:

for (int i = 0; i < 10; i++) {
// do something
// i might get referenced
// after the loop.

This is actually an issue that comes about because the C++ standard has changed over time. The original C++ specification would scope the i as part of the outer block (in this case function A::foo()). The standard changed so that now the i in is scoped within the for() {} block. Most compilers use the new standard. Some compilers (for example, Microsoft Visual C++ when used without an option supported only in newer versions, or the HP-UX compiler when used without a compiler option that we use) still use the old standard. It's probably better to be on the safe side and declare the iterator variable outside of the for() loop in functions that are longer than a few lines. Then you'll know what you are getting on all platforms:
Portable example:

int i;
for (i = 0; i < 10; i++) {
// do something
// i might get referenced
// after the loop.

Also you should not reuse a for loop variable in subsequent for loops or otherwise redeclare the variable. This is permitted by the current standard, but many compilers will treat this as an error. See the example below:
Non-portable example:

for (int i; 0 {
// do something
for (int i; 0 {
// do something else

Portable example:

for (int i; 0 {
// do something
for (int j; 0 {
// do something else

Declare local initialized aggregates as static.

Non-portable example:

A:: func_foo()
char* foo_int[] = {"1", "2", "C"};

This seemingly innocent piece of code will generate a "loader error" using the HP-UX compiler/linker. If you really meant for the array to be static data, say so:
Portable example:

A:: func_foo()
static char *foo_int[] = {"1", "2", "C"};

Otherwise you can keep the array as an automatic, and initialize by hand:
Portable example:

A:: func_foo()
char *foo_int[3];

foo_int[0] = XP_STRDUP("1");
foo_int[1] = XP_STRDUP("2");
foo_int[2] = XP_STRDUP("C");
// or something equally Byzantine...

Expect complex inlines to be non-portable.

Non-portable example:

class FooClass {
int fooMethod(char* p) {
if (p[0] == '\0')
return -1;

return 0;

It's surprising, but many C++ compilers do a very bad job of handling inline member functions. Cfront based compilers (like those on SCO and HP-UX) are prone to give up on all but the most simple inline functions, with the error message "sorry, unimplemented". Often times the source of this problem is an inline with multiple return statements. The fix for this is to resolve the returns into a single point at the end of the function. But there are other constructs which will result in "not implemented". For this reason, you'll see that most of the C++ code in Mozilla does not use inline functions. We don't want to legislate inline functions away, but you should be aware that there is some danger in using them, so do so only when there is some measurable gain (not just a random hope of performance win). Maybe you should just not go there.
Portable example:

class FooClass {
int fooMethod(char* p) {
int return_value;

if (p[0] == '\0') {
return_value = -1;
} else {
return_value = 0;
return return_value;

Portable example:

class FooClass {
int fooMethod(char* p);

int FooClass::fooMethod(char* p)
if (p[0] == '\0')
return -1;

return 0;

Don't use return statements that have an inline function in the return expression.

For the same reason as the previous tip, don't use return statements that have an inline function in the return expression. You'll get that same "sorry, unimplemented" error. Store the return value in a temporary, then pass that back.

Be careful with the include depth of files and file size.

Be careful with the include depth of files and file size. The Microsoft Visual C++1.5 compiler will generate internal compiler errors if you have a large include depth or large file size. Be careful to limit the include depth of your header files as well as your file size.

Use virtual declaration on all subclass virtual member functions.

Non-portable example:

class A {
virtual void foobar(char*);

class B : public A {
void foobar(char*);

Another drag. In the class declarations above, A::foobar() is declared as virtual. C++ says that all implementations of void foobar(char*) in subclasses will also be virtual (once virtual, always virtual). This code is really fine, but some compilers want the virtual declaration also used on overloaded functions of the virtual in subclasses. If you don't do it, you get warnings. While this is not a hard error, because this stuff tends to be in headers files, you'll get so many warnings that's you'll go nuts. Better to silence the compiler warnings, by including the virtual declaration in the subclasses. It's also better documentation:
Portable example:

class A {
virtual void foobar(char*);

class B : public A {
virtual void foobar(char*);

Always declare a copy constructor and assignment operator.

One feature of C++ that can be problematic is the use of copy constructors. Because a class's copy constructor defines what it means to pass and return objects by value (or if you prefer, pass by value means call the copy constructor), it's important to get this right. There are times when the compiler will silently generate a call to a copy constructor, that maybe you do not want. For example, when you pass an object by value as a function parameter, a temporary copy is made, which gets passed, then destroyed on return from the function. Maybe you don't want this to happen, maybe you'd always like instances of your class to be passed by reference. If you do not define a copy constructor the C++ compiler will generate one for you (the default copy constructor), and this automatically generated copy constructor might, well, suck. So you have a situation where the compiler is going to silently generate calls to a piece of code that might not be the greatest code for the job (it may be wrong).

Ok, you say, "no problem, I know when I'm calling the copy constructor, and I know I'm not doing it". But what about other people using your class? The safe bet is to do one of two things: if you want your class to support pass by value, then write a good copy constructor for your class. If you see no reason to support pass by value on your class, then you should explicitly prohibit this, don't let the compiler's default copy constructor do it for you. The way to enforce your policy is to declare the copy constructor as private, and not supply a definition. While you're at it, do the same for the assignment operator used for assignment of objects of the same class. Example:

class foo {
// These are not supported
// and are not implemented!
foo(const foo& x);
foo& operator=(const foo& x);

When you do this, you ensure that code that implicitly calls the copy constructor will not compile and link. That way nothing happens in the dark. When a user's code won't compile, they'll see that they were passing by value, when they meant to pass by reference (oops).
Be careful of overloaded methods with like signatures.

It's best to avoid overloading methods when the type signature of the methods differs only by 1 "abstract" type (e.g. PR_Int32 or int32). What you will find as you move that code to different platforms, is suddenly on the Foo2000 compiler your overloaded methods will have the same type-signature.

Type scalar constants to avoid unexpected ambiguities.

Non-portable code:

class FooClass {
// having such similar signatures
// is a bad idea in the first place.
void doit(long);
void doit(short);

B::foo(FooClass* xyz)

Be sure to type your scalar constants, e.g., PR_INT32(10) or 10L. Otherwise, you can produce ambiguous function calls which potentially could resolve to multiple methods, particularly if you haven't followed (2) above. Not all of the compilers will flag ambiguous method calls.
Portable code:

class FooClass {
// having such similar signatures
// is a bad idea in the first place.
void doit(long);
void doit(short);

B::foo(FooClass* xyz)

Type scalar constants to avoid unexpected ambiguities.

Some platforms (e.g. Linux) have native definitions of types like Bool which sometimes conflict with definitions in XP code. Always use PRBool (PR_TRUE, PR_FALSE).

Use macros for C++ style casts.

Not all C++ compilers support C++ style casts:

static_cast<type>(expression) (C++ style)

(type) expression (C style)

The header nscore.h defines portable cast macros that use C++ style casts on compilers that support them, and regualar casts otherwise.

These macros are defined as follows:

#define NS_STATIC_CAST(__type, __ptr) static_cast<__type>(__ptr)
#define NS_CONST_CAST(__type, __ptr) const_cast<__type>(__ptr)
#define NS_REINTERPRET_CAST(__type, __ptr) reinterpret_cast<__type>(__ptr)

Note that the semantics of dynamic_cast cannot be duplicated, so we don't use it. See Chris Waterson's detailed explanation on why this is so.

Instead of:

foo_t * x = static_cast<foo_t *>(client_data);
bar_t * nonConstX = const_cast<bar_t *>(this);

You should use:

foo_t * x = NS_STATIC_CAST(foo_t *,client_data);
bar_t * nonConstX = NS_CONST_CAST(bar_t *,this);

Don't use mutable.

Not all C++ compilers support the mutable keyword:

You'll have to use the "fake this" approach to cast away the constness of a data member:

void MyClass::MyConstMethod() const
MyClass * mutable_this = NS_CONST_CAST(MyClass *,this);

// Treat mFoo as mutable
mutable_this->mFoo = 99;

Use nsCOMPtr in XPCOM code.

Mozilla has recently adopted the use of nsCOMPtr in XPCOM code.

See the nsCOMPtr User Manual for usage details.

Don't use reserved words as identifiers.

According to the C++ Standard, Global Names [], paragraph 1:

Certain sets of names and function signatures are always reserved to the implementation:
Each name that contains a double underscore (__) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implemenation for any use. Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.


Stuff that is good to do for C or C++.
Always use the nspr types for intrinsic types.

Always use the nspr types for intrinsic integer types. The only exception to this rule is when writing machine dependent code that is called from xp code. In this case you will probably need to bridge the type systems and cast from an nspr type to a native type.

Do not wrap include statements with an #ifdef.

Do not wrap include statements with an #ifdef. The reason is that when the symbol is not defined, other compiler symbols will not be defined and it will be hard to test the code on all platforms. An example of what not to do:

Bad code example:

// don't do this
#ifdef X
#include "foo.h"

The exception to this rule is when you are including different system files for different machines. In that case, you may need to have a #ifdef SYSTEM_X include.
#include statements should include only simple filenames.

Non-portable example:

#include "directory/filename.h"

Mac compilers handle #include path names in a different manner to other systems. Consequently #include statements should contain just simple file names. Change the directories that the compiler searches to get the result you need, but if you follow the Mozilla module and directory scheme, this should not be required.
Portable example:

#include "filename.h"

Macs complain about assignments in boolean expressions.

Another example of code that will generate warnings on a Mac:

Generates warnings code:

if ((a = b) == c) ...

Macs don't like assignments in if statements, even if you properly wrap them in parentheses.
More portable example:

if (a == c) ...

Every source file must have a unique name.

Non-portable file tree:


For Mac compilers, every file has to have a unique name. Don't assume that just because your file is only used locally that it's OK to use the same name as a header file elsewhere. It's not ok. Every filename must be different.
Portable file tree:


Use #if 0 rather than comments to temporarily kill blocks of code.

Non-portable example:

a = b + c;
* Not doing this right now.
a += 87;
if (a > b) (* have to check for the
candy factor *)

This is a bad idea, because you always end up wanting to kill code blocks that include comments already. No, you can't rely on comments nesting properly. That's far from portable. You have to do something crazy like changing /**/ pairs to (**) pairs. You'll forget. And don't try using #ifdef NOTUSED, the day you do that, the next day someone will quietly start defining NOTUSED somewhere. It's much better to block the code out with a #if 0, #endif pair, and a good comment at the top. Of course, this kind of thing should always be a temporary thing, unless the blocked out code fulfills some amazing documentation purpose.
Portable example:

a = b + c;
#if 0
/* Not doing this right now. */
a += 87;
if (a > b) /* have to check for the
candy factor */

Turn on warnings for your compiler, and then write warning free code.

This might be the most important tip. Beware lenient compilers! What generates a warning on one platform will generate errors on another. Turn warnings on. Write warning free code. It's good for you.


Revision History.
0.5 Initial Revision. 3-27-1998 David Williams 0.6 Added "C++ Style casts" and "mutable" entries. 12-24-1998 Ramiro Estrugo 0.7 Added "nsCOMPtr" entry and mozillaZine resource link. 12-02-1999 Ramiro Estrugo 0.8 Added "reserved words" entry. 2-01-2001 Scott Collins


Further reading:
Here are some books and pages which provide further good advice on how to write portable C++ code.

Scott Meyers, Effective C++ : 50 Specific Ways to Improve Your Programs and Designs

Robert B. Murray, C++ Strategies and Tactics

mozillaZine has a list of books on C++, Anti-C++, OOP (and other buzzwords). This list was compiled from the suggestions of Mozilla developers.

Reply With Quote
Old Wednesday, August 31, 2005
Medal of Appreciation: Awarded to appreciate member's contribution on forum. (Academic and professional achievements do not make you eligible for this medal) - Issue reason: Appreciation
Join Date: Jul 2005
Posts: 1,221
Thanks: 349
Thanked 428 Times in 261 Posts
sibgakhan is a jewel in the roughsibgakhan is a jewel in the roughsibgakhan is a jewel in the roughsibgakhan is a jewel in the rough

C++ Exception Handling
by Denton Woods (08 August 2000)


Exception handling can be a very personal and complex topic. The C language gave the programmer very few exception handling capabilities, as the programmers wanted more control over exceptions themselves. Thankfully, the C++ standards committee crafted a simple, but powerful form of exception handling for the C++ language that still gives the programmer quite a bit of control. Many coders eschew this method that I will present shortly, so more power to you. Most of the information I learned on C++ exception handling was from the wonderful Deep C++ column on MSDN.

Dark Days of C

A typical 'C' function may look something like this:

long DoSomething()
long *a, c;
FILE *b;
a = malloc(sizeof(long) * 10);
if (a == NULL)
return 1;
b = fopen("something.bah", "rb");
if (b == NULL) {
return 2;
fread(a, sizeof(long), 10, b);
if (a[0] != 0x10) {
return 3;
c = a[1];
return c;

Quite messy if you ask me. You are extremely dependent on the return values of functions, and if an error occurs in the program, such as a header value not being correct, you have to constantly have code to handle this. If you allocate, say, 10 pointers in a function, I bet half of that function's code will be dedicated entirely to exception handling. Then there's the fact that if DoSomething returns an error code, the calling function will have to take appropriate steps to correctly handle the error, which, pardon my language, can be a huge pain in the ass.


I'll show you the C++ version of the above function later on. I'm not going to just drop it in your lap and expect you to know everything (even if you do...). I will build up to it, starting with an explanation of try-catch-throw.
try - C++ keyword that denotes an exception block
catch - C++ keyword that "catches" exceptions
throw - C++ keyword that "throws" exceptions
Now for an example that should hopefully make their purpose evident:

void func()
throw 1;
catch(int a)
cout << "Caught exception number: " << a << endl;
cout << "No exception detected!" << endl;

If you were to run this snippet of code, the output would be:

Caught exception number: 1

Now, comment-out the throw 1; line, and the output will be:

No exception detected!

Okay, this seems extremely simple, but exception handling can be very powerful if used correctly. catch can catch any data type, and throw can throw any data type. So, throw dumbclass(); works, as does catch(dumbclass &d) { }.

catch can catch any type, but it does not necessarily have to specify a variable. This is perfectly valid:

catch(dumbclass) { }

As is:

catch(dumbclass&) { }

Also, catch can catch every type of exception if need be:

catch(...) { }

The ellipses signify that all thrown exceptions are caught. You cannot specify a variable name for this method, though. I also recommend that if you catch'ing anything but a basic type (long, short, etc.), you catch them by reference, because, if you do not, the whole thrown variable has to be copied onto the stack, instead of just the reference to the thrown variable. If multiple variable types can be thrown, and you want to get the actual variables, not just an indicator that this type was thrown, you can do a multiple catch:

try {
throw 1;
// throw 'a';
catch (long b) {
cout << "long caught: " << b << endl;
catch (char b) {
cout << "char caught: " << b << endld;

Thrown Exceptions

When an exception is thrown, the program keeps going up the function stack until it encounters an appropriate catch. If there is no catch statement in the program, STL will handle the thrown exception via the terminate handler, but it usually does so less gracefully than you could, by popping-up a nasty dialog box or any variety of other things, usually by calling abort.

The absolute most important characteristic about this is that while it is stepping-up in the function stack, the program is calling the destructors of all local classes. So, voilà, you don't have to keep including code to free memory, etc. if you use classes often, even if they are just inline'd wrapper classes. I'd like to point you to right now. They have an excellent smart pointer class -- scoped_ptr, along with several other useful classes. It is pretty much equivalent to STL's auto_ptr, but I like it better. Either one is just fine to use.

Overloading the Global New/Delete Operators

I'd like to refer you to another tutorial now. The excellent "How To Find Memory Leaks" tutorial describes a great process to detect memory leaks by overloading the new and delete operators. The method he proposes only works for operator new/delete, not operator new[]/delete[]. It is fairly easy to figure these out, as they accept the same parameters.

Okay, so you ask why I mention overloading these global operators in an exception handling tutorial, and an answer you shall receive. I modify Dion Picco's operator new/new[] to throw an exception if they fail in my projects. I also define non-debug versions. Source can be found for my implementation at the end of this tutorial. Now, I make my implementation of new/new[] throw my own exception class called "Exception", which is in exception.h in the source accompanying this tutorial. STL defines a class called "exception" in , but it deals exclusively with strings. There's no quick way to tell what kind of exception was caught by doing catch (exception &e) { } without doing a complete string compare. So I created my own class, which can work with either strings, numbers or both. For reference, the STL way is to use bad_alloc, which is in , but if you #include , you will have troubles, because the regular new/delete/new[]/delete[] prototypes are in there.

If you overload new, etc. like mentioned, you can do:

char *a;
a = new char[10];
catch (...)
// a was not created - handle this here by exiting, etc.
// a was successfully created, continue

Of course this seems like more code than the standard "is a equal to NULL?" The thing is, it's not, because you can call several functions in a try block that allocate memory or anything else that can throw an exception. The following example uses my CFile wrapper, but you can use whatever you want, even the iostream classes. Don't worry, as classes such as vector are very optimized, so it's just a myth that these classes induce a significant overhead. Now we can get back to our infamous DoSomething function, with a function that calls it:

#include "file.h"
#include <vector>
#include "allocation.h" // Must be included after headers that can allocate memory
using std::vector;void CallDoSomething()
if (DoSomething()) {
cout << "File had proper value!" << endl;
else {
cout << "File had invalid value!" << endl;
catch (Exception &e)
cout << "Memory not allocated!" << endl;
bool DoSomething()
vector <int> a;
CFile b; if (!b.Open("something.bah", "rb"))
return false;
a.resize(10); // If this fails, it throws an exception and closes b before leaving
b.Read(&a[0], sizeof(long) * 10);
if (a[0] != 0x10) {
return false;
return true;

If you don't agree that this looks much nicer and is much easier to use than the C version, I don't know what is. =)

Now we see that C++ exception handling's power lies within its ability to step out of the current function and automagically call any local class destructors along the way. If a critical error occurred in a regular C program, the coder might be forced to call exit() or abort(), but neither of these automatically calls the local class destructors on its way out of the program. In actuality, they don't even step up the function stack!

Empty Throws

So, we can see now how powerful and useful this "new" method is. A try-catch block can contain another try-catch block, and this block can throw anything, too, which will be caught by the outer catch if there is no corresponding inner catch, or the catch throws something. One thing I have neglected to mention is that throw need not even have anything after it:

cout << "Caught exception!" << endl;

This could be used in extreme situations where you don't even care what was thrown.


A practical application of using try-catch-throw can be in a game. Say you have a cMain class and instantiate a Main based off of it:

class cMain
bool Setup();
bool Loop(); // The main program loop
void Close();
cMain Main;

In your main() or WinMain() function, you can do something like:

catch (Exception &e)
log("Exception thrown: %s", e.String()); // Just uses any log class you want.

// Close everything down here and present an error message

Your cMain::Loop() function may look something like this:

while (GameActive)
// Perform game loop here
catch (Exception &e)
/* Determine if exception thrown was critical, such as a memory error.
If the exception wasn't critical, just step out of this. If it was,
rethrow the exception like either "throw e" or just plain "throw", which
will rethrow the caught exception. */


I've shown you to the best of my abilities how to use C++ exception handling, but only you can decide if you want to use it. The methods presented in this article can help speed development time and make your life a whole lot easier. There are a plenty of topics I failed to cover in this article, and if you want to learn them, I suggest you visit Deep C++.

Printer-friendly version of this article
Return to the Featured Articles Archives
Return to flipCode
Reply With Quote
Old Wednesday, August 31, 2005
Medal of Appreciation: Awarded to appreciate member's contribution on forum. (Academic and professional achievements do not make you eligible for this medal) - Issue reason: Appreciation
Join Date: Jul 2005
Posts: 1,221
Thanks: 349
Thanked 428 Times in 261 Posts
sibgakhan is a jewel in the roughsibgakhan is a jewel in the roughsibgakhan is a jewel in the roughsibgakhan is a jewel in the rough
Default Free E-Books

Free E-Books
Good Site for Software Engineers
Reply With Quote
Old Wednesday, August 31, 2005
Medal of Appreciation: Awarded to appreciate member's contribution on forum. (Academic and professional achievements do not make you eligible for this medal) - Issue reason: Appreciation
Join Date: Jul 2005
Posts: 1,221
Thanks: 349
Thanked 428 Times in 261 Posts
sibgakhan is a jewel in the roughsibgakhan is a jewel in the roughsibgakhan is a jewel in the roughsibgakhan is a jewel in the rough
Post some useful IT links

This page is x-udd on a snarf of <>
Introduction to C Programming <>
C Optimization Tutorial <>
Compiling C and C++ Programs on UNIX Systems - gcc/g++ <>
Building and Using Static and Shared C Libraries <>²
Building and Using Static and Shared C Libraries <>
Programming in C: UNIX System Calls and Subroutines Using C <>
C FAQ <>
C Programming Class Notes <>
ANSI C for Programmers on UNIX Systems <>
Sams Teach Yourself C in 24 Hours <>
Sams Teach Yourself C in 21 Days (4th Ed.) <>
The Standard C Library for Linux - Part 1: file functions <>
The Standard C Library for Linux - Part 2: character input/output <>
The Standard C Library for Linux - Part 3: formatted input/output <>
The Standard C Library for Linux - Part 4: Character Handling <>
The Standard C Library for Linux - Part 5: Miscellaneous Functions <>
Programming in C: A Tutorial <>
An Introduction to C Development on Linux <>
C Programming Course <>
C Language Tutorial <>
CScene: An Online Magazine for C and C++ Programming <>

C++ Tutorial <>
Understanding C++: An Accelerated Introduction <>
An Introduction to C++ Class Hierarchies <>
G++ FAQ <>
Introduction to Object-Oriented Programming Using C++ <>
Compiling C and C++ Programs on UNIX Systems - gcc/g++ <>
C++ FAQ Lite <>
C++ Programming Language Tutorials <>
Reducing Dependencies in C++ <>
C++ Exception Handling <>
Part 1: Unicode <>
Part 2: A Complete String Class <>
Making C++ Loadable Modules Work <>
Sams Teach Yourself C++ in 21 Days (2nd Ed.) <>
C++ Portability Guide <>
C++ Tips <>
C++ Language Tutorial <>
CScene: An Online Magazine for C and C++ Programming <>
C++ Libraries FAQ <>

CGI Programming Tutorial <>
CGI Programming 101 <>
CGI Manual of Style <>
CGI Developer's Guide <>
CGI Programming Unleashed <>
Sams Teach Yourself CGI Programming with Perl 5 in a Week (2nd Ed.) <>
CGI/Perl Tips, Tricks and Hints <>
A Tour of HTML Forms and CGI Scripts <>
Reading CGI Data: URL-Encoding and the CGI Protocol <>
CGI Programming FAQ <>
A Brief Tutorial on CORBA <>
CORBA 2.0 Specification <>
CORBA Tutorials <>
Sams Teach Yourself CORBA in 14 Days <>
Linux Network Programming, Part 3 - CORBA: The Software Bus <>
CORBA Program Development, Part 1 <>
CORBA Program Development, Part 2 <>
CORBA Program Development, Part 3 <>
CSS2 Tutorial <>
CVS Tutorial <>
Concurrent Version System Tutorial <>
Introduction to Dynamic HTML <>
Emacs: The Software Engineer's ``Swiss Army Knife'' <>
Emacs FAQ <>
GNU Emacs Lisp Reference Manual <>
Programming in Emacs Lisp <>
GNU Emacs Manual <>
A Tutorial Introduction to Emacs <>
EMACSulation: Internet-ready! <>
EMACSulation: Ediff - An Emacs interface to diff and patch <>
EMACSulation: Emacs as a Server <>
EMACSulation: Customizing Emacs <>
Basic Emacs <>
EMACSulation: Templating Mechanisms <>
Emacs Macros and the Power-Macros Package <>
Polyglot Emacs 20.4 <>
Advanced Programming in Expect: A Bulletproof Interface <>
Automating Tasks with Expect <>
What Can you Expect?--A Data Collection Project Using Linux <>
Professional Programmer's Guide to Fortran 77 <>
Fortran 90 and Computational Science <>
User Notes on Fortran Programming <>
Fortran Programming for Physics and Astronomy <>
A Fortran 90 Tutorial <>
Using GNU Fortran <>
Fortran 90: A Course for Fortran 77 Programmers <>
Fortran 90 for the Fortran 77 Programmer <>
Introduction to Fortran <>
GIMP Tutorial Index <>
A Tutorial for Perl GIMP Users <>
A Scheme Tutorial for GIMP Users <>
GIMP Guide <>
The GIMP User Manual <>
Pseudo 3-D with GIMP <>
Graphical Photocomposition with GIMP <>
Creating Text with the GIMP <>
Creating Fire Effects with the GIMP <>
Creating and Editing Animations with GIMP <>
GIMP-Perl: GIMP Scripting for the Rest of Us <>
Writing a GIMP Plugin <>
GIMP: The RRU Tutorial <>
GIMP User FAQ <>
Script-Fu Tutorial <>
The Quick Start Guide to the GIMP, Part 1 <>
The Quick Start Guide to the GIMP, Part 2 <>
The Quick Start Guide to the GIMP, Part 3 <>
The Quick Start Guide to the GIMP, Part 4 <>
Application Programming Using the GNOME Libraries <>
Part 1: Everything You Need to Get Started <>
Part 2: Building a Sample Genealogy Program <>
Part 3: Adding File Saving and Loading Using libxml <>
Creating GTK+ Widgets with GOB: An Easier Way to Derive New GTK+ Widgets <>
Handling Multipel Documents: Using the GnomeMDI Framework <>
Livening Things Up: Graphics Made Easy Using the GNOME Canvas <>
Developing Gnome Applications with Python - Part 1 <>
GDK Reference Manual <>
GLib Reference Manual <>
GTK+ Reference Manual <>
The GIMP Toolkit <>
GTK V1.2 Tutorial <>
Drawing and Event Handling in GTK <>
An Introduction to the GIMP Tool Kit <>
Constrained Dynamics <>
Continuum Dynamics <>
Differential Equation Basics <>
Energy Functions and Stiffness <>
Particle System Dynamics <>
An Introduction to Physically Based Modeling <>
Rigid Body Dynamics I <>
Rigid Body Dynamics II <>
Scientific Visualization Tutorials <>
Gnuplot - An Interactive Plotting Program <>
GIF Animation Tutorial <>
HTML Table Tutorial <>
HTML by Example <>
How to Use HTML 3.2 <>
Creating a Client-Side Image Map <>
Advanced HTML: How to Create Complex Multimedia Documents for the Web <>
The ABCs of HTML <>
Sharky's Netscape Frames Tutorial <>

ILU Reference Manual <>
Using ILU with ANSI C: A Tutorial <>
Using ILU with Java: A Tutorial <>
Using ILU with Python: A Tutorial <>
ipchains: Packet Filtering for Linux 2.2 <>
Setting Up IP Masquerade <>
Setting Up IP-Masquerading <>
Ipchains: Easy Links to the Net <>
Linux Networking Using Ipchains <>
Advanced 4.4BSD Interpprocess Communication Tutorial <>
UNIX Multi-Process Programming and IPC <>
Enterprise JavaBeans Tutorial <>
JavaBeans Short Course <>
Introduction to the JavaBeans API <>
JDBC Short Course <>
Essentials of the Java Programming Language, Part 1 <>
Essentials of the Java Programming Language, Part 2 <>
Writing Advanced Applications for the Java Platform <>
Fundamentals of Java Security <>
Fundamentals of Java Servlets <>
Introduction to the Collections Framework <>
Introduction to CORBA <>
Fundamentals of RMI <>
Advanced <>
Introductory <>
Intermediate <>
Java Language Specification <>
Java Tutorial: Servlet Trail <>
Java Virtual Machine Specification (2nd Ed.) <>
Glossary of Java and Related Terms <>
The Java Language Environment <>
Java Look and Feel Design Guidelines <>
Story of a Servlet: An Instant Tutorial <>
Introduction to Java <>
Java2D: An Introduction and Tutorial <>
Java Servlet Tutorial <> FAQ <>
Brewing Java: A Tutorial <>
Shlurrrppp ... Java: The First User-Friendly Tutorial on Java <>
Swing Tutorial <>
Swing: A Quick Tutorial for AWT Programmers <>
Thinking in Java <>
Java RMI Tutorial <>
Java for C++ Programmers <>
The Advanced Jav/aJ2EE Tutorial <>
Hacking Java: The Java Professional's Resource Kit <>
JFC Unleashed <>
Java Developer's Guide <>
Java Developer's Reference <>
Sams Teach Yourself Java in 21 Days (Professional Reference Ed.) <>
Java Unleashed (2nd Ed.) <>
Java 1.1 Unleashed (3rd Ed.) <>
Java Game Programming Tutorial <http://www.intergate.bc.c/apersonal/iago/javatut/>
Java Networking FAQ <>
Java Tutorial: A Practical Guide for Programmers <>
Sockets Programming in Java <>
Programming with Java - Part I <>
Programming with Java - Part II <>
Setting Up a Java Development Environment for Linux <>
Understanding Java <>
Beginner's Guide to JDK <>
GUI Development in Java <>
Java Servlets: An introduction to writing and running Java servlets on Linux <>
Introductory _JavaScript Tutorials <>
_JavaScript Authoring Guide <>
Client-Side _JavaScript 1.3 Guide <>
Client-Side _JavaScript 1.3 Reference <>
Core _JavaScript 1.4 Guide <>
Core _JavaScript 1.4 Reference <>
Server-Side _JavaScript 1.4 Guide <>
_JavaScript FAQ <>
_JavaScript Tutorial <>
The Way of _JavaScript <>
Voodoo's Introduction to _JavaScript <>
_JavaScript Tutorial for Programmers <>
_JavaScript Primer <>
EchoEcho _JavaScript Tutorial <>
Sams Teach Yourself _JavaScript 1.1 in a Week (2nd Ed.) <>

Common Lisp Hints <>
Common Lisp the Language (2nd Ed.) <>
Lisp FAQ <>
Lisp Programming Tutorial <>
Lisp Tutorial <>
LISP Tutorial <>
Common Lisp HyperSpec <>
Basic MIDI Tutorials <>
Tutorial on MIDI and Music Synthesis <>
ML Tutorial <>
Programming in Standard ML '97 <>
A Gentle Introduction to ML <>
Moscow ML Owner's Manual <>
An MPI Tutorial <>
Tutorial on MPI <>
MPI: Portable Parallel Programming for Scientific Computing <>
Tuning MPI Applications for Peak Performance <>
MPI: From Fundamentals to Applications <>
MPI Tutorial <>
MPI: The Complete Reference <>
Introduction to Parallel Programming Using MPI <>
Basics of MPI Programming <>
Matlab Basics Tutorial <>
Matlab Summary and Tutorial <>
Matlab - Official Online Manuals in PDF <>
The Soar 8 Tutorial Home Page <>
8051 Assembly Tutorial <>
GNAT Reference Manual <>
MOO Programming Tutorial <>
Genetic Tutorial <>
Basic SUIF Programming Guide <>
Cosmology Tutorial <>
Relativity Tutorial <>
80x86 Assembly Language Programming Tutorial <>
ZPL Programming Guide <>
VHDL Synthesis Tutorial <>
Part 1: Overview <>
Part 2: The Lexical Analyzer <>
Part 3: The Parser <>
Part 4: The Symbol Table and Syntax Tree <>
Part 5: The Semantic Checker and Intermediate Code Generator <>
Part 6: Optimization <>
Part 7: The Virtual Machine <>
Part 8: Executable Code <>
Part 9: Advanced Subjects <>
A tutorial on character code issues <>
Imlib Programmer's Guide <>
Speech Analysis Tutorial <>
INTERCAL Programming Language Revised Reference Manual <>
Quantum Computation: A Tutorial <>
Modem Tutorial <>
Biotiming Tutorial <>
Introduction to Motif Application Development <>
X Window/Motif Programming <>
Motif FAQ <>
Motif/Lesstif Application Development <>
X/Motif Programming <>
OpenGL Programming Guide - The Red Book <>
NeHe OpenGL Tutorials <>
Advanced Graphics Programming Techniques Using OpenGL <>
Introduction to OpenMP <>
OpenGL: From the Extensions to the Solutions <>
Designing and Building Parallel Programs <>
Tutorial Material on MPI <>
Tutorial on MPI <>
Parallel Programming - Basic Theory for the Unwary <>
Building a Beowulf System <>
High Performance Fortran in Practice <>
Java Personal OpenGL Tutorial (JPOT) <>
OpenGL Tutorial <>
Advanced OpenGL Texture Mapping <>
Linux Focus <>
What is OpenGL? <>
GLUT Programming: Windows and Animations <>
OpenGL Programming: Simple Polygon Rendering <>
OpenGL Programming: More About Lines <>
GLUT Programming: Windows Management <>
Programming with OpenGL: Advanced Rendering <>
Programming with OpenGL: Advanced Techniques <>
OpenGL Overview <>
HPF: Programming Linux Clusters the Easy Way <>
PHP Knowledge Base <>
PHP/MySQL Tutorial <>
PHP3 Introduction <>
PHP Tutorials <>
PHP Manual <>
PHP How-To Columns <>
An Introduction to PHP3 <>
Advanced Tutorial on PVM 3.4 <>
PVM: A User's Guide and Tutorial for Networked Parallel Computing <>
Parallel Processing using PVM <>
Pascal Programming OnLine Notes <>
Roby's Pascal Tutorial <>
Pascal Language Tutorial <>
Perl Modules <>
Perl man pages <>
Perl Tutorial <>
A Quick Introduction to Perl <>
Perl FAQ <>
HTMLified Perl 5 Reference Guide <>
Perl Regular _Expression Tutorial <>
Save it With Perl: A CPAN Solution to Data Persistence <>
Introduction to Perl <>
The Perl Programming Language <http://www.civeng.carleton.c/aCourses/Grad/1995-96/82.562/perl/>
Sams Teach Yourself Perl 5 in 21 Days (2nd Ed.) <>
Using Perl for Web Programming <>
Perl 5 Quick Reference <>
Perl Part III - Arrays <>
Perl Part II - Writing a Real Program <>
Perl Part I - Introduction <>
Perl Tutorial <>
Robert's Perl Tutorial <>
CGI/Perl Tips, Tricks and Hints <>
An Introduction to Perl <>
Embperl: Modern Templates <>
Perl Embedding <>
Network Programming with Perl <>
PostScript FAQ <>
PostScript Programming <>
About PostScript Errors <>
A First Guide to PostScript <>
PostScript Tutorial and Reference <>
PostScript III: The Operand Stack of PostScript: Arrays, Variables, Loops and Macro Definitions <>
PostScript II: The Operand Stack, Manipulations and Mathematical Operators <>
PostScript I: The Language <>
The Online POV-Ray Tutorial <>
Povray I: First Steps <>
Povray II: Basic Notions <>
Povray III: Design of Recursive Structures <>
Prolog Programming: A First Course <>
On-Line Guide to Prolog Programming <>
Prolog Programming Tutorial <>
Practical ILU with Python: A Tutorial <>
Learning to Program <>
Numeric Python Tutorial <>
Cheat Sheet: A Quick Reference Document for Newcomers <>
Text Processing in Python: Tips for Beginners <>
Using State Machines: Algorithms and Programming Approaches in Python <>
Tinkering with XML and Python: An Introduction to XML Tools for Python <>
The Other Scripting Language that Starts with a "P" <>
The Dynamics of DOM: A Closer Look at Python's xml.dom Module <>
My First Web-Based Filtering Proxy: Converting Text to HTML Using Txt2Html <>
Instant Python <>
Instant Hacking: Learn How to Program With Python <>
The Whole Python FAQ <>
The What, Why, Who, and Where of Python <>
Extending and Embedding the Python Interpreter <>
Python Library Reference <>
Python Reference Manual <>
An Introduction to Python <>
Python Tutorial <>
Getting Started With Python <>
Remote Procecure Call - AIX Programming Concepts Guide <>
Protocol Compiling and Lower Level RPC Programming <>
Programming with Remote Procedure Calls - SCO <>
RPC Programming Documents - Sun <>
RPC Programming Interface - DEC <>
Remote Procedure Calls in Linux <>
REXX/imc Tutorial <>
Advanced Object REXX Programming <>
Introduction to Object REXX Programming <>
Rexx FAQ <>
TCP/IP Socket Programming with REXX <>
Ruby Language FAQ <>
Ruby: A New Language <>
Thirty-seven Reasons I Love Ruby <>
The Ruby Programming Language <>
Ruby User's Guide <>
Ruby Language Reference Manual <>
An Introduction to SCSI Drivers <>
Advanced SCSI Drivers And Other Tales <>
SQL Tutorial and Interpreter <>
Introduction to Structured Query Language <>
Beginning MySQL Tutorial <>
Sams Teach Yourself SQL in 21 Days (2nd Ed.) <>
SQL Tutorial I - Introduction to SQL and Installation of PostgreSQL <>
MySQL: A Database Server <>
Setting Up a MySQL Based Website - Part 1 <>
Setting Up a MySQL Based Website - Part II <>
PostgreSQL Tutorial <>
Using mSQL in a Web-Based Production Environment <>
Speaking SQL <>

Integrating SQL with CGI, Part 1 <>
Integrating SQL with CGI, Part 2 <>
PostgreSQL--the Linux under the Databases <>
Beagle SQL, A Client/Server Database for Linux <>
NoSQL Tutorial <>
MySQL Introduction <>

NCSA HTTPd Server Side Includes <>
The Server Side Includes Tutorial <http://www.carleton.c/a~dmcfet/html/ssi.html>
Programming in Standard ML '97: An On-Line Tutorial <>
SSI Tutorial <>
A Modest STL Tutorial <>
The Standard Template Library Tutorial <>
Introduction to STL, Standard Template Library <>
STL Tutorial <>
Introduction to Samba - Part 1: Key Concepts <>
More Adventures with Samba <>
Linux Networking: Exploring Samba <>
Using Samba to Mount Windows 95 <>
Introducing Samba <>
Samba's Encrypted Password Support <>
Scheme Tutorial <>
A Scheme Tutorial for GIMP Users <>
Revised (4) Report on the Algorithmic Language Scheme <>
MIT Scheme Reference <>
DrScheme Programming Environment Manual <>
MzScheme Language Manual <>
Teach Yourself Scheme in Fixnum Days <>
Lecture Notes on the Principles of Programming Languages <>
An Introduction to Scheme and Its Implementation <>
The Scheme Programming Language <>
Scheme FAQ <>
The PACT Scheme Language <>
Fundamentals of Computer Science I <>
Chez Scheme User's Guide <>
The Scheme Programming Language (2nd Ed.) <>
Basic Aspects of Squeak and the Smalltalk-80 Programming Language <>
IBM Smalltalk Tutorial <>
Daryl's TCP/IP Primer <>
Introduction to the Internet Protocols <>
IP Next Generation Overview <>
IPv6: The New Internet Protocol <>
Understanding IP Addressing <>
Introduction to IP Multicast Routing <>
TCP/IP Tutorial and Technical Overview <>
An Introduction to TCP/IP Programming <>
TCP/IP FAQ - Part 1 <>
TCP/IP FAQ - Part 2 <>
TCP/IP: Introduction to the Internet Protocols <>
Teach Yourself TCP/IP in 14 Days (2nd Ed.) <>
TCP/IP for Idiots Tutorial <>
T/TCP: TCP for Transactions <>
TCP/IP and IPX Routing Tutorial <>
Introduction to Programming with Tcl <>
Programming Using Tcl/Tk <>
Practical Programming in Tcl and Tk <>
Tcl/Tk Cookbook <>
Introduction to the Tcl/Tk Programming Language <>
The Tcl Syntax <>
Tcl/Tk Quick Reference Guide <>
comp.lang.tcl FAQ <>
Tcl/Tk Man Pages <>
Rapid Prototyping with Tcl/Tk <>
Tcl/Tk: The Swiss Army Knife of Web Applications <>
LaTeX for Secretaries <>
The UNIX Time-Sharing System <>
The Evolution of the UNIX Time-Sharing System <>
The UNIX Time-Sharing System - A Retrospective <>
UNIX - The Bare Minimum <>
Using the UNIX Operating System <>
History of UNIX <>
UNIXhelp for Users <>
STScI UNIX Users Guide <>
UNIX System Administration <>
UNIX Past <>
Compiling C and C++ Programs on UNIX Systems - gcc/g++ <>
Manipulating Files and Directories in UNIX <>
Introduction to UNIX Signals Programming <>
UNIX and Multics <>
UNIX Man Pages Online <>
UNIX Unleashed <>
UNIX Unleashed: System Administrator's Edition <>
UNIX Unleashed: Internet Edition <>
A Basic UNIX Tutorial <>
The UNIX Programming Environment <>
Introduction to UNIX <>
Intermediate UNIX Training <>
Coping with UNIX: An Interactive Survival Kit <>
Introduction to UNIX Course Notes <http://www.sao.nrc.c/aimsb/rcsg/documents/>
Advanced Introduction to UNIX <http://www.sao.nrc.c/aimsb/rcsg/documents/advanced/advanced.html>
Basic Introduction to UNIX <http://www.sao.nrc.c/aimsb/rcsg/documents/basic/basic.html>
Programming the Shell <http://www.sao.nrc.c/aimsb/rcsg/documents/bourne/bourne.html>
Networking/Internet with UNIX <http://www.sao.nrc.c/aimsb/rcsg/documents/internet/internet.html>
Learning UNIX <>
Introduction to VRML <>
VRML Primer and Tutorial <>
VRML Audio Tutorial <>
The Easy VRML Tutorial <>
VRML 97 Tutorial <>
Introduction to VRML 2.0 <>
An Introduction to VRML <>
VRML 2.0 Tutorial <>
Securing X Windows <>
X Window Guide <>
Using X11 Windows <>
Looking Through X Windows <>
X Widget FAQ <>
Xlib Programming: A Short Tutorial <>
X Windows Version 11.5: A Concise Description <>
Beginning with X <> (Xt) FAQ <> FAQ <>
Configuring X <>
The 40 Most Common X Programming Errors (And How to Avoid Repeating Them) <>
X Window System Application Performance Tuning <>
Taming the X Display Manager (xdm) <>
Introduction to X Windows <>
XFree86 FAQ <>
Programming with XView <>
Developing Imaging Applications with XIE <>
X Window System Administration <>
eXternal Data Representation Overview for Programming <>
eXternal Data Representation - AIX Programming Concepts Guide <>
External Data Representation: Sun Technical Notes <>
External Data Representation: Technical Notes <>
Working with XML: The Java API for XML Parsing (JAXP) Tutorial <>
XQL Tutorial <>
Tutorial Introduction to XML <>
The XML Revolution: Technologies for the Future Web <>
An Introduction to Perl's XML::XSLT Module <>
XML Reference and Glossary <>
Extensible Markup Language (XML) 1.0 <>
XUL Tutorial <>
The GNU Configure and Build System <>
Developing Software with GNU (w/ Learning Autoconf and Automake) <>
Autoconf: Creating Automatic Configuration Scripts <>
GNU Automake <>
Adding Fortran 77 Support to Automake <>
Debugging C and C++ Programs using gdb <>
Debugging with GDB (GNU Manual) <>
The Elm Reference Guide <>
The Elm User's Guide <>
Email with the Elm Mailer <>
Elm Tutor <>
Compiler Construction Using Flex and Bison <>
How to Write a Simple Parser with Lex and Yacc <>
A Guide to Lex and Yacc <>
Creating an Input Language with the lex and yacc Commands <>
A Brisk Tutorial on Lex and Yacc <>
What Do Lex and Yacc Do? <>
The Roles of Lex and YACC <>
A Little Manual for Lex and Yacc <>
GNU Bison Manual <>
GNU Flex Manual <>
Compiler Construction Tools - Part I: JFlex and CUP <>
Compiler Construction Tools - Part II: Installing JFlex and CUP - Specific Instructions <>
What is Lex? What is Yacc? <>
lex and yacc: Tools Worth Knowing <>
Introductory Tutorial on Make <>
A Brief Introduction to Make <>
Getting Started with Make - Part 1: The Basics <>
Getting Started with Make - Part 2 <>
Tutorial on Make <>
Automating Program Compilation - Writing Makefiles <>
A Brief Make Tutorial <>
Make - A Tutorial <>
GNU Automake Manual <>
GNU Make Manual <>
Quick and Dirty Make Tutorial <>
Building Projects with Imake <>
VDSL Tutorial <>
Cable Modem Tutorial <>
Tutorial: Insight Into Current Internet Traffic Workloads <>
Tutorial on Internet Monitoring <>
Frame Relay Tutorial <>
Serial Programming for POSIX Compliant Operating Systems <>
sed Script Archive <>
sed FAQ #2 <>
Do It With sed <>
sed - A Non-Interactive Text Editor <>
Introduction to sed <>
Handy One-Liners for sed <>
sed FAQ #1 <>
sed - The Stream Editor <>
sed Tutorial <>
UNIX Shell Patterns <>
Korn Shell Reference <>
UNIX Shell Programming Bourne and Korn Shells <>
A Brief Introduction To C Shell Variables <>
UNIX Shell Scripts <>
Writing UNIX Scripts <>
Part 1: Fundamental Programming in Bash <>
Part 2: More Bash Programming Fundamentals <>
Part 3: Exploring the Ebuild System <>
Working the the Shell Environment <>
pdksh (Public Domain Korn) <http://www.cs.mun.c/a~michael/pdksh/pdksh-man.html>
Shell Script Programming <>
C Shell Tutorial <>
Shell Differences FAQ <>
Z-Shell FAQ <>
GNU Bash Reference Manual <>
Bourne/Bash: Shell Programming Introduction <>
Functions and Aliases in Bash <>
Introduction to Shell Scripting <>
The Deep, Dark Secrets of Bash <>
bash (GNU) <>
csh (C) <>
ksh (Korn) <>
sh (Bourne) <>
tcsh <>
zsh (Z) <>
Getting the Most from Your Shell <>
Shell Command Language Index <>
UNIX Bourne Shell Programming <>
Features of the TCSH Shell <>
Improve Bash Shell Scripts Using Dialog <>
Extending the Bash Prompt <>
Shell Functions and Path Variables, Part 1 <>
Shell Functions and Path Variables, Part 2 <>
Shell Functions and Path Variables, Part 3 <>
Introduction to Network Functions in C <>
Berkeley UNIX System Calls and Interprocess Communication <>
Using Internet Sockets <>
Beginner's Guide to Sockets <>
BSD Sockets: A Quick And Dirty Primer <>
Sockets Programming in Java <>
Introduction to Socket Programming <>
An Introduction to Socket Programming <http://www.uwo.c/aits/doc/courses/notes/socket/index.html>
Perl and Sockets <>
Linux Network Programming, Part 1 - BSD Sockets <>
Getting Started with POSIX Threads <>
LinuxThreads FAQ <>
Part 3: Improve Efficiency with Condition Variables <>
Part 1: A Simple and Nimble Tool for Memory Sharing <>
Part 2: The Little Things Called Mutexes <>
Multi-Threaded Programming with POSIX Threads <>
Threads FAQ <>
Multithreaded Programming <>
LinuxThreads Programming <>
Pthreads - Overview and Manual <>
What is Multi-Threading? <>
Thread-Specific Data and Signal Handling in Multi-Threaded Applications <>
Introduction to Multi-Threaded Programming <>
POSIX Thread Libraries <>
vi Tutorial <>
elvis Manual <>
An Extremely Quick and Simple Introduction to the Vi Text Editor <>
vim Reference Manual <>
Mastering the vi Editor <>
vi FAQ - Part 1 <>
vi FAQ - Part 2 <>
vim Editor FAQ <>
vi Quick Reference and Tutorial <>
Revisiting VIM <>
The vi/ex Editor <>
Reply With Quote
Old Tuesday, December 27, 2005
SAZ's Avatar
SAZ SAZ is offline
Qualifier: Awarded to those Members who cleared css written examination - Issue reason: CE 2009 - Roll no 3245
Join Date: Dec 2005
Location: Lahore
Posts: 27
Thanks: 7
Thanked 15 Times in 8 Posts
SAZ is on a distinguished road
Thumbs down Stop this nonsense

Hi Sibgat
i am BSCS student last semester , so u can't say that i passed these comments simply it is irrelevant to me
but tell what is the purpose of this , i have read your post and got the impression that u are a very sensible person
but i cant get the meaning of throwing this data in this form.

if u feel that my words were not appropraiate and harsh
then i do feel sorry

May Allah bless us all
Reply With Quote
Old Friday, January 26, 2007
Junior Member
Join Date: Jan 2007
Posts: 1
Thanks: 0
Thanked 0 Times in 0 Posts
pickatutorial is on a distinguished road

I think the following site might be of help to IT students:
Reply With Quote

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On

Similar Threads
Thread Thread Starter Forum Replies Last Post
Ebooks Links Predator References and Recommendations 27 Thursday, February 08, 2018 11:23 AM
The Globalization of World Politics: Revision guide 3eBaylis & Smith: hellowahab International Relations 0 Wednesday, October 17, 2007 03:13 PM

CSS Forum on Facebook Follow CSS Forum on Twitter

Disclaimer: All messages made available as part of this discussion group (including any bulletin boards and chat rooms) and any opinions, advice, statements or other information contained in any messages posted or transmitted by any third party are the responsibility of the author of that message and not of (unless is specifically identified as the author of the message). The fact that a particular message is posted on or transmitted using this web site does not mean that CSSForum has endorsed that message in any way or verified the accuracy, completeness or usefulness of any message. We encourage visitors to the forum to report any objectionable message in site feedback. This forum is not monitored 24/7.

Sponsors: ArgusVision   vBulletin, Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.