Kohei Yoshida wrote:
On Fri, 2008-05-09 at 20:01 +0200, Mathias Bauer wrote:
Another interesting discovery was that removing ctors can be dangerous
at times because some compilers automatically create default or copy
ctors for classes even if they aren't used.
One technique to work around
Hi Mathias,
On Tue, 2008-05-20 at 08:43 +0200, Mathias Bauer wrote:
In the current situation the problem didn't happen in the class where
the ctor was removed but in some derived classes. These classes formerly
had a ctor (and so it wasn't necessary to declare a default ctor, be it
private
On Fri, 2008-05-09 at 17:54 -0400, Kohei Yoshida wrote:
Hi Niklas,
On Fri, 2008-05-09 at 19:17 +0200, Niklas Nebel wrote:
example: CHINA001
In the interest of removing the unused code, I'd like know what those
CHINA001 labels are for. Is it okay to perhaps review those commented
out
Hi Kohei,
On Thursday, 2008-05-08 00:22:10 -0400, Kohei Yoshida wrote:
If I recall correctly, the module with the most unused methods that
doesn't have anything in the pipeline to remove them is sc, so there's
where the lowest hanging fruit should be.
Since no one has raised hands, let
On Fri, 2008-05-09 at 16:47 +0200, Eike Rathke wrote:
while ScCompressedArray::GetPrevValue() is currently
unused it is the counterpart of GetNextValue() and IMHO should be kept
for completeness of implementation.
Perhaps #ifdef FUTURE around it, or else I can add such things to the
whitelist
On Fri, 2008-05-09 at 16:47 +0200, Eike Rathke wrote:
Just a note though: please don't blindly remove everything that appears
to be unused, e.g. while ScCompressedArray::GetPrevValue() is currently
unused it is the counterpart of GetNextValue() and IMHO should be kept
for completeness of
On Fri, 2008-05-09 at 16:11 +0100, Caolan McNamara wrote:
On Fri, 2008-05-09 at 16:47 +0200, Eike Rathke wrote:
while ScCompressedArray::GetPrevValue() is currently
unused it is the counterpart of GetNextValue() and IMHO should be kept
for completeness of implementation.
Perhaps #ifdef
Caolan McNamara wrote:
On Fri, 2008-05-09 at 16:47 +0200, Eike Rathke wrote:
while ScCompressedArray::GetPrevValue() is currently
unused it is the counterpart of GetNextValue() and IMHO should be kept
for completeness of implementation.
Perhaps #ifdef FUTURE around it, or else I can add such
Hi Malte,
Malte Timmermann wrote:
Hi Caolan,
thanks for the updated list! :)
I wonder: Who dares / volunteers to simply remove these methods?
This is ongoing already. I have a CWS where the biggest chunks have been
put in already (binfilter, filter, svtools, filter, desktop...). CWS is
On Fri, 2008-05-09 at 20:01 +0200, Mathias Bauer wrote:
A warning to everyone committing such cleanups to cvs: please use
non-pro builds on at least one platform
Indeed. The unused methods are always pulled from a .pro build. The same
issue arises with stuff used only on one platform but
On Fri, 2008-05-09 at 19:17 +0200, Niklas Nebel wrote:
Good old opt-in vs. opt-out choice. I'd prefer to leave all methods
in
the header files, commented out and marked somehow, unless someone
has
(manually) determined that they really shouldn't be there.
I can start using REMOVE_THIS
On Fri, 2008-05-09 at 15:16 -0400, Kohei Yoshida wrote:
Having said that, I would like to still reserve the right to just
outright remove code if I think with strong certainty that the code
shouldn't be there at all. ;-)
And again, if I removed something by mistake that you want to leave in,
On Fri, 2008-05-09 at 20:01 +0200, Mathias Bauer wrote:
Another interesting discovery was that removing ctors can be dangerous
at times because some compilers automatically create default or copy
ctors for classes even if they aren't used.
One technique to work around this is to put the
Hi Niklas,
On Fri, 2008-05-09 at 19:17 +0200, Niklas Nebel wrote:
example: CHINA001
In the interest of removing the unused code, I'd like know what those
CHINA001 labels are for. Is it okay to perhaps review those commented
out lines and see if we can remove them permanently?
Kohei
--
Kohei
On Thu, 2008-05-08 at 00:22 -0400, Kohei Yoshida wrote:
On Tue, 2008-05-06 at 09:10 +0100, Caolan McNamara wrote:
If I recall correctly, the module with the most unused methods that
doesn't have anything in the pipeline to remove them is sc, so there's
where the lowest hanging fruit should
On Tue, 2008-05-06 at 09:10 +0100, Caolan McNamara wrote:
If I recall correctly, the module with the most unused methods that
doesn't have anything in the pipeline to remove them is sc, so there's
where the lowest hanging fruit should be.
Since no one has raised hands, let me tackle that.
See http://people.redhat.com/caolanm/callcatcher/DEV300_m10/ for full
list. Top three offenders are...
1521 binfilter
403 sc
198 sd
C.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Hi Caolan,
See http://people.redhat.com/caolanm/callcatcher/DEV300_m10/ for full
list. Top three offenders are...
sorry for the dumb question, but what are uncallable methods?
Ciao
Frank
--
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems
Methods with very strange names, hard to speak ;)
No just kidding - it means that very likely (100%?) these methods are
never used/called from somewhere.
Malte.
Frank Schönheit - Sun Microsystems Germany wrote, On 06.05.08 09:51:
Hi Caolan,
See
On Tue, 2008-05-06 at 09:54 +0200, Malte Timmermann wrote:
Methods with very strange names, hard to speak ;)
No just kidding - it means that very likely (100%?) these methods are
never used/called from somewhere.
*cough*, yes. Maybe a what the hell are they, might be useful. They're
the
20 matches
Mail list logo
