Loading ...
Sorry, an error occurred while loading the content.

Re: [AutoTrace] C versus C++

Expand Messages
  • Masatake YAMATO
    Wolfgang, sorry to be late to answer. (I ve CC ed to autotrace ML.) ... After thinking, I d like to introduce glib for this inline issue. Here is my approach:
    Message 1 of 18 , Dec 2, 2000
    • 0 Attachment
      Wolfgang, sorry to be late to answer.
      (I've CC'ed to autotrace ML.)

      > > > - I should accept INLINE macro bacause gcc supports inline as
      > > > an extension of C lang. (Glib has INLINE macro, so it is worth
      > > > to use glib. But this is another issue.)
      >
      > OK, to what concerns the macro.
      After thinking, I'd like to introduce glib for this inline issue.

      Here is my approach:
      (1) If the user has not installed glib, autotrace doesn't use inline.
      (2) If the user has installed glib, autotrace uses glib ;and enable inline.
      (3) configure checks the existence of glib.
      (4) libautotrace and autotrace.h will not depends on glib.h.

      Any objection?

      > > > - I should not accept REF(T) macro because it is not realy needed.
      > > > C lang can do same with * pointer operator:).
      > > > If it is possible to do a thing with C lang without C++ lang,
      > > > I think we should do it with C lang.
      > Here I have a different opinion. But this is not a language issue, it
      > is a style issue. In C++ I'm used to use references (refs) whenever I
      > want
      > to pass a value to some function and don't expect that that function
      > needs the address of the value. Example: add to value and return the
      > result. Using a pointer here is quite unnatural. It is only a very ugly
      > workaround for fixing a performance problem due to the non-availability
      > of references in C. But for C I would recommend to keep the current
      > value passing style as it is much clearer code and the performance
      > impacts
      > are not to high (in C mode and for the small structs that we have in
      > autotrace).
      > If you use a pointer you cannot read from the code what happens with the
      > ownership (who does the free?) of the piece of memory the pointer points
      > to. Is it transferred or not. You need to get this info from some other
      > documentation. On the other hand using a value (and in C++ for
      > performance
      > reasons a reference) makes this very clear directly in the code without
      > any need for further documentation.
      > Using refs vs. values may have also an impact on inline expansion.
      > It is easier if refs are used.

      I understand why C style is ugly.
      But as a user of libautotrace.a,
      I don't like to consider there is two version of libautotrace.a:
      libautotrace.a compiled by C compiler and libautotrace.a compiled
      by C++ compiler.

      How do you think that we introduce that passing value via a pointer
      to hot-spot.

      I think the memory storage ownership is small problem if we define
      rules about memory storage handling. If it is difficult to define
      simple rules, we can introduce reference count mechanism well used
      in GtkObject system.


      > Finally: What about the const correctness? Do you consider that useful?
      > And what about the memory problem that I wrote about in my message to
      > the
      > group? Martin - did you check the "uninitialized variable" messages of
      > FlexeLint? I think they are (small) bugs.
      >
      > Ciao

      If the C-lang-compatible, we should keep all correctness, I think.
      Wolfgang, I'd like you to get a write account for autotrace CVS
      repositry.

      Masatake
    Your message has been successfully submitted and would be delivered to recipients shortly.