Re: [gcc-in-cxx] replacing qsort with std::sort

[Richard Guenther <richard.guenther@gmail.com>]

On Wed, Aug 12, 2009 at 2:03 AM, Pedro
Lamarão<pedro.lamarao@ccppbrasil.org> 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
>