Bug Vanquisher

27 January 2008

Yahoo is SO Much Fun!

Filed under: Bugz, Funnier — Tanveer Badar @ 8:21 PM

image

Latest version of Firefox is considered "rare" by Yahoo. Yes "rare" indeed, but the most conformant to web standards of all others out there!

May I point out that new version of Yahoo Mail does not work in FF 3 Beta 2 either, because they try to move nodes from one document to other through whatever arcane non standard method. This should be attempted through importNode or adaptNode.

image

21 January 2008

I Give Up!

Filed under: Rant vs Vent, Things in life — Tanveer Badar @ 7:52 PM

It is my lucky draw. My fate. Something I deserve.

Well, not deserve, but it always happens to me. Whenever I take a day off, the sucky combination of PTCL + KESC comes into action. I hardly get 30 minutes of continuous internet access during that entire day. Whether it is the frequent power failures happening every 30 minutes just to exhaust the UPS or the time it takes DSL modem to sync during those happy minutes when my computer isn’t running off a UPS.

And there are people who still say

سب سے پہلے پاکستان

Not that I ever speak ill of my country, but this is one time just too much. I find that really hard to grasp these days.

So, from now on, there will be no off days from work. At least others won’t suffer the power loss due to me being at home.

20 January 2008

Extreme Meta-programming

Filed under: C++ — Tanveer Badar @ 6:05 PM

“It was one of my most brilliant ideas, and between you and me, that’s saying something….My brain surprises even me sometimes…”

Albus Dumbledore – Harry Potter and The Philosopher’s Stone

What should this quote be doing here. Well I had a similar idea 30 minutes ago, out of which it took 15 minutes to write this post and get the two references. You see, in C++, iterators are a core concept related to streams and container. They may get redesigned a bit in near future (or may already have) but the notion will not change.

At the beginning, there was one, the input_iterator. It can only go forward and be dereferenced only once. Then came, the forward_iterator, it can also only go forward but can be dereferenced multiple times. This evolved into bidirectional_iterator, which can move in either direction and is a forward_iterator. Finally, the chain terminates at random_access_iterator which allows random access, chiefly [ ] and +, -, in addition to being a bidirectional_iterator.

With this background, I was writing a class which needed distinguished behavior depending upon the iterator type specified as a template argument. I thought, and kept thinking about it as to how should I approach the problem. I had already said a big “no” to partially specializing it, or any of the base classes, upon iterator type.

Therefore, the distinguishable functionality now resides in a separate class. I decided not to support input_iterator. Hierarchy starts at forward_iterator and goes hands in hands with other three.

Sorry about the cryptic text, that’s the spirit of C++ I like most.

template< typename iter , typename projection , typename category = std::forward_iterator_tag > class projection_iterator : public std::iterator< category , projection , typename std::iterator_traits< iter >::difference_type , typename std::iterator_traits< iter >::pointer , typename std::iterator_traits< iter >::reference >
{

// things like ++ (pre,post), *, ->, == and !=.

};

// This gets rid of input_iterator. Any attempts to instantiate will result in compile time error of type not defined.

template< typename iter , typename projection > class projection_iterator< iter , projection , std::input_iterator_tag >;

template< typename iter , typename projection > class projection_iterator< iter , projection , std::bidirectional_iterator_tag > : public projection_iterator< iter , projection , std::forward_iterator_tag >
{

// inherits from general class, adds — (pre,post).

};

template< typename iter , typename projection > class projection_iterator< iter , projection , std::random_access_iterator_tag > : public projection_iterator< iter , projection , std::bidirectional_iterator_tag >
{

// inherits from bidirectional_iterator case, adds [ ], +, -.

};

With implementation inheritance, I have reduced the amount of code I would have written otherwise quite drastically.

[Nitpickers corner]

It is still a work in progress. I, most specifically, don’t want any comment from you or bugging me on IM.

17 January 2008

Screw Up. Fixed!

Filed under: Windows Vista — Tanveer Badar @ 11:12 PM

Finally, my Windows Vista installation is up and running again. Only two or three programs of my usual set remain to be installed.

Why the reinstall? Well, I managed to install SP1 RC refresh last week and it didn’t work anymore.

14 January 2008

C++ Needs Serious Variable Inferencing

Filed under: C++ — Tanveer Badar @ 1:40 AM

A little excerpt from a little project of mine.

int array [ 5 ] = { 0 , 1 , 2 , 3 , 4 };
query::as_query( array , array + 5 ).select< query::actions::identity< int* > >( )
    .where( query::actions::condition< query::actions::identity< int* > , std::less< int > >( std::less< int >( ) ) )
    .orderby< query::actions::order< query::actions::condition< query::actions::identity< int* > , std::less< int > > > >( );

Those who can See will notice what is going on here given my history. Apart from that, notice how template arguments have gone out of hand with only three consecutive function calls. Consider the chaos when you bring in the big brothers, groupby, *join, subqueries and so on.

C++ seriously needs variable inferencing. I cannot wait to get my hands on a compiler which supports auto (no pun) type deduction. Above snippet is with no functionality and only compiling on bare bones at the moment. That library isn’t even functional and things will definitely get messier when it actually does something.

[Update]

Some 20 minutes later, the glue has been reduced by a great amount due to clever hard coding to condition in where definition.

query::as_query( array , array + 5 ).select< query::actions::identity< int* > >( )
    .where( std::less< int >( ) )
    .orderby< query::actions::order< query::actions::condition< query::actions::identity< int* > , std::less< int > > > >( );

13 January 2008

To Ref or Not To Ref

Filed under: Dev inside! — Tanveer Badar @ 8:22 PM

Shall I write void func( ref System.Uri ) or void func( System.Uri )?

Should

class something
{
     std::string* ptr;
};

or be done like this

class something
{
     boost::smart_ptr< std::string > ptr;
};

That, people, is the question!

Before answering this question, let us clarify some terms.

1- value semantics: upon assigning an object to another, its bit representation is copied to the assigned object, unless something fancy like copy constructor intervenes.

2- reference semantics: no object really contains what it says but has only a pointer to the actual bit representation, upon assignment this pointer is updated and both objects point to the same location in memory.

3- pass-by-value: parameter initialization obeys value semantics, newly initialized object contains an exact copy of initializer object, unless something fancy like copy constructor intervenes.

4- pass-by-reference: parameter points to the same object as the initializing object and remember the joke in java, I don’t know the current status

void swap( int a , int b )
{
    int temp = a;
    a = b;
    b = temp;
}

5- value types: value type obey value semantics by default but can be made to obey reference semantics by using explicit references or pass-by-reference across function calls.

6- reference types: by default they obey reference semantics and there is no known way to make them obey value semantics without some really fancy coding. This fancy coding typically requires that a reference type may exist in two forms, one mutable and other frozen. When value semantics are required you freeze an object and then, assignments make copies of it instead of setting the underlying pointer. But this requires fancy coding by someone.

The battle between value types and reference types is very much like "Men are from Mars and Women are from Venus’". Each has its merits and demerits. A comparison follows with examples from C++, C# and Java.

Value Types Reference Types

1- Default in C++.

1-Default in almost every other language.

2- Derived objects suffer slicing.

2- References are default.

3- Unnecessary copying, hidden costs.

3- No copying, unless explicitly asked.

4- Copy constructor often necessary, along with assignment and destructor.

4- Copy constructor1 semantically not present.

5- Explicit sharing of objects, no reference counting headaches2.

5- Multi-threading nightmare.

6- Helps in proper resource ownership3.

6- Mad COW4!

7- Function calls have pass-by-value as default.

7- Simulated pass-by-value can be a counter-intuitive.

8- References are step-child5.

8- Values types suffer6 from performance issue.

9- Destructors often have proper semantics.

9- Destructors entirely missing from picture, no deterministic clean-up.

10- Memory management is explicit (C++) or absent (CLR)7.

10- Typically, a garbage collection runs behind the scenes.

11-Nullable values types are often required when interfacing with cross-domain functionality.

11-Not nullable reference types are under active research.

[Nitpicker's corner]
1- Memberwise clone and ICloneable do not have clearly defined semantics, they are even sort of deprecated.
2- I am not talking about COM here, it is only a core language level comparison.
3- RAII idiom.
4- I recommend you read that entire series.
5- I can’t seem to find a reference (no pun) at the moment, but it is impossible to write reference types in C++ as they are implemented in C# or Java.
6- The costs listed on that page may vanish in future, but I have plenty more reasons up my sleeve.
7- Please don’t even get me started on this!

Renovation Week Begins

Filed under: Personal — Tanveer Badar @ 7:41 PM

Actually, it began four hours ago when I finally decided to get a hair cut after four months. Your can imagine how unhappy the barber would be right now.

And after a confessional sort of phone call with Faisal | Usman (& wouldn’t work, they have so little in common), some other matters were sorted out, new decisions were made. We discussed a lot of things.

The problem(s) began some six month ago as far as I can think. I am becoming the laziest kid on the block all this time. My computer sort of stinks with tons of dirt inside because one side is open ever since I bought it. My glasses need changing and eye-sight re-evaluation for three years now. I still haven’t got my degree issued yet. My mouse double triple clicks every time for an year now. Faisal keeps telling me to buy a decent microphone for the last month. I have become the most irritable person in immediate family, reacting the slightest noise in the most obnoxious manner. The list goes on and on.

Considering this list, the first line and the title should make sense now. It is one down, some to go sort of thing. I’ll keep posting these frequent losses of rationality confessions over the next two weeks as things get done.

Screwed!

Filed under: Funnier — Tanveer Badar @ 3:13 PM

My Windows Vista installation, nothing personal. He he he…

I finally managed to get a no boot configuration after repeatedly trying to install Windows Vista SP1 RC refresh (yes, that’s the official name). Finally, after wasting 90 minutes and constantly staring at "Reverting changes", I hit the reset button and it does not boot anymore.

10 January 2008

Application+WPF=Sexy Experience!

Filed under: WPF — Tanveer Badar @ 11:02 PM

I don’t talk like that, ever. But the application deserves that.

http://www.frogdesign.com/case-study/lawson-smart-client.html

DO NOT PROCEED

Filed under: Fun — Tanveer Badar @ 10:19 PM

Feel free to click if you have 10 minutes!

"The thing inside"

Older Posts »

Blog at WordPress.com.