Quote:Original post by Daaark
Heaven forbid that someone should try to objectively point out a flaw in something that they have put on a pedestal.

If you had done so objectively I wouldn't have complained.

PS - Thanks for the vote of "confidence". Very mature.

Quote:

Quote:All user defined objects having type pointers that mightn't be needed, thus wasting memory.

C# has structs which are value types.

Not all the items on my list related to all modern programming languages. Here I was referring to Java, although that's not really such a modern language anymore. Of course Java also has many other ways to waste heap memory.
I probably should've listed the languages I was referring to beside the points, except I'd was scared I'd make mistakes :)

Quote:The most efficient JIT theoretically is slower than the most efficient fully-precompiled code.

I should have qualified this by saying that if the important loops in your code are larger than the code cache this may not be true. But with modern caches in PCs it should be true, as I'm pretty sure that cache is growing faster than the size of the important code that's taking up 90% of CPU cycles. Maybe you'll miss L1 a few more times, but I'd think JIT'd have problems staying in L1 also.

For the int foo<int>(int x) { .... } specialization there is an optimal solution for the given architecture, regardless of where in the program it's called, right? (I guess it's not for some exceptional cases). Theoretically a C++ compiler isn't prevented from finding the optimal solution. A JIT might also find the best solution, but it has to also perform code generation during runtime, hence it has a theoretically worse best case. (This is also ignoring compile-time inlining, and the fact that a JIT has far less time to optimize code).

I'm not sure if compliant C++ is allowed to do SMC, where it could for example write variables into for-loop machine-code as immediates - I guess A JIT could do this. But if C++ is allowed to do so then theoretically the best C++ compiler won't be any slower for these circumstances either.




As for array bounds checking, my primary concern isn't the cycles it takes to compare the size with the index, it's the memory used in storing the size. I've used deep binary trees where nodes have a node* child[2] member. With bounds checking you'd be wasting 1 integer per node right? Which in the case of my AVL tree demo (when I add an int to node) increases my memory usage by around 15%. Granted my AVL tree demo was only used to prove a point and isn't the best real-world solution, but you get the idea.

Also, small things like this will build up if we accept them. How about integer overflow checks? Checking that unallocated memory isn't read? That delete() is always called on valid pointers? Each of these might have only a small performance hit, but they'll all add up. And the above only help fallible coders :)
I'm all for testing my code with these options on, but on principle I think releases shouldn't be expected to do these.




Finally I can say that IMO the buggiest apps I see these days are usually done in modern languages - but perhaps this is because poorer programmers prefer them. This is also just a gut feeling.

Quote:Original post by Promit

Quote:Original post by yacwroy

Quote:The most efficient JIT theoretically is slower than the most efficient fully-precompiled code.

I should have qualified this by saying that if the important loops in your code are larger than the code cache this may not be true. But with modern caches in PCs it should be true, as I'm pretty sure that cache is growing faster than the size of the important code that's taking up 90% of CPU cycles. Maybe you'll miss L1 a few more times, but I'd think JIT'd have problems staying in L1 also.

That was completely nonsensical. Try again.

Ok it's quite misleading sorry. JITs are pretty unlikely to dispose of and repeatedly regenerate functions.

I was just thinking in the purely abstract theoretical sense that a JIT _could_ technically save you code space by only generating code when it's needed and disposing of it afterwards, thus saving space if you're that constrained. I doubt this would be done.
But it was a pretty poor explanation since it didn't make much sense outside the above context.

edit: posted too early.

Whats wrong with using boost::shared_ptr<>, boost::array<>, boost::shared_array<>.

The only grip I have with C++ is that the arrays don't have knowledge of their own size/length/count, as where C# does. Since there is really no way of getting the size of an array pointer. But you can on normal arrays by using sizeof(array) / sizeof(unsigned) etc.

C++0x is adding a ton of new useful features into C++. Like right now GCC's next main version 4.4.0 adds strongly typed enums just like C# has except its enum class Foo : unsigned int, etc. There is varadic templates, soon to be partial support of a GC which is displayed on the C++0x status of GCC. Actually, In my honest opinion and this is just an opinion cause I don't count as everyone. GCC's compiler is far better than MSVC's. I've used both and rather use GCC.

The other grip I have for C++ is that and I've ran into the problem. When a header has a global define like for clamp() in devIL for example. My vector2,3,4 class has a function called clamp(). And if I don't do #undef clamp before including my Vector headers, well at least on MSVC it doesn't give you no details of that happening. It has no scope of it. Which should be fixed in my opinion. I haven't tested it in GCC yet. Also had this same annoying problem with min/max of win32 which probably everyone ran into and go tired of doing #define NOMINMAX etc. And the header guards and the class Foo; crap also.

And until mono has better support for C# on all systems. I won't touch C# until then. There is no point.