2. I have written a function to calculate the average of a vector of numbers. It is templated so that it works on any type of value. However is it possible to check if the template type has an addition and division operator and if not, print a compile error message?
My code:

2. The compiler will give you an error. After fixing your code and testing with string, VC++ 7.1 gave this message (among others):

Code:

error C2676: binary '/' : 'std::string' does not define this operator or a
conversion to a type acceptable to the predefined operator

5. Many compilers will optimize the copy away (with RVO - Return Value Optimization). Try it with optimizations enabled (e.g. in Release Build or with -O2) and see if the copy constructor is called. I don't know of any way to force it.

There doesn't seem to be any reason for the compiler to copy the object as it is only being used in the caller function.

There doesn't seem to be any reason for the compiler to not copy the object, since that's what it's supposed to do.
5. A stack is implemented as, well, a stack. You can pass storage for the return value in by reference, or use dynamic memory. Compilers may try to optimize this, but if your classes get just a little complicated, they'll get lost. Yeah, compilers are dumb. Deal with it.
4. "When typeid is applied to classes typeid uses the run-time type information to keep track of the type of dynamic objects." - CPlusPlus.com
3. Boost is open source.
2. The compiler will do it anyway, if you try to use + and /, like std::accumulate and your function do.
1. C++ is not for you. Try Lisp instead.

Thanks for the answers. I wasn't sure if a lot of the stuff I wanted was even possible.

1. Lisp is great. Its unfortunate that c macros aren't as good apparently

2. The main reason I wanted this to happen is so that the error occurs in the caller code, not my code. Then, if a template function is used inside another template functions, it becomes very difficult to track the original cause of the error as the error message generated is huge. For example

Note how hard it is to determine the cause of the compile error: the main method is not mentioned once in the error message but is the method that contained the bug.

4.

When typeid is applied to classes typeid uses the run-time type information to keep track of the type of dynamic objects

Does this mean that for every object, a pointer for that object is kept to point to the rtti information? I understand that that already occurs for derived classes, but what about classes like vector and string, as well as primitive types? I'm just concerned that using typeid will force the compiler to use much more memory than it needs to.

5. Oh well. I mainly needed it for efficiency but it doesn't really matter

Note how hard it is to determine the cause of the compile error: the main method is not mentioned once in the error message but is the method that contained the bug.

You just need to learn to read the error messages. Granted, it's not as easy as it could be. But the first few lines make it obvious the cause is related to class Lame, and the last line actually describes the real cause of the error.

In any event, you might want to do some digging on traits classes. Traits classes are used (in the STL and, incidentally by boost) to enforce conditions that are required for a class to be used with particular conditions. For example, supporting particular conversions. It would probably be possible to use such a technique to enforce a requirement that an expression "a+b" is valid for your type.

Originally Posted by Monkeymagic

Does this mean that for every object, a pointer for that object is kept to point to the rtti information? I understand that that already occurs for derived classes, but what about classes like vector and string, as well as primitive types? I'm just concerned that using typeid will force the compiler to use much more memory than it needs to.

I wouldn't worry about it.

It depends on the compiler and how it implements classes and, naturally, the typeid operator i.e. it's an issue related to quality of implementation of your compiler. Most classes will need to be associated with some information about their type, to support operators like typeid() and dynamic_cast<>. That overhead will normally be there regardless of whether you use those operators, as the compiler can't judge if some other function (eg in another source) will use those operators. So, it is probably something that compiler vendors will optimise very carefully to minimise memory or performance overhead.

Originally Posted by Monkeymagic

5. Oh well. I mainly needed it for efficiency but it doesn't really matter

It is possible to avoid temporaries by careful design. For example, using a += b will avoid a temporary that a = a+b; would introduce by default (and that the compiler would have trouble eliminating for user-defined types, as there is not necessarily a 1-1 correspondence between the += operator and + operator).

You might want to look ip the blitz++ numeric library. It is a C++ template library designed around numerics. It also uses some pretty clever techniques to avoid temporaries (as some of the objects they pass around, such as large matrices) are very costly to copy.

The C++ standard explicitly makes some allowances so that the RVO (and some other optimisations of temporaries out of existance) are feasible. For example, a temporary does not need to be created if the ONLY way of detecting its existance is by tracking constructor and destructor calls. However, again we get in the domain of quality of implementation of compilers: it is up to the compiler vendor as to whether they do that.

1. It is possible to write a macro called JOIN that joins macro arguments together [...] JOIN(std::co,ut <<) "hello";

Yes and no. The result of ## must be a valid preprocessor token, which "std::cout <<" isn't - that's two tokens.
You can join two tokens together if, and only if, the result is a valid token again.

Is it possible to modify these input arguments in the macro. Ie is a macro REVERSE possible

No. The only things you can play with are whitespace, commas and parentheses in the arguments.

2. I have written a function to calculate the average of a vector of numbers. It is templated so that it works on any type of value. However is it possible to check if the template type has an addition and division operator and if not, print a compile error message?

No matter how you turn it, however, until we actually have proper concept support, the error messages will be ugly.

3. In some functions in the boost library, I have noticed that they appear to return a type (eg boost::result_of). How is this possible?

Those are meta-functions. They are "executed" by the compiler. In technical terms, they're just template structs with a nested "type" typedef that is the "result" of the "function".
To learn more about this stuff, read "C++ Template Metaprogramming" by David Abrahams and Aleksey Gurtovoy.

4. How does typeid work internally?

Depends on the compiler.

Is the answer computed at runtime or compile time?

Depends. If the answer can be calculated at compile time, it is. If not, i.e. when using it on an expression that results in a reference to a polymorphic class (a class with at least one virtual function), then it's calculated at runtime.

Also, does using it result in extra memory being used to store type information in classes?

Again, depends on the compiler. Many compiler require you to explicitly enable RTTI before you can use typeid. Some allow you to disable it. If it's enabled, then the additional memory is required for any polymorphic class, no matter if you use typeid or not. For other types, additional memory in the executable may or may not be required, depending on the compiler and whether you use typeid on the type or not.

5. Is it possible to have a function return a stack object without the created stack object being copied and deleted?

No. A stack object goes out of scope, and the programmer can't do anything about it. End of story.
On the other hand, the compiler might do something about it. See RVO and NRVO. But don't rely on this behaviour, because like all optimizations, it's optional.

There doesn't seem to be any reason for the compiler to copy the object as it is only being used in the caller function.

No, strictly speaking, a different object is used in the caller function.

1. Lisp is great. Its unfortunate that c macros aren't as good apparently

Perhaps unfortunate. Perhaps fortunate. Lisp macros have great potential for abuse - even those part of the Common Lisp standard. (For debate, anyone?)
In the end, Lisp macros are Lisp programs executed during compilation and are therefor just as powerful as the language itself. Preprocessor macros are just parametric text replacements.

All the buzzt! CornedBee

"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law