Posted by splakhani at 7:01 PM
Posted by splakhani at 7:02 PM
6. Don't use namespace facility.
Support of namespaces (through the namespace and using keywords) is a relatively new C++ feature, and not supported in many compilers. Don't use it.
7. main() must be in a C++ file.
The first C++ compiler, Cfront, was in fact a very fancy preprocessor for a C compiler. Cfront reads the C++ code, and generates C code that would do the same thing. C++ and C startup sequences are different (for example static constructor functions must be called for C++), and Cfront implements this special startup by noticing the function called "main()", converting it to something else (like "__cpp__main()"), adding another main() that does the special C++ startup things and then calls the original function. Of course for all this to work, Cfront needs to see the main() function, hence main() must be in a C++ file. Most compilers lifted this restriction years ago, and deal with the C++ special initialization duties as a linker issue. But there are a few commercial compilers shipping that are still based on Cfront: HP, and SCO, are examples.
So the workaround is quite simple. Make sure that main() is in a C++ file. On the Unix version of Mozilla, we did this by adding a new C++ file which has only a few lines of code, and calls the main main() which is actually in a C file.
8. Use the common denominator between members of a C/C++ compiler family.
For many of the compiler families we use, the implementation of the C and C++ compilers are completely different, sometimes this means that there are things you can do in the C language, that you cannot do in the C++ language on the same machine. One example is the 'long long' type. On some systems (IBM's compiler used to be one, but I think it's better now), the C compiler supports long long, while the C++ compiler does not. This can make porting a pain, as often times these types are in header files shared between C and C++ files. The only thing you can do is to go with the common denominator that both compilers support. In the special case of long long, we developed a set of macros for supporting 64 bit integers when the long long type is not available. We have to use these macros if either the C or the C++ compiler does not support the special 64 bit type.
9. Don't put C++ comments in C code.
The quickest way to raise the blood pressure of a Netscape Unix engineer is to put C++ comments (// comments) into C files. Yes, this might work on your Microsoft Visual C compiler, but it's wrong, and is not supported by the vast majority of C compilers in the world. Just do not go there.
Many header files will be included by C files and included by C++ files. We think it's a good idea to apply this same rule to those headers. Don't put C++ comments in header files included in C files. You might argue that you could use C++ style comments inside #ifdef __cplusplus blocks, but we are not convinced that is always going to work (some compilers have weird interactions between comment stripping and pre-processing), and it hardly seems worth the effort. Just stick to C style /**/ comments for any header file that is ever likely to be included by a C file.
10. Don't put carriage returns in XP code.
While this is not specific to C++, we have seen this as more of an issue with C++ compilers, see Use the common denominator between members of a C/C++ compiler family. In particular, it causes bustage on at least the IRIX native compiler.
On unix systems, the standard end of line character is line feed ('\n'). The standard on many PC editors is carriage return and line feed ("\r\n"), while the standard on Mac is carriage return ("\r"). The PC compilers seem to be happy either way, but some Unix compilers just choke when they see a carriage return (they do not recognize the character as white space). So, we have a rule that you cannot check in carriage returns into any cross platform code. This rule is not enforced on the Windows front end code, as that code is only ever compiled on a PC. The Mac compilers seem to be happy either way, but the same rule applies as for the PC - no carriage returns in cross platform code.
MacCVS, WinCVS, and cygwin CVS when configured to use DOS line endings automatically convert to and from platform line endings, so you don't need to worry. However, if you use cygwin CVS configured for Unix line endings, or command line cvs on Mac OS X, you need to be somewhat careful.
11. Put a new line at end-of-file.
Not having a new-line char at the end of file breaks .h files with the Sun WorkShop compiler and it breaks .cpp files on HP.
Posted by splakhani at 6:58 PM
Posted by splakhani at 6:54 PM
Loop jamming
Never use two loops where one will suffice:
for(i=0; i<100; i++)
{
stuff();
}
for(i=0; i<100; i++)
{
morestuff();
}
It would be better to do:
for(i=0; i<100; i++)
{
stuff();
morestuff();
}
Note, however, that if you do a lot of work in the loop, it might not fit into your processor's instruction cache. In this case, two separate loops may actually be faster as each one can run completely in the cache.
--------------------------------------------------------------------------------
Faster for() loops
Simple but effective.
Ordinarily, you would code a simple for() loop like this:
for( i=0; i<10; i++){ ... }
i loops through the values 0,1,2,3,4,5,6,7,8,9
If you don't care about the order of the loop counter, you can do this instead:
for( i=10; i--; ) { ... }
Using this code, i loops through the values 9,8,7,6,5,4,3,2,1,0, and the loop should be faster.
This works because it is quicker to process "i--" as the test condition, which says "is i non-zero? If so, decrement it and continue.".
For the original code, the processor has to calculate "subtract i from 10. Is the result non-zero? if so, increment i and continue.". In tight loops, this make a considerable difference.
The syntax is a little strange, put is perfectly legal. The third statement in the loop is optional (an infinite loop would be written as "for( ; ; )" ). The same effect could also be gained by coding:
for(i=10; i; i--){}
or (to expand it further)
for(i=10; i!=0; i--){}
The only things you have to be careful of are remembering that the loop stops at 0 (so if you wanted to loop from 50-80, this wouldn't work), and the loop counter goes backwards.It's easy to get caught out if your code relies on an ascending loop counter.
--------------------------------------------------------------------------------
switch() instead of if...else...
For large decisions involving if...else...else..., like this:
if( val == 1)
dostuff1();
else if (val == 2)
dostuff2();
else if (val == 3)
dostuff3();
it may be faster to use a switch:
switch( val )
{
case 1: dostuff1(); break;
case 2: dostuff2(); break;
case 3: dostuff3(); break;
}
In the if() statement, if the last case is required, all the previous ones will be tested first. The switch lets us cut out this extra work. If you have to use a big if..else.. statement, test the most likely cases first.
Posted by splakhani at 10:54 AM
Posted by splakhani at 10:44 AM
Posted by splakhani at 6:37 PM
Posted by splakhani at 6:29 PM
1) Which is the parameter that is added to every non-static member function when it is called?
---------------------------------------------------------------------------------------
2)
class base
{
public:
int bval;
base(){ bval=0;}
};
class deri:public base
{
public:
int dval;
deri(){ dval=1;}
};
void SomeFunc(base *arr,int size)
{
for(int i=0; i <>bval;
cout << endl; } int main() { base BaseArr[5]; SomeFunc(BaseArr,5); deri DeriArr[5]; SomeFunc(DeriArr,5); }
---------------------------------------------------------------------------------------
3)
class base { public: void baseFun(){ cout << "from base" <<>baseFun();
}
int main()
{
base baseObject;
SomeFunc(&baseObject);
Deri deriObject;
SomeFunc(&deriObject);
}
---------------------------------------------------------------------------------------
4)
class base
{
public:
virtual void baseFun(){ cout << "from base" <<>baseFun();
}
int main()
{
base baseObject;
SomeFunc(&baseObject);
Deri deriObject;
SomeFunc(&deriObject);
}
---------------------------------------------------------------------------------------
5)
class some
{
public:
~some()
{
cout << "some's destructor" << endl; } }; void main() { some s; s.~some(); } ---------------------------------------------------------------------------------------
6) #include class fig2d { int dim1; int dim2; public: fig2d() { dim1=5; dim2=6;} virtual void operator<<(ostream & rhs); }; void fig2d::operator<<(ostream &rhs) { rhs <<>dim1 <<" "<
}
*/
void main()
{
fig2d obj1;
// fig3d obj2;
obj1 << cout; // obj2 << cout; }
return true;
else
return false;
}
int main()
{
complex c1;
cout << c1;
}
Class complex
{
double re;
double im;
public:
complex() : re(0),im(0) {}
complex(double n) { re=n,im=n;};
complex(int m,int n) { re=m,im=n;}
void print() { cout << re; cout << im;}
};
void main()
{
complex c3;
double i=5;
c3 = i;
c3.print();
}
00000
2. 01010
3. from base
from base
4. from base
from Derived
5. some's destructor
some's destructor
6. 5 6
7. Runtime Error: Stack Overflow
8. Garbage value
9. 5,5
Posted by splakhani at 5:01 PM
Question :: Read below code and answer the following questions. LINE Contains 50 char * b, q, *r; 200 b=getbuf(); 201 q = *b; 212 r= anotherfunction(b); 213-300 /* we want to use ‘q’ and ‘r’ here*/ 2000 char * getbuf() 2001 { 2002 char buff[8]; 2003-2050 /* unspecified, buff defined here *./ 2051 return (char *) buff; 2052 }
1. What will be in variable ‘q’ after line 201 is executed? Under what conditions might this not be so?
Answer:
2. Is there an alternative, but equivalent, way to write line 2000? If so, what is it?
Answer:
3. Is getbuf() a reasonable function?
Answer:
4. Will getbuf() execute at all?
Answer:
5. Please comment on line 2051.
Answer:
6. Is getbuf() good practice, and why?
Answer:
7. What line not given should be provided for compilation?
Answer :
Posted by splakhani at 4:50 PM
Posted by splakhani at 7:13 PM
Posted by splakhani at 7:02 PM
Posted by splakhani at 6:55 PM
Posted by splakhani at 6:21 PM