next »

[teomat]

strange stuff

I had something similar happening in my code only a few weeks ago, involving a static object which did some stuff (a lot of stuff, it was my entity manager) and serialization.
Some classes were holding a reference to that static object (because I'm lazy and had to write less that way) and after deserializing I created a new instance of it.
But some objects still had a reference to the old one and were using that one. Caused lots of weird bugs (which made no sense at all), sounds similar to what you got there.

[increpare]

Spent all day trying to make progress with my sfxr stuff, realized I'd need to put in a new list to panel Y that had similar functionality to the list in panel X.  Several minutes later I find myself copying and pasting vast swathes of code.  I'm too tired to refactor right now, but not terribly happy about it...

[zacaj]

I had that problem too, turned out my string class was allocating one byte too few, and then attempting to write to that byte, overwriting all kinds of stuff

[increpare]

Hiking up a big hill of bugs.  Hope I get on the downward slope sometime today...

edit: hate writing buggy, unstable software ... this is not my favoured approach to development.

[ghosted]

Well, I've gotten to the bottom of the issues that I mentioned the other day, which have been stalling progress for a few weeks now. I should be posting in the Happy Programmer thread except for the simple reason is that my own idiocy was to blame. Strange movement, entities not updating, failing editor behaviour and all in only Release mode. I was convinced the compiler was doing something silly or I was writing to memory I shouldn't have. The truth...

I'd forgotten to initialise 1 variable and 1 array.

This is my confession - I am a chump.


Thanks for all the suggestions guys. It was the stories of silly mistakes that forced me to take a second glance at the simple stuff and discover my true potential as an idiot.

[Triplefox]

Debugging is a school of hard knocks, isn't it?

[Kekskiller]

Having a constructor template error with some tricky meta programming

Code:

namespace ITK { namespace Meta {
  
  template <bool cond, class if_true, class if_false> struct TypeIf                            {typedef if_true  result;};
  template <           class if_true, class if_false> struct TypeIf <false, if_true, if_false> {typedef if_false result;};
  
  template <class T> struct ConstRef {
    typedef typename TypeIf<(sizeof(T)<sizeof(T*)),const T,const T&>::result type;
  };
  
  #define ConstRef(T) typename ITK::Meta::ConstRef<T>::type
  
} }

template <class T> struct A {
  T t;
  
  // does not work:
  template <class S> A(ConstRef(S) d) {t=d;}
  
//  // works:
//  A(ConstRef(T) d) {t=d;}
};
 
int main () {
  A<char> a(4);
  return 0;
}

GCC error output:

Code:

templconstest.cpp: In function ‘int main()’:
templconstest.cpp:25: error: no matching function for call to ‘A<char>::A(int)’
templconstest.cpp:14: note: candidates are: A<char>::A(const A<char>&)

In essence it's complaining about the constructor template, it functions normally without. If you wonder about the meta stuff: It generates a call-by-reference or call-by-value depending on what's bigger using sizeof. The classes work, I used them before without any problems. It's just that it always generates a reference if combined with a constructor template. I don't know why, cause it works fine without. Test it for yourself, GCC does currently not like it. I can live with that (it's not sooo essential), but it'd be nice to have such kind of implicit type conversion.

[increpare]

Managed to break up my big-assed unexplained bug into a zillion smaller unexplained bugs.  Progress.  But man, I'm really getting fatigued with it 

[Average Software]

Having a constructor template error with some tricky meta programming

Code:

namespace ITK { namespace Meta {
  
  template <bool cond, class if_true, class if_false> struct TypeIf                            {typedef if_true  result;};
  template <           class if_true, class if_false> struct TypeIf <false, if_true, if_false> {typedef if_false result;};
  
  template <class T> struct ConstRef {
    typedef typename TypeIf<(sizeof(T)<sizeof(T*)),const T,const T&>::result type;
  };
  
  #define ConstRef(T) typename ITK::Meta::ConstRef<T>::type
  
} }

template <class T> struct A {
  T t;
  
  // does not work:
  template <class S> A(ConstRef(S) d) {t=d;}
  
//  // works:
//  A(ConstRef(T) d) {t=d;}
};
 
int main () {
  A<char> a(4);
  return 0;
}

GCC error output:

Code:

templconstest.cpp: In function ‘int main()’:
templconstest.cpp:25: error: no matching function for call to ‘A<char>::A(int)’
templconstest.cpp:14: note: candidates are: A<char>::A(const A<char>&)

In essence it's complaining about the constructor template, it functions normally without. If you wonder about the meta stuff: It generates a call-by-reference or call-by-value depending on what's bigger using sizeof. The classes work, I used them before without any problems. It's just that it always generates a reference if combined with a constructor template. I don't know why, cause it works fine without. Test it for yourself, GCC does currently not like it. I can live with that (it's not sooo essential), but it'd be nice to have such kind of implicit type conversion.

As far as I know, parameters to templatized constructors must be deduceable from the constructor arguments.  The type of S on that constructor can't be deduced from the parameter (your macro hides that a little bit).

If you provide a dummy parameter to aid the deducing, it actually compiles:

Code:

template <class T> struct A {
  T t;

  // does not work:
  template <class S> A(S dummy, ConstRef(S) d) {t=d;}
  
//  // works:
//  A(ConstRef(T) d) {t=d;}
};
 
int main () {
  A<char> a(4, 4);
  return 0;
}

Comeau C++ gives similar errors to what GCC is giving, and Comeau is almost always right.  I don't think GCC is in the wrong on this one, you just can't do what you're trying to do.

[Kekskiller]

Ah, ok. Thanks, that explains a lot! So I can't do this with giving him the typ explicitely. Hm, I guess I'll simply drop the idea.

[increpare]

And another wave of bugs. 

[Ludophonic]

So when I #include <set> it should put everything in the std namespace right?

Well, it puts set in so std::set<float> a_set; works and set<float> a_set; (without the namespace) doesn't; exactly as it should be.

But at the same time seems to also pollute the default namespace with several goddamn standard C header files: stdlib.h, string.h and who knows what else. Grrrr.

[Kekskiller]

Well, C++' STL is a rather complex construct with it's own set of dependencies. Though it requires you some time to implement it's features by yourself, so either way you end up with one or two side effects.

[Ludophonic]

You would think it would use the <cstring> and <cstdlib> versions which are defined to be in the std namespace.

[Kekskiller]

As I always say: STL sucks. No way around.

[dspencer]

Why is that a problem? It seems like stdlib.h should be part of the standard library. So it makes sense that its functions go into namespace std. Likewise, string is part of the standard library.

[Average Software]

Why is that a problem? It seems like stdlib.h should be part of the standard library. So it makes sense that its functions go into namespace std. Likewise, string is part of the standard library.

It's a problem because stdlib.h is only included with C++ for C compatibility.  The proper C++ header is cstdlib, which declares everything in namespace std.

[Ludophonic]

Why is that a problem? It seems like stdlib.h should be part of the standard library. So it makes sense that its functions go into namespace std. Likewise, string is part of the standard library.

What you're describing is the behaviour I want, and what I believe the C++ standard says is supposed to happen.  Everything should go into std when using C++ style includes.

It's not doing that, which is why I be grumpy. Time to test with another compiler and perhaps file a bug report with Apple.

[dspencer]

OH oops. Yes, be grumpy. grr.

[mcc]

So: implicitly including string.h, etc via set sounds like very wrong behavior to me.

However: It is parity behavior with Linux. If I test-compile:

#include <set>

int main() {
        strlen("test");
        return 0;
}

This compiles for me, against my intuition, on both OS X (Apple-gcc 4.2.1) and Ubuntu (gcc 4.2.4).

There's this obnoxious thing where gcc on every platform needs to be bug-compatible with each other, because otherwise people will write code that implicitly depends on mainline GCC's bugs and then tarballs won't compile on os x or whatever :|

( I'm curious, anyone want to try compiling this on MSVC? My copy of VS has apparently expired or something and wants me to register  )