Saturday, October 9, 2010

How do we get Fat?

Since long time I have been thinking about how fat gets creates/stored in our body. I found a very good link on how stuff works which explains exactly how does fat gets stored in our body. this is what I found.

Fat is stored in fat cells, muscle cells and liver cells. The propotion is very less in muscle and liver cells.
The number of fat cells in our body remain same, but as we eat more fatty food, their size increase as they accumulate more fat in them. These cell are usually found under out skin.
My thinking was that fat is created from fatty food only. But I found that our body also converts excess glucose into fat. After we eat food it gets digested in stomach and through intestine, fat and glucose enters blood stream.
Fat cell first prefer to absorb fats from blood stream since that is very easy and less energy consuming (well everybody is entitled to their choices and everybody tends to be lazy :) ) work while converting glucose into fats is longer and energy consuming process so that is not preferred.
If you have 100 extra calories in fat (about 11 grams) floating in your bloodstream, fat cells can store it using only 2.5 calories of energy.
On the other hand, if you have 100 extra calories in glucose (about 25 grams) floating in your bloodstream, it takes 23 calories of energy to convert the glucose into fat and then store it. So what this means is that any extra calorie that goes into our body gets converted into fat.
Well to answer the question in title of the post, its clear that we get fat by eating access to what our body needs and that get deposited as FAT, and keeps on accumulating until our pants start to tightening and we get bigger pant size :) Hope thats not the case. Eat limited and healthy.
Hope this information was helpful to you. Don't forget to put your comments on this article and all credit for the information goes to HowStuffWorks link posted below.

All the information is obtained from HowStuffWorks. Visit there for more detailed information.

Update: I also found a very good video on youtube explaining all that I wrote above.


Monday, September 6, 2010

PIMPL (the beauty marks you will want your libray to have :) )
Private-Implementation is a Software Engineering paradigm which allows us to enhance encapsulation, reduce compilation times and retain binary compatibility. The idea here to add another layer of abstraction between the library and the user code.

The Story
Consider that you are create a library which you will be shipping to customers when done. Since Software is never perfect and always extensible, after you shipped you Version 1.0 you plan to change the way your memory allocator functions . So you start updating the library and ship another version. You don’t change the signature of the function, just the internals. So at the backbox view, everything is same, just the feeling this version would be better than the previous since its Version 2.0. But, there is always a ‘but’, you have to add some private member in the .h file. So along with the Version 2.0 library you also ship update .h file.
Now let’s say that I am one of the users of your great library. I use it to develop UI framework for my mobile device. So now when you release Version 2.0, there are two options for me. Either I stick to older less efficient version of upgrade to 2.0. I decide to upgrade to 2.0, I place the new .h and library to correct location and start compiling my code.
Now to my surprise I see that my complete code base (which is 10000 files big and more that 10,000,000 lines of code, lets assume it) is rebuilding. Now why did that happen. None of your changes affect the way my code works. I mean you didn’t change signature of any of your functions (beware, that’s a very bad practice in ‘Library Developer World’) or add new functionality, you only changed how your ‘new’ and ‘delete’ operators work internally which I don’t care until they do what is advertised. But I see lot of my code being recopiled.

Why PIMPL?
PIMPL helps you avoid the issue by adding an extra layer of abstraction between the application code and library.
Lets say that the name of your library class is Foo. In which you have implemented getMessage(), setMessage(std::string) and printMessage() functions. What PIMPL idiom suggests that you create another class FooImpl in which you have all the members variables and functions of Foo, declared and implemented as if it was Foo, as shown in listing below.

FooImpl.h

#ifndef FOOIMPL_H
#define FOOIMPL_H
class FooImpl
{
public:
FooImpl();
~FooImpl();
void printMessage();
void setMessage(char* );
char* getMessage();
private:
char* m_message;
};
#endif // FOOIMPL_H

FooImpl.cpp

#include "FooImpl.h"
#include "string.h"
#include "stdlib.h"
#include "stdio.h"
FooImpl::FooImpl()
{
}
FooImpl::~FooImpl()
{
}
void FooImpl::setMessage(char* message)
{
m_message=message;
}
char* FooImpl::getMessage()
{
return m_message;
}
void FooImpl::printMessage()
{
printf("%s\n",m_message);
}


Now create another class Foo which will act as abstraction class for FooImpl. Look as code below.

Foo.h

#ifndef FOO_H
#define FOO_H
class FooImpl;
class Foo
{
public:
void printMessage();
void setMessage(char* );
char* getMessage();
Foo();
~Foo();
private:
FooImpl* m_fooImpl; //d_ptr
};
#endif // FOO_H

Foo.cpp

#include "Foo.h"
#include "FooImpl.h"
Foo::Foo(): m_fooImpl(new FooImpl())
{
}
Foo::~Foo()
{
}
void Foo::setMessage(char message[])
{
m_fooImpl->setMessage(message);
}
char* Foo::getMessage()
{
return m_fooImpl->getMessage();
}
void Foo::printMessage()
{
m_fooImpl->printMessage();
}

main.cpp

#include "Foo.h" //no need to include "FooImpl.h"
int main(int argc, char *argv[])
{
char* myMessage="Hello PIMPL";
Foo f;
f.setMessage(myMessage);
f.printMessage();
return 0;
}


Let me quickly explain what is happening in the code.
You access everything in FooImpl class, using private member variable, m_fooImpl of Foo.cpp class. The client or user of the library does know nothing about FooImpl. All he has to do is create an object of Foo class and access its public members as if they were implemented in Foo class.
Now the thing to note here is that any change you make in FooImpl class will not need you to recompile main.cpp or Foo. This helps us to avoid recompiling our code incase of changes in library. And since Foo class doesn’t include any implemention other than pointer indirection to FooImpl.
You can check by copying above code in respective .cpp and .h files and compiling with your favorite compiler. Try to see what files are compile upon changing each file.

But this idiom does have following drawbacks.
  • More work for the implementor.
  • Doesn't work for 'protected' members where access by subclasses is required.
  • Somewhat harder to read code, since some information is no longer in the header file.
  • Run-time performance is slightly compromised due to the pointer indirection, especially if function calls are virtual (branch prediction for indirect branches is generally poor).
References:

Monday, May 3, 2010

Are you afraid of Failure??

The most common reason people don't pursue their dreams is FEAR OF FAILURE. Well in that case below is the list of failure of a very successful person we all know very well (along with some successes also).
  • 1831 - Lost his job
  • 1832 - Defeated in run for Illinois State Legislature
  • 1833 - Failed in business
  • 1834 - Elected to Illinois State Legislature (success)
  • 1835 - Sweetheart died
  • 1836 - Had nervous breakdown
  • 1838 - Defeated in run for Illinois House Speaker
  • 1843 - Defeated in run for nomination for U.S. Congress
  • 1846 - Elected to Congress (success)
  • 1848 - Lost re-nomination
  • 1849 - Rejected for land officer position
  • 1854 - Defeated in run for U.S. Senate
  • 1856 - Defeated in run for nomination for Vice President
  • 1858 - Again defeated in run for U.S. Senate
  • 1860 - Elected President (success)

Select blank space below to see that great person's name

ABRAHAM LINCOLN

Source: failures