Re: C/C++ (was Re: mailbox (was Re: intro))

[Alain Magloire]

> 
> > But something that you forgot .. how many people know C++?
> > Ok those on the list that understand(can code with C++) speak
> > loudly .... The silence is deathning.
> 
> No, not at all. I know C++ and was working pretty actively in some
> projects that were using it, and my silence is just due to the fact
> that I understood C++ is not a panacea as well and have heard such
> discussions before :^) In spite of its being more strictly standardized
> than C, C++ usually poses much more compatibility problems.

If it we restrict to a clean set, we can get away with it.
But that easier to say then to do 8). For example, things like namespace
even today is not widely implemented.  But they are examples of
success, QT comes to mind.

> "Standards are a good thing, for you can always choose the one you
> prefer", said someone and that seems to be particularly true regarding
> different C++ compilers. Besides, there exists a strong mutual
> dependence: 'way of thinking' <=> 'spoken language' which is true for
> programming languages as well as for natural ones. In case of
> programming languages, that means that one is always tempted to use
> approaches that seem more effective in that given language. But that
> does not necessarily mean they are effective in the code the compiler
> produces.

But they are some tasks/problems that are resolve more elegantly
via a certain language, IMHO.  And in mailutils, some places are
obvious like a mime_t should have been also message_t .i.e

public class Mime extends RFC822Message {
}

A mime is a different vision of the message which separate
the message container in different structures. A rfc822 message
see  only two streams header and body no particular interpretation
is done on the body.

public RFC822Message implements Message {
        Header getHeader();
        Body getBody();
}

> Having spent much time programming in the Lisp, I understand
> you, Alain, when you say: 'It felt funny after doing Java for so long
> to call (free) and to play with pointers.' It really feels funny after
> Lisp with its garbage collectors and other attractive features, but
> usually memory management (and not only memory management) controlled
> by programmer is much effective than that controlled by
> compiler/interpreter.

AMEN! brother sergey, AMEN 8)

> OK, that all seems to become a philosophical essay, so I'd better
> stop here. Anyway, I've said it -- I feel better :^) Let's return
> to the ... meat of the matter :^)

[[laughs]] 8) mais non, mais non, mon cher.  Un peu de zizanie avec une
pince'e de philosophie ne peut faire que du bien 8-)
(For the english speakers, ... we love tequillas 8)

> Both C and C++ have their pros and their contras. The reality is that
> neither is perfect and that many programs are written in C (and many
> will be written in it, I believe) and other many are written in C++.

Agreed.

> Mailutils could facilitate writing of those working with email. It
> would be a Good Thing if it could provide both C and C++ interfaces.
> As Alain has pointed out, usually this is achieved by writing a C++
> interface to the C API. Doing it other way around is possible but
> imposes many problems and difficulties. Portability issues should not
> be forgotten, also. So, my proposition is to provide a very good
> C API, and build other interfaces (Scheme, C++, Perl, whatever) on
> top of it.

Alright then, lets view it another way:  I think we all agree
on the need to have a clear lower level API to talk to the
underlying mailbox formats.
Now comes the framework, that API to talk transparently to all of them,
in C it is cumbersome and the language gets in the way, for example
message_set_header() or mailbox_set_xxx this, mailbox_get_xx that
there is no real inheritance, so we have end up with a bunch
of _set/get_ calls, it can get messy especially when something
wrong happen, in the lowest level(This is were sometimes, I crave
for a good C++ throw 8).

What do you see we can do in term of framework (mailbox_t/message_t,...)
for the next step? (of course the next step is not tomorrow if at all 8)