Outlook express is being really funny.
Its never been the worst news client, but this version has gone sideways.

"Ruben" <ruben@www2.mrbrklyn.com> wrote in message news:pan.2008.10.10.14.37.50.601771@www2.mrbrklyn. com...
> On Fri, 10 Oct 2008 11:09:31 +0200, Chris Becke wrote:
>
>> I do not in any way wish to imply that c++ features should not be used.
>>
>> I do think however that this is an area in which there is no "right" answer. It is perfectly valid sometimes to use virutal interfaces. But sometimes it is not.
>>
>> The problem is, in *my* experience. Which is limited to my environment that is mostly Win32 development. In my experience, as soon as the interface pattern is considered for a c++ object, the level of abstraction that an interface implies makes it a very suitable canditate to be located in an external binary module.
>>
>> At the same time, I do in fact prefer using PODs for data in interfaces. Again, in the environment im exposed to we have c++ code written a long time ago before the STL was stable, as well as a need to interop with other c++ frameworks that have their own ideas as to what constitutes a string (For eg). Interfaces, being very abstract, are the mechanism by which these different codebases (even when in the same compiled module) interop, and thus PODs as a least common denominator are the most convenient to work with. And frankly a lot easier to deal with.
>>
>>
>
> I'm sure your making some important and interesting point here but I can't
> read it because it scrolls of the screen about 20 feet.
>
> Try using
>
> %!fmt in vim or some other wrapping convention in the editor of your
> choice so we can all share in the wealth of good ideas you present
>
> Ruben
>
>
>> "James Kanze" <james.kanze@gmail.com> wrote in message news:0c00706c-4ecd-47d3-92ea-1c5f0fd1bd54@a19g2000pra.googlegroups.com...
>> On Oct 9, 9:54 am, "Chris Becke" <chris.be...@gmail.com> wrote:
>>> XPCom is little more than a pillage of Microsoft COM. Both, at
>>> their base level consist of declaring a C++ class containing
>>> pure virutal methods and compiling with a compatible compiler.
>>> Ensuring that even c++ interfaces intended to be used only by
>>> homogeneous (c++) code are nonetheless compatible at a binary
>>> level means that code can easilly move from a homogeneous to a
>>> heterogeneous environment.
>>
>>> Which is just good software engineering practice.
>>
>> So I shouldn't use classes, because some other component might
>> be written in C. For that matter, I shouldn't use struct,
>> because some other component might end up written in Fortran.
>>
>> This is just plain stupid. You're code has (or should have)
>> well defined interfaces. Which support what they support. If
>> one of the requirements is that it be callable from another
>> language, then you use appropriate tools for this, depending on
>> which and how many languages are concerned. (Often, ``extern
>> "C"'' is all that is required.) But such interfaces normally
>> only occur at the component level, and represent a separate
>> interface from those used internally. And represent but a small
>> percent of your interfaces.
>>
>>> Not everyone uses c++.
>>
>> Of course, not. Cobol, and probably PHP, are more widely used,
>> for example.
>>
>>> .so and .dll files are (depending on your platform) common
>>> ways to glue binary files (from teams with different toolsets)
>>> together .
>>
>> Plugins are one technology, and of course, you're plugin
>> interface should be designed to support as many languages as
>> possible: no classes, for example, and possibly no struct's.
>>
>>> The virtual keyword prevents that interface and any derived
>>> interfaces ever being exported in a binary compatible way (on
>>> compilers that otherwise produce interfaces in a way that DOES
>>> conform to COM/XPComs binary interface requirements).
>>
>> The use of classes prevents this already. The question is
>> simply one of your requirements. If an interface has to support
>> multiple languages, you really can't present more than a POD at
>> the interface level. Most interfaces don't have such
>> constraints, however, and when you have such constraints, you
>> generally implement them using the facade pattern, so you can
>> use all of C++ in your implementation.
>>
>>> If you are developing reusable code you can never know how its
>>> going to need to be used in the future.
>>
>> That is, of course, bullshit. Code can only be used for that
>> for which it was designed for. If you don't provide an
>> interface callable from Cobol, or from PHP, your code can't be
>> called from those languages.
>>
>>> don't shoot yourself in the foot and rely on this broken
>>> mechanism. It might be good "c++". but its bad computer
>>> science. It violates the earliest principals computer science
>>> students are taught about avoiding coupling.
>>
>> I don't think you really understand software engineering. You
>> program to a requirements specification, and not to some
>> imaginary, mythical future use. Premature genericity is just as
>> bad a sin as premature optimization: you don't know what the
>> future will bring, or need. And implementing all of your
>> interfaces in ``extern "C"'', with just PODs (because that is
>> really what you've just said) is just plain stupid.
>
> --
> http://www.mrbrklyn.com - Interesting Stuff
> http://www.nylxs.com - Leadership Development in Free Software
>
> So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998
>
> http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
>
> "Yeah - I write Free Software...so SUE ME"
>
> "The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."
>
> "> I'm an engineer. I choose the best tool for the job, politics be damned.<
> You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."
>
> © Copyright for the Digital Millennium
>

Chris Becke wrote:
> Outlook express is being really funny.
> Its never been the worst news client, but this version has gone sideways.

I had been using it for a decade without top-posting. If
you want to stick to it, look at this:
http://home.in.tum.de/~jain/software/oe-quotefix/

> [...]

Schobi

Chris Becke wrote:
> Outlook express is being really funny.
> Its never been the worst news client, but this version has gone sideways.
>
It must have if it keeps forcing you to top-post.

--
Ian Collins

James Kanze wrote:

> I'm having problems figuring out what virtual inheritance has to
> do with all this. Certainly, some languages might not support
> it. But then, many of the most widely used languages outside of
> C++ (e.g. Cobol, C) don't even support inheritance to begin
> with.

I believe that the current Cobol standard supports inheritance although
I haven't seen a recent standard. However, a visit to
http://www.cobolstandard.info/wg4/document.html offers plenty of
evidence that Cobol supports inheritance, MI and even some analogue of
template classes.

LR

Its not forcing me to top post. That I have been doing for a decade. and far prefer to the alternative.

It has gone sideways in that it isn't quoting correctly. And apparently screwing up line wrapping on sent documents.

"Ian Collins" <ian-news@hotmail.com> wrote in message news:6l9sisFavgarU3@mid.individual.net...
> Chris Becke wrote:
>> Outlook express is being really funny.
>> Its never been the worst news client, but this version has gone sideways.
>>
> It must have if it keeps forcing you to top-post.
>
> --
> Ian Collins

Chris Becke wrote:
> Its not forcing me to top post. That I have been doing for a decade. and far prefer to the alternative.

You might want to think about this. At least in
technical groups, you're rather alone with this
preference.

> [...]

Schobi