Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


sundersoft

Member Since 09 May 2012
Offline Last Active Oct 09 2012 09:38 PM

Posts I've Made

In Topic: Is using a debugger lazy?

21 September 2012 - 07:19 PM

I almost never use a debugger because:
-I usually have a good idea of where the bug is; it's usually in the last code you wrote (assuming you're testing properly). The code's errorneous behavior is also usually enough to determine roughly where the bug is. Having to look at stack traces and whatnot takes a good amount of time and it's usually not necessary to know exactly where the bug is.
-My approach to fixing bugs is to look at the relevant code and try to improve it. I may find other bugs that I didn't know about or I may find that the code or variable names are confusing. I may also decide that the method I'm using is naturally error prone (has many special cases, etc) and that I should rewrite the code to be simpler. With a debugger, I normally find the bug, fix it, and leave, so the code quality is not improved much. I'd rather spend time looking at the code than using a debugger.

When I do use a debugger, it's usually to generate a stack trace for an uncaught exception or segmentation fault. Although well written C++ code shouldn't throw many exceptions or have many opportunities to segfault, so I very rarely use the debugger. I normally do printf-style debugging since it's faster than using a debugger to generate the same information if you're lucky, and since I prefer reading log files over suspending the program every time I want data.

I also hate Visual Studio because it gets in my way so much. You should just be able to write text without having a box suddenly pop up on the screen, eat your keyboard input, and block out the rest of the code. Why can't the autocomplete stuff be on a seperate panel on the side of the screen instead of blocking the code? I use Dev-C++ (a beta version of it and with the most recent version of GCC) to do all development because the IDE is simple and doesn't get in my way. Also, autocomplete encourages lazy variable naming because the penalty for not naming your variables properly is reduced which makes it harder to detect badly-named variables. Many of the other IDE's features are stupidly implemented and it would waste more space (specifically vertical space) than Dev-C++ even if you disabled all of its features.

With that being said, most people are reliant on debuggers and prefer complicated IDEs such as Visual Studio.

In Topic: std::enable_if, template specialization

01 September 2012 - 06:46 PM

I soon realized this after posting that reply and decided to go with the function overload. Extending the standard namespace is something I try to avoid, but I am interested in what these "certain conditions" are, if you could explain further.


This is what the standard says about it (this is from a 2005 draft but I doubt the C++11 standard changed this significantly):

"It is undefined for a C++ program to add declarations or definitions to namespace std or namespaces within names-
pace std unless otherwise specified. A program may add template specializations for any standard library template to
namespace std. Such a specialization (complete or partial) of a standard library template results in undefined behavior
unless the declaration depends on a user-defined type of external linkage and unless the specialization meets the standard
library requirements for the original template.
171)
A program may explicitly instantiate any templates in the standard
library only if the declaration depends on the name of a user-defined type of external linkage and the instantiation meets
the standard library requirements for the original template."

Footnote 171: "Any library code that instantiates other library templates must be prepared to work adequately with any user-supplied specialization that meets
the minimum requirements of the Standard."

You might want to wait for concepts to be standardized (or killed) before trying to add information about when a template would work to its interface. You're going to have to change your code if the standards comittee actually implements concepts and you want to use that feature (which would basically do what you're trying to do right now).
http://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29
However, this probably isn't going to be standardized for another 5 years at least (if it does become standard).

In Topic: std::enable_if, template specialization

01 September 2012 - 05:36 PM


You could try changing the specialization to:

template <> typename std::enable_if<std::is_arithmetic<mytype>::value, mytype>::type func(const mytype& x) noexcept;


I could try this but it would involve specializing is_arithmetic for mytype which is something I don't really want to do. Even still it would only evaluate to true and produce the same problems.


I really doubt you're going to be able to specialize the function if your type doesn't have is_arithmetic<mytype>::value==true . You are allowed to specialize templates in the standard library (under certain conditions). The following code compiles even though the mytype specialization of func doesn't use is_arithmetic:

#include <iostream>
#include <type_traits>
// firstsomething.hpp
template <typename T>
typename std::enable_if<std::is_arithmetic<T>::value, T>::type func(const T& x) noexcept
{ return x; }
// something.hpp
class mytype {
};
namespace std {
template<> class is_arithmetic<mytype> {
	static const bool value=1;
};
}
template <> mytype func(const mytype& x) noexcept { return mytype(); }
int main() {
	func(0.0);
	func(0);
}

If the is_arithmetic specialization was removed, the code would fail to compile on GCC 4.6. If your type is not an arithmetic type then I think you're going to have to use function overloading.

I think I was concerned that creating an overload would break func for integer types because mytype does not have an explicit constructor and it still takes a single argument integer value. However this is not the case apparently.

Yes; the compiler will prefer to instantiate a template over having a cast and using a non-template (although you can force it to use the non-template version by generating a function pointer to it and calling it, or you can force it to use a template by specifying the template arguments explicitly).

In Topic: std::enable_if, template specialization

01 September 2012 - 01:07 PM

This code compiles in GCC 4.6. I don't have 4.7 to test with.
#include <type_traits>
// firstsomething.hpp
template <typename T>
typename std::enable_if<std::is_arithmetic<T>::value, T>::type func(const T& x) noexcept
{ return x; }
// something.hpp
typedef int mytype;
template <> typename std::enable_if<true, mytype>::type func(const mytype& x) noexcept { return 0; }
int main() {
    func(0.0);
    func(0);
}

You could try changing the specialization to:
template <> typename std::enable_if<std::is_arithmetic<mytype>::value, mytype>::type func(const mytype& x) noexcept;

If that doesn't work, you might not need a function specialization in the first place (I'm not sure what exactly you're trying to do), so you ought to be able to use function overloading:
mytype func(const mytype& x) noexcept;

I did add 'template <typename T>' to the specializations instead of 'template <>' but doesn't this then mean the functions are no longer specializations of the original?

Yes. You can't have a partial function specialization in C++ so all function specializations must start with "template<>" (as far as I know).

In Topic: Can't resolve problematic dlopen() call.

12 August 2012 - 10:18 PM

I accidentally downvoted your post, sorry.

PARTNERS