Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 10 Apr 2010
Offline Last Active Dec 17 2012 02:42 PM

Posts I've Made

In Topic: Java Technique: Using static inner class for debug purposes, then bring it ou...

22 November 2012 - 12:14 PM

Why is it difficult to create a completely new, independent class in Java? Personally, I think you'd be better off making it simpler to create new classes than developing techniques to work around how troublesome it is.

In Topic: Try/catch absurdity and calling destructors...

18 October 2012 - 02:14 PM

I think it mentions it (and gives pros and cons) in CodeComplete where it's not really arguing for it's use but just presenting it as something that's sometimes done.

I've tried it a little, and then decided to dismiss it from my own coding - I also don't often mistype = for ==, but maybe if I was switching between multiple languages and had a compiler that doesn't issue a good warning for that mistake, it might be worth doing.

Yoda conditionals are a particular annoyance to me. They're less readable, and are not very useful if you write good tests.

More dangerous is accidentally forgetting to break at the end of a case in a switch. It's rare to test for things that you don't do, so a case that falls through and does something extra might not be caught.

In Topic: Is that way of using constructor really better ?

04 October 2012 - 04:33 PM

If there is a compiler that does not issue a warning when you put initializers out of order, you should switch to one that does.

FYI Visual c++ 2012 does not issue a warning about this with /wall (and 'language extensions' disabled fwiw). I know gcc does, and I agree that it's a useful warning.

Yeah, msvc is the only compiler I know of that doesn't support that warning. For gcc, clang and intel, the flag is -Wreorder.

You could vote for it if you want Microsoft to add it.

In Topic: SFINAE equivalent in C#?

01 October 2012 - 10:49 AM

It seems it would be a pretty silly tradeoff to disallow template specializations in order to allow implicit template type conversions, particularly when the solution to your original problem is so simple:

template<typename ContainerT>
void function(const ContainerT&){}

That would be a reasonable solution if it did not have such a dramatic impact on compilation time, and if it did not require major workarounds to apply to virtual functions.

There are definite advantages to the restrictions C# imposes on its generics.

In Topic: SFINAE equivalent in C#?

28 September 2012 - 08:12 PM

There is no such thing as "const" in C#, so that's a non issue.
However, it's normal that it doesn't work in c++. An array of const objects is not all all the same type as an array of non const objects. You can't expect implicit conversion of those two types.

I could expect it, given that the two objects should have both identical code and data, and one has an interface that is a subset of the other. The fact that it's so difficult to use one in place of the other is just a limitation imposed by poor design choices in the C++ template system.

If it C++ disallowed atrocities like this, the types would be compatible:
struct MyObject{};

template<class T> struct MyTemplateClass {
   T x;

template<> struct MyTemplateClass<const MyObject*>{};

int main()
   MyObject obj;

   MyTemplateClass<MyObject*> i1;
   i1.x= &obj;

   MyTemplateClass<const MyObject*> i2;
   i2.x= &obj; // compile error

Reading through stuff about C# generics, it seems that they maintain restrictions to prevent that sort of thing.