C++ casts Demystified

Hope the following code sample clarifies the differences between the various C++ casts. const_cast is left as a trivial case.

class V {public: virtual ~V(){}}; //Virtual Base Class

class G: virtual public V{}; //Common ancestor for base classes
class B1: public G{}; 

class B2{}; //Non-polymorphic class
class B3: public G{}; 

class D: public B1, public B2, public B3 {};

class I{ public: virtual ~I(){}}; //Independent, unrelated Class

int main(int argc, char* argv[])

{
 D d;
 D*  pdd=&d; 
 B1* pb1d=&d; //No casts needed

 B2* pb2d=&d; 
 B3* pb3d=&d; 
 V*  pvd=&d;

 //G*  pgd=&d; //Compile-error, ambiguous

 // I* pi1d=&d; //Cast needed. Compile error.
 I* pi1d=(I*)&d; //No compile error, but semantically wrong. Address gets assigned.

 //I* pi1d=static_cast<I*>(&d); //Compile error

 //Upcasting
 B1* pb1= dynamic_cast<B1*>(pdd); // = pb1d 

 B2* pb2= dynamic_cast<B2*>(pdd); // = pb2d

 B3* pb3= dynamic_cast<B3*>(pdd); // = pb3d

 G*  g1 = dynamic_cast<G*>(pdd); //No compile-error, but null because ambiguous

 G*  g2 = reinterpret_cast<G*>(pdd); //No compile-error, nothing

 //G*  g3 = static_cast<G*>(pdd); //Compile-error, but null because ambiguous
 
 //Downcasting
 D* pdd1 = dynamic_cast<D*>(pb1d); //downcast, B1 must be polymorphic

 //D* pdd = dynamic_cast<D*>(pb2d); //downcast, B2 not polymorphic. Compile error.
 G* g3= dynamic_cast<G*>(pvd); //ambiguous downcast, = null, compiles in C++ not in Comeau

// G* g4= static_cast<G*>(pvd); //ambiguous downcast, = null

 //Crosscasting
 I* pi= dynamic_cast<I*>(pdd); //pi will be null

 I* pi2= reinterpret_cast<I*>(pdd); //pi2 will be equal to pdd

 //I& ri= dynamic_cast<I&>(*pd); //throws an exception

 B3* pb31= dynamic_cast<B3*> (pb1d);



 return 0;
}

Rethink About Reuse

Was listening to C++ Stylistics

1. Three pillars of OO
1. inheritance
2. encapsulation
3. polymorphism
1. overload
2. coercion
3. parametric
4. runtime inclusion
2. object oriented styles
1. prototype-based
2. object-based
3. dynamically typed
4. statically typed
3. object destruction policy
1. scope-nound
2. explicit
3. reference-based
4. GC

4. reuse is actually use!
5. use chairs to make a bed is reuse
6. using it again to sit is just use
7. inheritance-based
8. interface-based
9. challenge is to organize code
10. if you are not doing much, you become uncomfortable
11. "Adaptation"?
12. you cannot have virtual template functions

PAPPADOM Framework

I have been working on a class of browser-based applications which don't require a server.
Calling it PAPPADOM = Portable Application Providing Persistence Atop DOM (Document Object Model)

PAPPADOM is a package consisting of
* Prototype Javascript framework
* Miscellaneous UI components - menubars, menu etc
* Persistence - save stuff

Advantages
* Portable - web-browsers supporting Javascript is all you need
* Open Data - data is stored within the HTML file and hence is accessible.

Examples:
Neptuner UBoat: http://neptuner.googlecode.com/files/demo_uboat_neptuner_0_20.zip
Memonaut: http://memonaut.googlecode.com

Just a fancy name...

Containers: Stick to basic types initially

STL containers may impose a few requirements on your class (say for example, class Student) before they can contain them: like comparison operators, copy-constructors and a whole bunch of other things. This can be rather daunting (not to mention irritating) for the programmer, if his class is not containment-ready just yet and there is no example/documentation at hand: the error-messages are not friendly!

There might be quite a bit of boiler-plate code to add to the class Student before you can use STL containers to contain Student objects. Rather than getting your program’s core functionality up, you may find yourself just plugging in mundane code into your data-types, not to talk about all those strange-looking and mostly unreadable error-messages.

Example:

Say you want to make a grade-report for a group of students. It’s as simple as putting all your student records in an std::multimap, with Grade as key and iterating through the filled in multi-map (which groups the records according to the key).

class Student
{
string m_sName;

RollNumber m_xID;
Grade m_xGrade;
}

Tip 1: Work with pointers to your class. The use of the pointer also makes for better efficiency: no copies of your objects!
multimap<Grade, Student*> gaGradeReport;

Again depending on the contents of the class Grade, the compiler may squeal! It needs a comparison type LessThan before it can work…which brings me to Tip 2…

Tip 2: Use basic data-types for your key in associative containers like std::set, std::map etc. The easiest way to do it is to provide a conversion operator to a basic type for your key class.

multimap<short, Student*> gaGradeReport;

//After providing conversion to short
class Grade{... operator short() {...}}
Implement your program on these lines, get it working and then do the boiler-plate stuff.

Solution:
Here’s how you may do the grade-report task:

//Add the student info

for(..)//Iterate through the student objects one by one
(

 //Get the address of student record in pxStudent 
 gaGradeReport.insert(pair<short, Student*>(short(pxStudent->m_xGrade),pxStudent);

}

//Print the GradeReport multimap
for(..//each grade)
{
  for(..//each record in range)

  {//print the record}
}

Summary:
Work with basic data-types (pointers are basic data-types) for STL containers for more rapid development. Plug in the boiler-plate later.

Schedule Task, View Dependencies

On Win2K+, schedule commands to run

## at "command"

Eg: at 07:45 "shutdown -s"

Shuts down the PC at 7:45 am.

You can view these tasks in Control Panel as well.

On *nix, view shared library dependencies of an executable.

## ldd

Make It Fast!

Sharing a template for an easy to use make file system.

• Self-maintaining: No need for manually adding files.
• Quick-and-dirty: Get started fast!

Here goes:

SOURCE_FILES= $(wildcard *.cpp) ../../commando/sonar/Sonar.cpp
# Automatically gets the file-list from the directory!
# Add extra files from other dirs at the end if needed (Sonar.cpp above)

OBJS=$(patsubst %.cpp, %.o,$(SOURCE_FILES))
# Rule for specifying object file list

# The rest of this is standard make-file stuff   

COMPILER=g++
CFLAGS= -W -g -O0 -fexceptions -finline-functions -D_THREAD_SAFE -fpack-struct=4
#Compiler options  
LIBS= -lboost_filesystem
#Libraries to link to  

SEARCHDIRS = -I../inc -L../lib

#Include and library directories  

TARGET= ../../homebase/linux/nuboat
# Output file  

.PHONY:all
all: $(TARGET)

$(TARGET): $(OBJS)
$(COMPILER) $(CFLAGS) $(SEARCHDIRS) $(GLOBALS) $(OBJS) $(LIBS) -o $(TARGET)

%.o: %.cpp
$(COMPILER) $(CFLAGS) $(SEARCHDIRS) $(GLOBALS) -o $@ -c $<

.PHONY:clean
clean:
-rm -f $(OBJS) $(TARGET)

You can use this so long as you don't have source files floating around in the Makefile's directory, which should not be included in the build.