Bug Vanquisher

4 November 2007


Filed under: C++ — Tanveer Badar @ 7:57 PM

I am very happy to announce that CPPCodeProvider is almost complete in implementation. The first beta release will be available at the download site shortly, hosted by source forge. And as time is passing, this post is becoming more and more of a wish list than some sort of release notes. A separate post on current bugs follows.

The reason it took so long to complete was due to me being lazy. The last functions were the largest to write, the hardest to work out and most important, without them it was impossible to write out a user defined type.

Also, I have done some more prettification for final code rendering. A bug which lay undiscovered so far has been fixed. It involved instantiating a type with bool which was not recognized and threw invalid_argument exception.

Two things I would like to note are: I have made the way code is indented in the output stream(s). Each class now dictates its own indentation by using tabs argument and no one else does that work for it. Additionally, if any CodeObject needs to have newline rendered after it, that newline must be rendered by the calling code because most of the time, it is out of context to know if a newline will not disturb the indentation and formatting.

After these two changes there should be no formatting problems as far as I can say. However, if you do see something messed up missing newlines or incorrect indentation, drop me a line on sourceforge about that specific CodeObject and if possible, some CodeDOM to reproduce the issue.

One more thing to note is the behavior of constructors of copying_pointer. Both constructors which take T* and T& own the passed argument. Therefore, be very careful if you do this:

copying_pointer< T > a( new T ) , b( *a );

This line will cause T to be deleted twice and if you are lucky this will be caught during debug builds. Correct way is to write

copying_pointer< T > a( new T ) , b( a );

because the copy constructor makes a copy of passed argument, hence no ownership issues. Similarly, UDT will own the destructor assigned to it. Be careful with that after memory leak is fixed.

I am also working on efficiently implementing BasicType. It’s purpose is to model primitive types which are only handful and rarely change. Therefore, it would be wise to have a cache of BasicType which handed out an object given the type name. But I will need to further investigate as it will undoubtedly introduce race conditions during cache initialization.

Also, next time there will be support to indent using either tabs or space.

It Had Nothing To Do With Pakistan

Filed under: Fun — Tanveer Badar @ 2:06 AM


3 November 2007

مزید پیار بھرے بول

Filed under: Funnier — Tanveer Badar @ 10:28 PM


پیار تو ہونا ہی تھا

Filed under: Fun — Tanveer Badar @ 8:35 PM

Living under emergency. :)




Building The Tools

Filed under: Computer Theory, Dev inside! — Tanveer Badar @ 1:12 PM

Connected with the extremely twisted last post, consider the methods of programming the machines we have seen since 1943. Let us build a hierarchy of tools we use for programming and how they must have come to be what they are right now.

ENIAC was programmed using rewiring and four years later than that for ROM function tables. Only six women programmed it. Compilers existed long before that. Assemblers came out a little late. We see the first portable programming language in 1972. High level languages soon follow, my first love enters the picture, the world is swarming with all sorts of OO and high level languages by mid 1980s. Declarative languages add to the mix at this time too. Right now, we are partying on very expressive programming environments.

Grab Visual C++ compiler, the language I use most. Or better yet csc.exe. Consider how that compiler itself must have been built. If you have seen rotor, you will know that csc itself is written in C++. Therefore, it will require a C++ compiler, definitely cl.exe because of this. Put cl.exe into the interrogation box and ask the same question, who is your mother? It will say cl.exe with a build number or version number smaller than mine.

But this isn’t a chicken and egg problem because it must have begun at the first build of cl.exe. Let’s say it was compiled with a C compiler. Then, who was the mother of that compiler? Some earlier C compiler. Who gave birth to that first one? An assembler is the most likely answer, say masm.exe. The question repeats itself, only this time in the context of assemblers. First assembler would have built the second and itself must have been built by some machine which required programming by re-wiring (only a guess, I have no proof :)).

This machine may have built a few assemblers. Those assemblers must have boot-strapped themselves and eventually one of them may have become powerful enough to build a C compiler. (Actually, from what I just read, it goes way back than that assumption. C was a transformation of B which had a compiler who origin was in BCPL’s compiler. But let us again skip the details and say BCPL compiler may have been built with an assembler.)

This early compiler must have boot-strapped itself too and built more powerful versions of it and other compilers. Definite proof for this is the C-front, first compiler for C++ which produced C code as a result which was compiled and executed. The process has been bootstrapping itself ever since and giving rise to more and more language compilers of all sort and hence, we trace the path from root to csc.exe!

If you look carefully, you will find my favorite data structure here too. Conceptually, ENIAC or something similar lies at the root. At every level, a transformation program (assemblers/compilers) is either boot-strapping itself or increase the set of available transformation programs at the next level. From ENIAC, we move to a decent number of assemblers, which boot-strap themselves to assemble BCPL (again, my hypothesis) compiler. BCPL compiler compiles B compiler which boot-straps itself and generates a C compiler. This C compiler again bootstraps and really makes the bomb go off by giving rise to other C compilers and C-front. And again, the rest is history.


Filed under: Computer Theory — Tanveer Badar @ 1:08 PM

It must have begin with the first ever Abacus. One of the earliest machines to help us compute. Although primitive but really effective. Even if you do not include a concept of ‘0’ in your numerals.

Over millennia, we moved forward to faster, automated computing machines. ENIAC was born. But limited in programmability and never reproduced. Remember it is still 1943 and the design has been locked. First ever compiler makes to the front for Mark 1 in the same year. No stored program concept till 30/06/1945, machine programmability is very limited. Universal Turing Machines are still 4 years away. Even with the concept of UTM in 1948, it takes one more year for human eyes to see the first ever symbolic assembler.

Therefore, let me change the title to


Let’s fast forward the boring details and link leaden paragraphs to 1972. This year is significant because it marks the turning point in programming languages and will change the flow of events forever. We see ‘C‘ being born and the rest is history.

I am laying the ground for another post with this extremely brief history, many twisted details (some by me, for brevity’s sake), and left out milestones (again my apologies).

2 November 2007

True Face

Filed under: Uncategorized — Tanveer Badar @ 6:32 AM

« Newer Posts

Blog at WordPress.com.