References:
References are just hidden pointers (not pointers to pointers), and these two functions are nearly identical in performance, are they not?
void function1(int& x)
{
x += x;
x += 3;
x *= 2;
}
void function2(int* p)
{
*p += *p;
*p += 3;
*p *= 2;
}
References basically just provide syntactic sugar. Because of the differences in syntax, pointers and references cannot be interchanged. Here''s an excerpt from MSDN 6.0a:
quote:
Excerpt from MSDN 6.0a
Reference Operator: &
decl-specifiers & cv-qualifier-listopt dname;
A reference is a 16-bit or 32-bit quantity that holds the address of an object but behaves syntactically like that object. A reference declaration consists of an (optional) list of specifiers followed by a reference declarator.
In C++, any object whose address can be converted to a given pointer type can also be converted to the analogous reference type. For example, any object whose address can be converted to type char * can also be converted to type char &. No constructors or class conversion functions are called to make a conversion to a reference type.
References are also great for inline functions:
template <typename pointer_type>
inline void safe_delete(pointer_type& pointer)
{
delete pointer;
pointer = NULL;
}
That code allows you to treat "pointer" as the actual pointer, rather than dealing with the messy pointer-to-pointer syntax.
(now assuming 32-bit memory addressing...)
Since references are just hidden pointers, creating a reference (4-byte hidden pointer) to a char parameter to use it as a reference doesn''t make much sense. That approach would require 400% more memory, or 1/5 (sizeof(char)/total usage). It would also hamper performance, because you must access the variable indirectly (via a pointer). That''s why passing by value is the default: simple, fast, and efficient with the intrinsic types.
For large objects, the use of pointers (and thus references) is justified by the reduction of the parameter to 4 bytes. That is, if the object you wish to pass is 128 bytes, then a reference (4-byte hidden pointer) doesn''t make much difference; the increase would be a little more than 1.03%, which reduces the amount of memory required for that object copy by about 96.77% (120/124 bytes).
For small types, like the intrinsic types, the additional cost of using a pointer (both speed and memory) is not going to be justified; your purpose would probably be better served to simply widen the scope of the variable, making it a namespace variable or a module variable, which would eliminate manipulating the function''s local stack altogether.
Keyword auto:
I think that the auto keyword is a left-over from the days when the stack was considered slow. You had to explicitly declare stack variables as "auto."
Private derivation:
class A : B is allowing objects of type B to be transferred to functions requiring objects of type A, and the private keyword indicates that the interface of the derived class is totally different from that of the base.
Overloaded operators:
quote:
Original post by RWarden
In fact I refuse to use iostream simply for that reason.. when I see >> I see a right shift, not stream input!
Why do you expect the << operator to act the same on both ints and iostreams?
That''s just not feasible. Operators were created by humans as short-hand notation for the properties of the data types involved. Operators are overloaded in both algebra and C with different number types - saying they shouldn''t be overloaded seems rather silly. If you check a good algebra text on the subject, you''ll find that the "laws" like commutative and associative are just properties of the data types involved, not common to the operators. Check out matrix math for an example of this. Different data types require different implementations for their operators, and operator overloading seems like the only non-redundant way to do it.
Look at the following expressions:
int x = 5, y = 10;
int z = x + y;
Without operator overloading, I see only two ways in which those statements could exist in any language: either reserve the + operator only for ints, or make different names for each operator for each type, like:
int x int_assign 5, y int_assign 10;
int z int_assign x int_addition y;
which seems redundant...shouldn''t the compiler know the types already? What is the use of type-checking, if not to control the way data is stored, and the operations on that data? That''s what data types are all about. Function/operator overloading is just a very clean way of doing it.
The difference between C and C++ operator overloading lies in C''s limitation. The only fully functional types that C allows are the intrinsic types. C structures were merely a way of grouping data together - they constitute a severely limited type (no special functions, no constructors, no cast operators, no overloaded operators, etc. nothing like the intrinsic types). In C++, a type is anything that you can define with class, and class-defined types have all the capabilities available to them that the intrinsic types have in both C and C++. That''s why user-defined operator overloading exists in C++.
gimp: The for() loop scoping rules are new - VC is not new.
BTW, you can emulate it if you want:
void main(void)
{
{
for( int A = 0; A < 10; A++){}
}
//later
{
for( int A = 0; A < 10; A++){}
}
}
But that''s kind of messy...
-
null_pointerSabre Multimedia
