On Wed, Aug 12, 2009 at 2:03 AM, Pedro
Lamarão<[email protected]> wrote:
> I've recently started my contributions to the gcc-in-cxx project, and
> eventually decided on the qsort suggestion because it seems the
> easiest one.
> I've made the change in three places in cp/classes.c; the patch can be
> found here:
>
> http://code.google.com/p/ccppbrasil/wiki/GccInCxx
>
> Is this the way to go?
Please attach patches in the future.
+bool
+field_decl_less (const tree& x_p, const tree& y_p)
+{
you should be able to use std::bind and functors to avoid that
function.
+#include <algorithm>
+
#include "config.h"
#include "system.h"
The includes need to come after config.h and system.h at least.
+static bool
+method_name_less (const tree& m1_p, const tree& m2_p)
see above.
- qsort (VEC_address (tree, method_vec) + slot, len - slot, sizeof (tree),
- resort_method_name_cmp);
+ std::sort (VEC_address (tree, method_vec) + slot,
+ VEC_address (tree, method_vec) + len,
+ resort_method_name_less);
this hints at the fact that we want to replace VEC ...
> Some questions occurred to me: in order to support a C and a C++
> compiler at the same time, what "portability" mechanism should be
> used? #ifdef guards to switch between qsort and std::sort on the spot,
> based on __cplusplus? Should a helper function be declared somewhere?
We shouldn't do this kind of patches as long as we need to support
a C compiler.
> Also, std::sort requires a "less" function on reference-tovalue-type,
> so the current foo_cmp functions can't be reused.
> Would a separate patch to introduce foo_less variants be acceptable
> for GCC 4.5 right now?
No, I don't see the need for them.
> Also, is the gcc-in-cxx branch still active? Should my objective be to
> contribute patches to this branch?
I think the branch is dead, but you need to ask Ian.
> On a side note, I've studied vec.h and found it hard to change.
> One reason is because this header is included by the gen*.c stuff,
> which is still being compiled by a C compiler, even when building with
> a C++ compiler is enabled.
> I've considered providing a separate version of vec.h when C++ is
> being used, to avoid infinite #ifdefs.
> Is this a good idea?
See above.
Richard.
> --
> Pedro Lamarão
>
