future of the C++
in [C++]
|
Prev: Generating a derived class from a base class
Next: Why is the return type of count_if() "signed" rather than "unsigned"?
From: Stanley Friesen on 12 Jul 2010 17:37 Andre Kaufmann <akfmnews(a)t-online.de> wrote: >Dragan Milenkovic wrote: >> [...] >> And why would there be a constructor involved with a static value? >> I don't think that those two cases can be compared. > >Where's the difference if I initialize a static or a class member ? > >class a { static int v; }; >class b { int v; }; > >To initialize them I have to write: > >int a::v = 1; >b::b() : v(1) {} > >Why can't I simply write ?: > >class a { static int v = 1; }; >class b { int v = 1; }; > Actually, in C++0X you *can* do at least the second part of this. (note, in the first case you would still have to write a definition of the static member, so, IMO, there is actually little benefit to the first case except where it is const. -- The peace of God be with you. Stanley Friesen [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Larry Evans on 12 Jul 2010 17:35 On Jul 12, 5:26 pm, Mathias Gaunard <loufo...(a)gmail.com> wrote: > On Jul 12, 2:14 pm, Larry Evans <cppljev...(a)gmail.com> wrote: > [snip] >> it uses >> >> http://svn.boost.org/svn/boost/sandbox/variadic_templates/boost/funct... >> >> to test whether the functor, F, passed to reify_apply template can be >> applied to an argument list of type (C1,C2,...,Cn). If so, it does >> the call, if not an exception is thrown. > > You could simply add an operator()(...) overload to your functor, no > need for needlessly complicated introspection machinery. > I just remembered the *real* reason for using can_be_called. While testing, I found that even though I didn't call the functor invalid arguments, the compiler instantiated the calls anyway and issued a fatal compile-time error. In apply_unpack.hpp there's this code: #ifndef APPLY_UNPACK_DEMO_UNCHECK_ARGS apply_ftor_check_args( a_functor , a_args.template project<Indices>()...); #else //This branch of #if...#endif can cause compile errors //about "no match for for call to 'SomeFunCall'" //where SomdFunCall is some function name and //parameter type list. a_functor( a_args.template project<Indices>()...); #endif If you enable the #else branch and run the test driver, you'll see what I mean. Even though the test driver (or some version of it) only calls with arguments that are valid, the compiler diagnoses a fatal error. It does this because, judging from the compiler error messages, it tries to instantiate each possible combination of concrete arguments. I'd really like a way to avoid that. Your suggestion about using operator()(...) would avoid that; however, it would make the error messages more cryptic and it would also require either: 1) the user to define his functor with operator()(...) and issue his own diagnostic. 2) reify_apply to create a functor derived from one with operator()(...) and inheriting from the reify_apply functor. or something like that. Hope that clarifies the reasons for using can_be_called. -regards, Larry -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Stanley Friesen on 12 Jul 2010 17:53 nmm1(a)cam.ac.uk wrote: >In article <i13i2b$jlb$1(a)news.eternal-september.org>, >Walter Bright <walter(a)digitalmars-nospamm.com> wrote: >> >>Usually, yes, a breakpoint is better. But consider what a breakpoint is >>- it's a debugger installing an exception handler! A debugger is >>sometimes not available, and so it's nice to be able to build in a bit >>of debugger capability into the program. > >Precisely. All competently engineered production applications >have the ability to diagnose their own failures, and I can witness >(from experience with ones that did and ones that didn't) that it >can reduce the maintenance effort by a factor of ten. And more >bugs get fixed rather than hacked around, of course. > >And that ignores the fact that most languages force you to take >explicit action to ensure that all diagnostics are written to >disk! Just doing that in a handler is often worthwhile. But what if you don't *have* a disk, or any other easily accessible persistent store? This is true of many, if not most, embedded systems (such as the one I am currently working on). -- The peace of God be with you. Stanley Friesen [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Jerry Stuckle on 12 Jul 2010 22:03 Stanley Friesen wrote: > nmm1(a)cam.ac.uk wrote: > >> In article <i13i2b$jlb$1(a)news.eternal-september.org>, >> Walter Bright <walter(a)digitalmars-nospamm.com> wrote: >>> Usually, yes, a breakpoint is better. But consider what a breakpoint is >>> - it's a debugger installing an exception handler! A debugger is >>> sometimes not available, and so it's nice to be able to build in a bit >>> of debugger capability into the program. >> Precisely. All competently engineered production applications >> have the ability to diagnose their own failures, and I can witness >> (from experience with ones that did and ones that didn't) that it >> can reduce the maintenance effort by a factor of ten. And more >> bugs get fixed rather than hacked around, of course. >> >> And that ignores the fact that most languages force you to take >> explicit action to ensure that all diagnostics are written to >> disk! Just doing that in a handler is often worthwhile. > > But what if you don't *have* a disk, or any other easily accessible > persistent store? This is true of many, if not most, embedded systems > (such as the one I am currently working on). I have to agree with Nick on this one. And it's especially important in embedded systems, which must be able to not only detect failures, but recover from them and go on. Every embedded system I've seen in the last 15-20 years or so has some kind of persistent storage; early ones often used EEPROMs, while many current ones use flash memory. There should be storage reserved for error logging and reporting so the developers can go back and see what went wrong. Of course, this isn't necessary if your hardware never fails and your programmers are perfect :) -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex(a)attglobal.net ================== [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Larry Evans on 12 Jul 2010 22:23
On Jul 13, 3:35 am, Larry Evans <cppljev...(a)gmail.com> wrote: [snip] > > You could simply add an operator()(...) overload to your functor, no > > need for needlessly complicated introspection machinery. > > I just remembered the *real* reason for using can_be_called. While > testing, I found that even though I didn't call the functor invalid > arguments, the compiler instantiated the calls anyway and issued a > fatal compile-time error. In apply_unpack.hpp there's this code: > > #ifndef APPLY_UNPACK_DEMO_UNCHECK_ARGS > apply_ftor_check_args( a_functor > , a_args.template project<Indices>()...); > #else > //This branch of #if...#endif can cause compile errors > //about "no match for for call to 'SomeFunCall'" > //where SomdFunCall is some function name and > //parameter type list. > a_functor( a_args.template project<Indices>()...); > #endif > > If you enable the #else branch and run the test driver, you'll see > what I mean. Even though the test driver (or some version of it) > only calls with arguments that are valid, the compiler diagnoses a > fatal error. It does this because, judging from the compiler error > messages, it tries to instantiate each possible combination of > concrete arguments. > > I'd really like a way to avoid that. Your suggestion about using > operator()(...) would avoid that; however, it would make the error > messages more cryptic and it would also require either: > > 1) the user to define his functor with operator()(...) > and issue his own diagnostic. > > 2) reify_apply to create a functor derived from one with > operator()(...) and inheriting from the reify_apply > functor. > > or something like that. > [snip] Well, using operator()(...) didn't work (got a compile error in apply_unpack); however, using: template < typename Functor , typename ResultType > struct functor_bad_args { typedef ResultType result_type; template<typename... Args> result_type operator()(Args&... args)FUNCTOR_CONSTANCY throw() { throw bad_functor_args<Functor(Args&...)>(); return result_type(); } }; and then in the test driver, changing functor3 to inherit from this did the trick. The new code has been uploaded. Thanks for the suggestion, Mathias. -regards, Larry -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |