compile-time

I am currently learning Haskell, and there is one thing that baffles me: When I build a complex expression (whose computation will take some time) and this expression is constant (meaning it is build only of known, hard coded values), the expression is not evaluated at compile time. Comming from a C/C++ background I am used to such kind of optimization. What is the reason to NOT perform such optimization (by default) in Haskell / GHC ? What are the advantages, if any? data Tree a = EmptyTree | Node a (Tree a) (Tree a) deriving (Show, Read, Eq) elementToTree :: a -> Tree a elementToTree x =

We've all heard the warnings that if you invoke undefined behaviour in C or C++, anything at all can happen. Is this limited to any runtime behaviour at all , or does this also include any compile-time behaviour? In particular, is a compiler, upon encountering a construct that invokes undefined behaviour, allowed to reject the code (in the absence of other requirements in the standard to do so), or even to crash? Filip Roséen - refp " You're all ignoring the actual definition and focusing on the note, The standard imposes no requirements . " - @ R.MartinhoFernandes The message above was

I have a symbol table implemented as a std::map . For the value, there is no way to legitimately construct an instance of the value type via a default constructor. However if I don't provide a default constructor, I get a compiler error and if I make the constructor assert, my program compile just fine but crashes inside of map<K,V>::operator [] if I try to use it to add a new member. Is there a way I can get C++ to disallow map[k] as an l-value at compile time (while allowing it as an r-value)? BTW: I know I can insert into the map using Map.insert(map<K,V>::value_type(k,v)) . Edit: several

I was excited when constexpr was introduced in C++11, but I unfortunately made optimistic assumptions about its usefulness. I assumed that we could use constexpr anywhere to catch literal compile-time constants or any constexpr result of a literal compile-time constant, including something like this: constexpr float MyMin(constexpr float a, constexpr float b) { return a<b?a:b; } Because qualifying a function's return type only as constexpr does not limit its usage to compile-time, and must also be callable at runtime, I figured that this would be a way to ensure that MyMin can only ever be

I tend to use math functions of constant expressions for convinience and coherence (i.e log(x)/log(2) instead of log(x)/0.3... ). Since these functions aren't actually a part of the language itself, neither are they defined in math.h (only declared), will the constant ones get precalculated at compile time, or will they be wastefully calculated at runtime? Some compilers will evaluate them at compile time, but this behavior is not guaranteed (and doing so may also cause problems). You'll need to check your compiler and see what it does. Note that on many systems, log(2) is available from the

A few days ago I asked by which criteria the compiler decides whether or not, to compute a constexpr function during compile time. When does a constexpr function get evaluated at compile time? As it turns out, a constexpr is only evaluated during compile-time, if all parameters are constant expressions and the variable you are assigning it to is are constant expression as well. template<typename base_t, typename expo_t> constexpr base_t POW(base_t base, expo_t expo) { return (expo != 0 )? base * POW(base, expo -1) : 1; } template<typename T> void foobar(T val) { std::cout << val << std::endl;