oOzone

Wednesday, June 09, 2010

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;
}

Saturday, May 29, 2010

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

Saturday, February 20, 2010

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...

Friday, February 12, 2010

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.

Thursday, January 28, 2010

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

Sunday, January 17, 2010

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.

Sunday, December 13, 2009

Neptuner Coding Guidelines

==========================
NEPTUNER Coding Guidelines
- sonofdelphi
2009-12-13
2008-12-16
==========================

* To enable faster coding with an IDE
* To enable better debugging, no guessing what a variable is!

Variable naming
================

Variables are named as:


Scope Modifier
* Member variables start with m_
* Global variables start with g_
* Function Parameters start with "in_"
* Local variables don't have a scope modifier

Indirection Modifier
* Pointer variables start with p
* Reference variables start with r
* Other variables don't have an indirection modifier

Aggregation Modifier
* a - aggregates (arrays, vectors, lists etc)
* Plain variables don't have an aggregation modifier

Usage Modifier
* n - used for counting
* s - used as string
* c - character
* b - used as boolean
* f - used as a function. Deprecated though.
* e - enumeration types
* x - other structs, x = Complex = non-simple
* Other types (what are they?:-) don't have a usage modifier.

Indentation
=============
* Use a single indent for every {} block.

* { and } should be on new lines, at the same indentation level as the conditional.
Eg:
if(someCondition)
{
 statement1;
 statement2;
}

* Single line conditionals need not have {} marking.
  But make sure you indent the single statement.

Type naming
=============
* Follow TitleCasing for user-defined types - classes, structs, enums.
Eg:
class Student
{
 string m_sName;
 int    m_nMarks;
};

Function naming
================
* Functions should follow camelCase.
* The first word of a function should be a verb.
Eg: doSomeThing()

Pseudoclass functions
======================
* For C-style module functions, name as ModuleName_
Eg: Neptuner_addStuff

Hide details

Change log

r386 by sonofdelphi on Jan 26, 2010 Diff

dos2unix lineendings

Go to:

Double click a line to add a comment

Older revisions

r378 by sonofdelphi on Dec 20, 2009 Diff

r181 by sonofdelphi on Oct 10, 2009 Diff

r161 by sonofdelphi on Oct 09, 2009 Diff

All revisions of this file

File info

Size: 1790 bytes, 77 lines

View raw file

Wednesday, September 16, 2009

I Could Have Done It Too

With application development, the question is not whether you could have done it; it's whether you did it at all.

Do you believe in your idea enough to invest the time and the effort it takes to do it?

Monday, June 29, 2009

Thomanujan Number - 1229

INVALID POST
Thanks to Jeswin for pointing out bug in code.
:S :( Sheepish smile

Wednesday, May 27, 2009

Baseline Semantics

The term Baseline can often be a source of confusion.

In my experience with Configuration Management and other tools (Microsoft Project etc), a baseline is anything “that can serve as a basis for comparison” – this may or may not be approved. SVN, in fact, skirts this baseline issue by defining the alternate terminology “tag” for the same thing!

I believe our problems stem from the–

1) Informal use of baseline as a verb, with the meaning ‘to approve’.

2) Lack of formalization of what type of baseline (and there are many kinds, refer below!) we refer to when we generically use the term baseline

References

Dictionary definition:

Noun: baseline

1. An imaginary line or standard by which things are measured or compared

(TJ: Other meanings for sake of completeness, also note “imaginary” J in 1)

2. The back line bounding each end of a tennis or handball court; when serving the server must not step over this line

3. The lines a baseball player must follow while running the bases

Wikipedia mentions:

Generally, a baseline may be a single work product, or set of work products that can be used as a logical basis for comparison. A baseline may also be established (whose work products meet certain criteria) as the basis for subsequent select activities. Such activities may be attributed with formal approval.

There are different kinds of baselines (from Wikipedia).

Functional Baseline: initial specifications established; contract, etc. Allocated Baseline: state of work products once requirements are approved

Developmental Baseline: state of work products amid development

Product Baseline: contains the releasable contents of the project

Others, based upon proprietary business practices

CMMi itself defines it multiply as (from CMMi-DEV 1.2 )

A baseline is a set of specifications or work products that has been formally reviewed and agreed on, that thereafter serves as the basis for further development or delivery, and that can be changed only through change control procedures. A baseline represents the assignment of an identifier to a configuration item or a collection of configuration items and associated entities. As a product evolves, several baselines may be used to control its development and testing.

For Systems Engineering

One common set of baselines includes the system-level requirements, system-element-level design requirements, and the product definition at the end of development/beginning of production. These are typically referred to as the “functional baseline,” “allocated baseline,” and “product baseline.”

For Software Engineering

A software baseline can be a set of requirements, design, source code files and the associated executable code, build files, and user documentation (associated entities) that have been assigned a unique identifier.

TJ:

In my opinion, attaching extra, “holy” meanings to an-already polymorphic word would not be appropriate. It would be a classic case of jargon-clash and would lead to inter-personal communication problems and possibly conflict!

It would also mean an incurrence of training (un-training) overhead and would be the proverbial seed for discontent in a new adopter.

Thursday, January 01, 2009

INTEGRATE – 2008 - Changes done for 2K9

0 error(s), 0 warning(s), 1 greeting(s)

Wish you a Happy New Year!

Log attached.

Sunday, December 14, 2008

Recipe - Do Something To Each File In Directory

This one is a real life-saver!

To do the same operation on each file, in Windows, you can use the for command.
for /F %i in ('dir *.dbg /s/b ') do @del %i

The above example deletes all *.dbg files under the current directory

Explanation
for /F %i ......... for each %i
in('dir *.dbg /s/b ') ..... in the list returned by the command. dir /s specifies a recursive search, /b causes it to to output just a list, without the file details
do @del %i ...... del %i is the command to delete the file. @ suppresses the display of the command

Recipe Syntax
for /F {%var} in ('{list-builder-command}') do {action-command}