Future reuse of code

[Richard Plinston]

GCC the compiler is pointless without libraries,

No, that is not true. On Unix things like open() read() are _system_ calls
not library routines. It is possible to write an application in C without
any libraries at all. In fact most of the libraries are written in C and
thus only require to be coded in the program to give that functionality.

and libraries in C/C++ differ between platforms.

Well of course the standard libraries are _implemented_ differently, but
they provide the same programmer interface and act as a layer between the C
program and the 'platform' specifics.

For gcc the libraries give the same implementation on all platforms they
are implemented on - in fact gcc and its libraries probably run on naerly
every platform that full Java does, and a couple that don't have a full
Java, such as MS-DOS/EMX.

One could also argue that the Java VM 'differes between platform' in that
the VM for one environment won't work on another. In that case the Java VM
is acting in the same way as the C libraries.

Java's libraries let you write complex applications without a million
#ifdef _LINUX_ or whatever.

Your not very widely read on this are you: - never let facts get in the way
of a good prejudice ?

It may be true that _most_ implementations of Sun's JVM at the same version
will run the same program unchanged, it may not be true that, say, a JVM
1.2 will run all Java 1.4 programs or that a servlet will run as an applet.
There are also dozens of JVMs out there which have subtle differences which
may need to be coded around: MS J+, Kaffe, Latte, JanosVM, Alta, even
Blackdown.

These provide specialised environments or enhancements or are for platforms
not catered for by Sun.

All that you are saying is that if one only works within a very limited set
of Java, say the standard VM from Sun of a given version then all programs
will run unchanged.

One could do that for C/C++ too. One never needs an #ifdef if one only
uses those wnvironments that never need an #ifdef.

In any case many of the JVMs are written mostly in C.

 

[Alex]

On Fri, 15 Aug 2003 01:21:55 GMT, Kevin Easton

The difference in, that equivalent program in Java would either work
or not work. It would give the same results on all platforms. With
the C version, you don't know if it works on other platforms until you
test it.

Subject to the run-time environment being thoroughly tested to work
the same on all the potential platforms. Not unlike a conforming C
compiler, wouldn't you say?

The bottom line is, you cannot expect 1-to-1 conformance between
implementations. You should, therefore, always test your programs
on all target platforms. This applies to Java just as much as it
does to C.

Alex

 

[Mark Gordon]

Who said anything about fopen? You still use fopen, but MUST have the
additional include file, which adds support for the mainframe way of
doing things.

In which case it is *not* a conforming hosted C implementation. To be
conforming the inclusion of stdio.h to provide a definition of the FILE
type is entirely sufficient. Of course, you might need to use something
else to deal with directories etc.

The mainframe C compiler is quite happy with long var names and mixed
case. It is the linker which falls over. Actually is only "sees" up to
8 characters, but does not complain at all. This leads to very
interesting behaviour :-((

From memory I think the 8 character limit is legal but I'm not sure
about the case sensitivity. I always avoid having names only
distinguished by case, so it has never been an issue for me.

Oh yes, I also forgot about tri-graphs:
[ becomes ??(
] becomes ??)
^ becomes ??\
~ becomes ??-

Trigraphs are the other way around. You put "??(" in the source and it
is replaced by "[".

I ended up writing a converter which takes the original C code, and
converts it to something that will run on the mainframe. Yuck.

Sounds like the mainframe did not have a conforming C implementation to
me.

 

[Mark Gordon]

Only a bit. (pretty much the amount needed for Delphi compability.
Basic classes and such)


Like?

Trapping the "STOP" key on an HP workstation. Only used this on the HP.

Separately compiled files (has that been added to the standard?) Handled
differently on the different Pascal implementations I used.

A non-standard way to access third party libraries. Handled differently
on the different Pascal implementations I used.

Probably a number of other things that I can't remember now.

I think the Delphi diverged even further, although I helped people with
Delphi rather than using it myself.

 

[Mark McIntyre]

But then people write code thinking of only their own platform where
int is say 32 bits, and hand it to someone else whose int is 16 bits.
It does not work.

well yes, but thats hardly surprising, since they're bad programmers.

It requires foresight

no, it requires an understanding of the limits of the size of an int.

and a macro to make that
code work on both platforms. It is thus foolish to claim C or C++
works naturally multiplatform. It requires extra effort.

it requires knowledge.

 

[Mark McIntyre]

Straw man argument Kevin.

You made the silly assertion that ALL C code would run unmodified on
any platform correctly. That is nonsense.

If you insert the word conforming, its correct.
"All conforming C code will run on any conforming platform correctly".

I need hardly point out thatr *precisely* the same is true of Java,
C++ or for that matter DCL. If you rely on nonstandard features of
your specific implementation, such as the size of an int, or some
class thats not part of the standard, then you're screwed.

I merely stated that writing cross platform code in C or C++ takes
considerable effort.

This remark is flat out wrong.

I've written hundreds of thousands of lines of C and a few tens of Ks
of C++, all of which was completely portable between VMS, Solaris and
NT, and it required NO special effort, merely sticking to the language
spec. The only time I had a problem was when faced with a pre-ansi
compiler on the Sun box.

You need to find third party
libraries supported on all your platforms.

Only if you want to do things not part of the standard implementation.
Just as, in fact, you would need to do with Java, if you wanted, say,
to access vacuum tubes or drive a stepping motor.

You need to generate separate executables.

You do with Java too - each implementation has a separate executable
called the Java Runtime.

You need to test separately, and you need a ton of compile time
macros to make the magic work.

Bollocks. Utter and total bollocks. Stop trolling.

 

[Richard Heathfield]

[Please observe followup to comp.lang.c; thanks.]

Its impossible to write a "strictly compforming" programme.

int main(void)
{
return 0;
}

 

[Richard Heathfield]

[Please observe followups to comp.lang.c; thanks.]

Mark McIntyre wrote:

"All conforming C code will run on any conforming platform correctly".

Counter-example:

void main(void)
{
}

This program is conforming (even though it invokes undefined behaviour),
because at least one conforming implementation accepts it. On the other
hand, it's not difficult to find at least one conforming implementation
that rejects it.

 

[Chris Smith]

[Replaced comp.lang.java.programmer, where this discussion is clearly
relevant.]

Well of course the standard libraries are _implemented_ differently, but
they provide the same programmer interface and act as a layer between the C
program and the 'platform' specifics.

This is true for the specified standard libraries, but not for all
libraries. Then the issue becomes the scope of the standard libraries,
which is quite clearly larger in Java than C. Of course, third-party
libraries are often available for a subset of C platforms that provide
common interfaces to functionality not in the standard library...
however, not all of them are going to work on the platform you're using,
and even "standard" interfaces such as BSD sockets are commonly
implemented with incompatibilities (sometimes even deliberate ones)
between platforms.

If you include those third-party libraries to do things outside of the
language standard libs, and ignore the difficult task of hunting them
down and using them in platform-specific ways, then the compatibility
advantages of Java are clearly not necessarily revolutionary, but are
still a real breath of fresh air from what you'd be doing in C.

What really needs to happen, though, is for this discussion to pin down
what is meant by "libraries" in C. If we're talking about the standard
library, then it clearly differs greatly in completeness; I rarely see
problems that can be solved in C by sticking entirely to the standard
library. On the other hand, if we're talking about third-party
libraries available for C on one or more platforms, then it must be
admitted that it's pretty hit-and-miss in terms of portability.

One could also argue that the Java VM 'differes between platform' in that
the VM for one environment won't work on another. In that case the Java VM
is acting in the same way as the C libraries.

Why would that matter?

It may be true that _most_ implementations of Sun's JVM at the same version
will run the same program unchanged
it may not be true that, say, a JVM
1.2 will run all Java 1.4 programs or that a servlet will run as an applet.

Of course not. Why is this relevant?

There are also dozens of JVMs out there which have subtle differences which
may need to be coded around: MS J+, Kaffe, Latte, JanosVM, Alta, even
Blackdown.

And yet you only need one that runs on the platform. If it conforms
with the right version of the Java specifications, that's all you need
to know, AND it alone is sufficient for writing non-trivial
applications. There are some VMs in your list that are just plain
incomplete or known to not comply with specifications, but there's no
need to write for those VMs, just as there would be no need to use an
obviously non-compliant compiler for the C language.

All that you are saying is that if one only works within a very limited set
of Java, say the standard VM from Sun of a given version then all programs
will run unchanged.

I'd ammend that to say "a VM compliant with a given range of versions of
the Sun specifications". Well, then you don't have a guarantee that
your code will run, since some things like multithreading are
intentionally nondeterministic in the standard and could vary between
platforms, but at least you've got an environment designed to encourage
and make it easy to write portable code, and it's harder to make a
mistake.

One could do that for C/C++ too. One never needs an #ifdef if one only
uses those wnvironments that never need an #ifdef.

You seem to be ignoring the fact that C and C++ both provide
substantially smaller ranges of features and platforms that can be
targeted without conditional compilation. Sure, some applications can
be targeted at some combinations of platforms; but the question when I'm
making choices for an app is: can MY application be targeted at the
likely platforms of MY target audience, and how difficult will it be to
do so. In many cases, C makes that task considerably more difficult.

In any case many of the JVMs are written mostly in C.

And?

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[James J. Gavan]

Apologies in advance guys, but this is a long winded one - to do with the
application of OO COBOL, but some of it certainly applies to the other
languages.
YOU'VE BEEN WARNED - SO QUIT HERE IF NOT INTERESTED !:-
--------------------------------------------------------------------------------

Jimmy,

your post raised a few questions.

Perhaps you could elucidate...?

How can a queue (FIFO) and a stack (LIFO) be implemented with an ORDERED or
SORTED Collection?

By definition, these collections have to be UNORDERED or UNSORTED.

I certainly hope J4 are not going to overturn the accepted concepts of queue
and stack in order to implement these collection types. But then, nothing
they did would surprise me...

Trying to trip me up with superior knowledge <G>. Mentioning Sorted Collections
was definitely a slip of the pen ! They would be a non sequitur - either
elements are added according to the default Sort or you sub-class to get your
own customized sort !

However Ordered Collections - Yes. Recall I once suggested Sequential
Collections - but you didn't like that definition. To clarify from my on-line
help :-
--------------------------------------------
Orderedcollection
An OrderedCollection manages the storage of elements in the order in which they
were added to the collection. One of the main advantages of OrderedCollections
over Arrays is that they can grow dynamically as more elements are added. You
can use OrderedCollections to implement stacks and queues.
----------------------------------------------------------

Probably the most common use being to read in data and the latest record is
added as the last element (the COBOL file sequential approach). However, there
is nothing to stop you inserting at an index position of your choice - when you
are aware of 'positioning'. The sequential approach implies "add" (at the
bottom) with no reference to an index. Naturally with callbacks you can iterate
against all the elements in the collection, plus when a condition fails you can
get out of the callback with "quitIteration".

My example was an attempt to show retrieval in its simplest form by index.
Supporting the Ordered Collection is the PRIVATE class Sequenced Collection. Be
assured there are methods to achieve the points you made, remove one (element)
or block (of elements), replace one or block etc., even "reverse" the order of
the collection. You may not be thrilled with J4, but they aren't a bunch of
dummies - and I'm sure they will cover all points. As to FIFO/LIFO - difficult
to see that I would have a use unless I ever got into Simulation.

Is he "REALLY using OO COBOL"...?

And you so often accuse me of mis-reading you ! How the hell did you arrive at
the above crummy statement. The two volume tome 'Core Java' is quite candid that
Java had an initial set of lists - subsequently they had to back-track and add
on features which had been missed. Not my words, but 'Core Java' published by
Sun !

Using the free or cheapest tools you can get to do a job is quite distinct
from using the best tools available to do the job.

If you can't afford to use the "right" tools for the job I don't see any
dishonesty in saying so.

Eiter way, it doesn't alter the fact that using the right tools for the job
(rather than making whatever tools you have fit the job) is a preferred
strategy.

Agreed. when originally writing I was thinking of including the words 'best
tool', but let them slip by. However that is a very subjective thing, 'best'.
For the most part I would suggest that most language users in this thread would
*prefer* to facilitate features in their 'parent' language - the one they are
most comfortable with. If all else fails, then they look at other languages,
particularly if they can find a pre canned routine/function. And it is not a
question of making 'your tools fit the job'. That is ridiculous - first call
does your language handle it, (may require a bit of research for methods
available), if not, then go the 'outside' route.

As you don't quote the OCX site, we can't judge for ourselves whether the
suggested component was appropriate or not.

Without back-tracking to look up the site - be assured it DOES have rich
features, (but from the marketing blurbs, possibly some overloading - see
below). BUT without getting into OCX the point was it was easily achievable in
COBOL - and I might add, by RE-USING a large chunk of classes which I had
already written.

Trapping a Windows or keyboard event is feasible in any language that deals
with GUI development. What makes COBOL (even OO COBOL) MORE "right" for this
than VB, C, C++, or Java?

Again your misinterpretation of what I wrote. If your preference is COBOL then
COBOL is MORE 'right' if it lets you do something easily. If your 'parent' is VB
why would you go looking at C/Java for the solution - if it is easily attainable
in VB ?

People who used the recommended OCX component wouldn't care what language
they embedded it in, and they have the same re-use advantages that you
realised by doing it in COBOL.

The point here is that components transcend languages.

(That is one reason why I personally consider them a better solution...)

As stated above, I think the general tendency will probably be language of
preference. (Don't really see too many of them invoking COBOL - do you ?). If
however, and to quote your phrase, "It's only programming', and you believe
something is more viable in another language, then go for a potpourri - the
latter approach implying you carry around more baggage with your application
because you are now adding libraries for both languages.

I suggested baggage, accompanying components could be a problem - you summarily
dismissed that as irrelevant. It can come to haunt you.. Recall Jerry's problem
with that very large file - and the attendant problem of getting extracts over
to user sites. He concluded he would drop the project and take up pig farming;
as an alternative he suggested another solution - along with the data give each
user site a free disk <G>. Difficult we know with an existing and functioning
database - but the true answer goes back to design - that file design should
probably be seriously revamped. Baggage or volumes are not something that can
be dismissed lightly. The frugality on storage when this game started some 40-45
years ago, is just as valid today, providing it doesn't impede performance.

This is a total non sequitur. What has my support of components got to do
with anything you posted? The implication seems to be that by opting for a
component based approach, I am not "REALLY" using OO COBOL.

That is unfair and uncalled for.

I don't really mind whether you think I do so or not, and it is just one of
the tools I use, but I have been using it long enough that I was able to
post an analysis and explanation of it to an ASP based Web site, at a time
when you were assuring the COBOL community that "nobody understands OO
COBOL".

A deliberate misquote on your part. Certainly I had initial difficulties getting
a handle on OO and a certain gentleman PECD is on record as saying the same
thing ! I am now a reasonably happy camper - but in view of a quote below
coming from you - ????????

(Here's the link, in case you've forgotten...:
http://www.aspalliance.com/aldotnet/examples/coboldotnet.aspx)
The same link also contains the advice regarding "best tools for the job"
which you were so dismissive of above...)

This is the first time I read it, but I do recall a COBOLer jumping into clc and
asking about this MS .NET example. He was somewhat pissed off when I declined,
along the lines from any neighbour you might have up the road, "Hey you program
all day long. Why can't you tell me why my disk doesn't work or my screen
doesn't come on ? To describe it with some detail, I think, required knowledge
of the interplay between MS and Fujitsu NET COBOL - I was not prepared to trip
over my feet !

Not our Pete, this was a challenge not to be refused. Sorry but your quotes in
RED are not much more helpful than a Dick and Jane classic ! Spot didn't even
get a look in. To be absolutely blunt - why did you even bother ?

Let's educate the masses here who may not be familiar with COBOL :-

COBOL has four Divisions :-
-------------------------------------
IDENTIFICATION DIVISION.
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.
------------------------------------
OK guys get cracking and start coding in COBOL. You want more ? You want jam on
it ?.

Now your understanding has advanced to the point where you know how to
handle some Windows events in it...

Keep going...eventually you may learn how to build components with it...

If that happens, maybe we can talk.

Typically snotty wind up from you - although this time you haven't attempted to
wrap your venom with a "<G>", which of course is a caveat which translates to "
Hey ! I was only kidding", if the recipient feels offended.. (That comment on
your style was initially observed by somebody else, not me !).

Maybe we can talk ? Not likely - unless you are considerably more forthcoming in
the future. While I accept that Components ARE viable, (in certain areas), - I
don't buy into your approach. Forgive me, but it appears that you've arrived at
a set of conclusions, have cast your thoughts in concrete and then made the
problems fit the solution.. In a recent message Robert used the phrase "Your
approach was myopic". I'm afraid I agree. I said a while back he is no dummy,
but his diplomatic skills definitely need a brush-up <G> Any criticism of your
perceived and 'correct' approach results in a snarl - as in your recent snotty
reply to Donald about components.

I'll mention it seeing as you've plugged your 38 years in IT. As of this June
I've been 40 years in the game, starting in my beloved Zummerzett (Somerset). I
still prefer to call it EDP. The first 12 years spent in design - that's the
stage before wee programmers started doing chicken scratches on coding pads.
Without question you can probably lose me in programming techniques - but don't
even try when it comes to design, bearing in mind I was using random access from
day one. Get the design wrong and you are on a hiding to nothing, no matter how
much clever coding you put into it..

I've certainly been bewildered over the years by your view of OO COBOL.
Clarification has only recently surfaced. Let's take some points in progression
:

1. You used an early version of Fujitsu OO COBOL which DIDN'T include
collections. You could get those coupled with a fast Sort package for about
another $1,000 (?). Surprise, surprise. I wonder how many didn't buy that
extension - so they programmed ignoring collections(lists). I assume at the time
you fitted into that category. Since then collections may be a part of later
versions of F/J OO - but I've never seen you make reference to them.

You may have your viewpoint - but it's my firm belief that lists/collections are
an inherently important feature in the OO family, and working without them is
like having one arm held behind your back. Lists have always been a part of
design, even using procedural COBOL - I recall mention of Robert designing
chained lists. Similarly, I think Michael did the same with his good ole
favourite - BASIC.

2. Some 5 or 7 of us started chatting privately about OO COBOL. Out of the blue
you came on like the converted. You had discovered Java, but found the language
'underwhelming'. You evangelized how good Java was and started distributing Java
articles to us. Huh ? Not just me, others must have felt the same - 'We are here
to discuss OO COBOL, what has Java got to do with it ?".

3. Then the Java mode went silent. Quietly you had back-tracked to Fujitsu to do
your components - sure I know you will dispute that, but the first indications
you ever gave were that you were using Fujitsu, plus the follow-up, that Fujitsu
generates your intermediate code, so you really don't have to worry too much
about OO.

4. In the C.L.C News Group I have from time to time posted sample code, on one
occasion explaining for Warren about instantiation. This particular message was
followed up by a snide remark from you about the irrelevance. "What gives ?", I
thought, "Where's his hang up ?".

5. Then I made the mistake of saying that before you even start coding you first
have to design your class hiearchies.(I bet you missed it - Roedy Green (Java)
made the same point in one of his first messages in this thread). Back you came
- No! You don't have to do it that way. "Huh ?", I'm saying again to myself.

6. Within clc we got into some friendly discussion on Components and you
attempted to spell out your String2Num - but it was never specific code and your
quotes were, "You could do it this way or this way.....". I countered by
suggesting that using a generic dialog, and creating instances of it I could
achieve the same for a series of dialogs. I posted the code specific to an
entryfield. Your response, "It may work for you, but it appears to contain too
much maintenance". I could arrive at two conclusions from that, (1) You didn't
have a bloody clue what I was describing, or (2) Having settled on Components as
your religion of choice - no deviations allowed, no prisoners taken ! My guess -
# 2,with a slight element of #1 - because you probably didn't even read it !
Note I am NOT claiming to have found the answer, just an alternative approach,
which at the moment works - as I've said before - down the road I might fall
flat on my face. In your case that couldn't possibly happen could it ?

7. I'm sorry but your mindset is often illustrated in two of your pet phrases,
"I am not convinced.....", or "I am not persuaded....". See - I do read what you
write, and although I don't go in for copious cross-reference of messages, I do
have a bloody good memory. I'll be SOL if Alzheimer's ever kicks in !

8.. Having run through the above, which conveys my bewilderment as to your
thinking, for me we now arrive at the real kicker :-

8th August
"OO for me is only important insofar as it provides the key to component
building.

There are too many disadvantages in pure OO...lack of cross platform
Classes, difficulty in calling one set of classes from a language based on a

different Foundation, and so on. Simply by wrapping the objects as

anywhere. My fervour is for components, not OO, although I also believe that
OO is a superior model for programming than procedural.".

The first sentence implies OO is a non-starter - it doesn't fit your thinking.

Your list of disadvantages - "lack of cross platform classes" - I assume here
you are referring to portability - the tug-o-war our C and Java friends are not
winning (or as Howard said, 'Neither are they convincing anybody'). Certainly of
great significance if you are MARKETING components. But check those component
sites - so many modules have been written to address specific languages -
excluding COBOL ! Get into a master and servant relationship, the boss legally
owns the components you design and you aren't going to sell them anywhere - not
unless the boss wants to market them.

"Difficulty in calling one set of classes from a language based on a
different Foundation". Not in my book. I can happily invoke Java from my COBOL
compiler, coupled with COBOL classes written to specifically invoke Java. Same
goes for C with specific data types to handle inter language operability - a
point stressed in the Standard COBOL 2002. (Don't go asking for samples - I
don't use either feature. Disbelieve me if you wish - or go take a peep at
microfocus.com home page and see entries for Java, plus examples).

Note carefully, I am not rejecting components, but the argument that they are
the panacea or cure-all for the future of IT. And in the process your
conclusions have led you to dismiss major OO features. We now have OO-COBOL and
a sub-product called Dashwood-OO COBOL - just leave out the bits you think don't
matter.

You referred us to the following article :-

http://www.aboutlegacycoding.com/

I thought I'd check, as I didn't recall it had any source code. Correction it
does :-
------------------------------------------
Environment Division.
…
Repository.
Class OLE AS "*OLE".
…
Working-Storage Section.
01 S2Nobj-Name pic x(128) value "STRING2NUM.String2Num.1".
01 S2Nobj OBJECT REFERENCE OLE.
…
Procedure Division.
…
invoke OLE "CREATE-OBJECT"
using S2Nobj-Name
returning S2Nojb.

Now I can get the component to display its Properties by:

Invoke S2Nobj "ShowStuff" using strInput

Cf. the JavaScript above.

S2N.ShowStuff(strInput)

It isn't SO different, is it? (And you thought this OO stuff was hard <G>)
-------------------------------------------------------------------------------

Again something you probably missed from Roedy - he also commented that OO
developers needed to attain a skill set.

I didn't write the following - I think I got it from clc :-
-------------------------------------------------------------------------------
$set ooctrl(+P)
class-control.
word is class "$OLE$word.application".
working-storage section.
01 theWord object reference.
procedure division.
invoke word "new" returning theWord
invoke theWord "setVisible" using by value 1
invoke theWord "Quit"
invoke theWord "finalize" returning theWord
stop run.
-------------------------------------------------------

We *know* they both work, because you are going to tell me the first one
definitely works. And I'm going to tell you the second works because I compiled
and ran it.
BUT - to describe a concept - they are both as useful as teats on a bull !

Yours was an enjoyable article - But the above - ZOWEE ! That really gives me a
lot of information if I want to get into Components. Sorry, but I'm the Doubting
Thomas from the Twelve. Until I can see and touch the source - I ain't buying. I
want to see a concept liberally supported by source before I make my *own*
judgement, before I go down a different path. (If I want to follow through on
Components, what better than the Aussie academic, Brian Henderson-Sellers -
oodles of articles and diagrams, plus I can buy an armful of books from him, (he
is the author of course), on Component generalizations - but no source !).

Now here's the real problem I have with Components, because although you have
supplied the weapon you haven't illustrated the ammunition.

Let's talk something basic like dates. Please produce me a component. Well
certainly in COBOL we are already well armed with at least some eight Date
intrinsic functions which can be CALLED in traditional fashion from a COBOL
program. I don't use them all, but if I did would put them in a super class
"Dates" as individual methods. Coupled with those, there are generalized
methods, (mainly PRIVATE), required for date validation, format checking etc.
(Real bread and butter stuff).

Then we move on - return of validity checks and formatting output to return to
the invoker. Do you want ccyy/mm/dd, mm/dd/ccyy, dd/mm/ccyy, and all the other
possible permutations, or spelled out with names of months and days of week,
(both full and abbreviated). Throw in you also want spacing or hyphens or
obliques. So I live in Canada - better give me English and French. I live in the
US better give me those two plus Spanish and Portuguese. I don't need to expand
- go into the possibilities in Europe. Somewhere down the road our Asian friends
get into the act.
Do I really want a component that does all the above, even providing me with
Hindi and Urdu !

It doesn't require much visualizing to realize that this component is a MONSTER.
In response to queries from Howard Brazlee, you were adamant you don't maintain
components; you write a new one. Really ? How quickly do we arrive at Date
Component Version 1005 ?

The only sensible solution is the one that Roedy alluded to - we have to design
classes and in this case a whole hierarchy just for Dates, super doing the true
polymorphic functions, and sub-classed to handle formatting and spoken
languages .
It is conceivable that such a hierarchy may well embrace something like 200 or
more classes, (albeit some of them may be tables (arrays - for you other folks)
of literals - possibly spanning only a page of source). That still leaves us at
the monster level. But, with the right tools, sub-classes can be pulled to
create selective DLLs - and for the version I want I can be assured that it is
not carrying the baggage associated with Hindi and Urdu, or perhaps, the Slavic
group of languages.

None of the above occurs as a result of starting to code, although proto-typing
can begin. The first step is the overall hierachial design.

Would you seriously attempt to cover the whole gambit above in one of your
component structures ? Possibly you could, but to achieve it you need
sub-classing - and I'm not getting the message that is what you are doing. I
have no intention of going into detail here to spell it out, but it is clearly
obvious to me, and many others into "true" OO, all the above can be achieved via
hierarchies and sub-classing - so where does a Component have the edge ?

Without clear concise code as to the route you would take - how can I even guess
what your approach would be to the above problem - which is an absolute natural
for conventional use of OO with classes, sub-classes, plus throw in $10 words
like polymorphism and encapsulation..

I have been extremely blunt. I feel very angry at what I perceive to be
deception - possibly not your intent. Plus I am really alarmed that you are
sending the younger folks off ecstatically into space, and are they truly aware
of what the implicatins are with your 'shortcut' approach to OO ? The anger is
in the same vein as I'm bloody angry with George Dubya and his clan over the
mythical WMDs - seeing as I was one of the two Canucks who thought the U.S.
should go in - but would have preferred if Daddy Bush had done it 10 years ago.

I've stayed out of clc - largely because of your ramblings - and your dismissal
of the conventional concept of OO really pissed me off. I do not intend to go
into a tit for tat, trying to score points with a clever wordsmith. (I would
caution you however, Oscar Wilde was a clever wordsmith - and he finished up in
jail !).

If you make some valid counter-argument then I may respond - otherwsie silence.

In all my ramblings above I do NOT make claim to being an expert in OO. Mentally
I'm still back there in the UK with the big red letter "L" attached to my car -
"Learner - beware". Being down in the Antipodes I'm hardly likely to knock you
over anyway. However, if I did it in the UK and you told the judge "I was
walking along the pavement and he knocked me down", the judge would award you a
handsome sum of crisp pound notes. You'd be SOL in N. America - "Your honour, I
was walking along the pavement and he knocked me down". Judge responds, "Case
dismissed. You should have been walking on the sidewalk, not the pavement !".

As the cartoons used to say, 'THAT'S ALL FOLKS !".

Jimmy, Calgary AB

 

[Harley]

| > Roedy Green wrote:
| > > Don't be silly. Look at any C code designed to run on many platforms.
| > > It is riddled with macros to pull off the feat.
| > >
| > > You can do a few simple things like parse the command line, open a
| > > flat file in a platform independent way, but not even the size of int
| > > is guaranteed unless you play some games with macros.
| >
| > Well, no you can't open a file in a generic way. Opening a file on a PC
| > is different than opening a file on a mainframe. You need a special
| > library to do this:
| >
| > #ifdef I370
| > #include <lcio.h>
| > #endif
| >
| > Which works with the SAS C compiler.
| >
| > Plus, all your variables and function names need to be 8 characters or
| > less, AND mixed case is ignored, so VarA and VARA are the same, thanks
| > to the mainframe linker.
| >
| > At least it was a few years ago. Things may have chnaged since then....
|
| if it does not support fopen, it is not a std-compliant C hosted
| environment.
|
| goose

That's OK, you can write for the Z80, and ignore the mainframe.

 

[docdwarf]

I certainly appreciate the effort, but you could do with some work on
the execution

All right... thanks greatly, you... you poopie-head, you! Now, off to the
gallows you go!

(was that a good enough execution?)

DD

 

[Richard Heathfield]

[Followups set to comp.lang.c]

Who said anything about fopen? You still use fopen, but MUST have the
additional include file, which adds support for the mainframe way of
doing things.

Then Get A Better Compiler. Both C/370 and LE370 support fopen correctly,
without any need for a different include file.

The mainframe C compiler is quite happy with long var names and mixed
case.

/The/ mainframe C compiler? There are more things in heaven and earth,
Horatio, than are dreamt of in your philosophy.

I ended up writing a converter which takes the original C code, and
converts it to something that will run on the mainframe. Yuck.

Got the tee-shirt.

 

[Mark Gordon]

[Replaced comp.lang.java.programmer, where this discussion is clearly
relevant.]

It may be true that _most_ implementations of Sun's JVM at the same
version will run the same program unchanged
it may not be true that, say, a JVM
1.2 will run all Java 1.4 programs or that a servlet will run as an
applet.

Of course not. Why is this relevant?

It's relevant because there are platforms where Java 1.4 is *not*
available but earlier versions of Java are.

And yet you only need one that runs on the platform. If it conforms
with the right version of the Java specifications, that's all you need
to know, AND it alone is sufficient for writing non-trivial
applications. There are some VMs in your list that are just plain
incomplete or known to not comply with specifications, but there's no
need to write for those VMs, just as there would be no need to use an
obviously non-compliant compiler for the C language.

So how many VMs are there that provide SWING on a console *without* a
GUI installed?

I'd ammend that to say "a VM compliant with a given range of versions
of the Sun specifications". Well, then you don't have a guarantee
that your code will run, since some things like multithreading are
intentionally nondeterministic in the standard and could vary between
platforms, but at least you've got an environment designed to
encourage and make it easy to write portable code, and it's harder to
make a mistake.

So, despite what was said in another post (not necessarily by you) Java
applications *do* need to be tested on every platform you want to run
them on.

You seem to be ignoring the fact that C and C++ both provide
substantially smaller ranges of features and platforms that can be
targeted without conditional compilation. Sure, some applications can
be targeted at some combinations of platforms; but the question when
I'm making choices for an app is: can MY application be targeted at
the likely platforms of MY target audience, and how difficult will it
be to do so. In many cases, C makes that task considerably more
difficult.

In my case Java has made the task considerably more difficult because it
has forced us to upgrade the OS on a *large* proportion of our customers
servers.

And?

It follows that you will have a C implementation available, whereas you
don't always have a JVM available where you have a C implementation.

 

[Mark Gordon]

| > Roedy Green wrote:
| > > Don't be silly. Look at any C code designed to run on many
| > > platforms. It is riddled with macros to pull off the feat.
| > >
| > > You can do a few simple things like parse the command line, open
| > > a flat file in a platform independent way, but not even the size
| > > of int is guaranteed unless you play some games with macros.
| >
| > Well, no you can't open a file in a generic way. Opening a file on
| > a PC is different than opening a file on a mainframe. You need a
| > special library to do this:
| >
| > #ifdef I370
| > #include <lcio.h>
| > #endif
| >
| > Which works with the SAS C compiler.
| >
| > Plus, all your variables and function names need to be 8
| > characters or less, AND mixed case is ignored, so VarA and VARA
| > are the same, thanks to the mainframe linker.
| >
| > At least it was a few years ago. Things may have chnaged since
| > then....
|
| if it does not support fopen, it is not a std-compliant C hosted
| environment.
|
| goose

That's OK, you can write for the Z80, and ignore the mainframe.

Do you have a fully conforming Java implementation for this mainframe?

Have you checked that there is not a conforming C implementation for
this mainframe? I just looked and GNU is working on an I370 port of gcc
so if nothing else is available that will be.

 

[Chris Smith]

It's relevant because there are platforms where Java 1.4 is *not*
available but earlier versions of Java are.

Sure, just as someone elsewhere in this thread was describing a platform
with an obviously non-compliant C compiler, which caused similar
problems. You still have to make sure your platform contains a compiler
and runtime components for the language you've chosen, and Java is no
exception to that.

Given that statement, though, I'd be surprised to find too awfully many
platforms limited too awfully far in Java versions. I'd guess that
writing for 1.3 should be sufficient for very wide portability, and 1.4
should be sufficient except when there's a specific desire to target old
or unusual platforms.

So how many VMs are there that provide SWING on a console *without* a
GUI installed?

Every Java-compliant VM will provide the Swing libraries, and according
to the version and configuration will throw either AWTException or
HeadlessException when something is done that requires use of graphics
output. Any implementation that doesn't have a pixel-graphics device
and does otherwise is not compliant.

Here, you're asking for the impossible, and you know it. Java remains
as compatible as it can be.

So, despite what was said in another post (not necessarily by you) Java
applications *do* need to be tested on every platform you want to run
them on.

Yes, I'd agree with that. I can have a high degree of confidence that
my application will run on multiple platforms without that testing,
since I know the general portability problems associated with Java. But
if it were critical that the app work on those platforms, I'd definitely
test. Something always has the possibility of coming up.

In my case Java has made the task considerably more difficult because it
has forced us to upgrade the OS on a *large* proportion of our customers
servers.

Fine. That's part of the decision as well. I am far from saying that
Java should be some kind of default choice..

It follows that you will have a C implementation available, whereas you
don't always have a JVM available where you have a C implementation.

Sure. I'd be surprised if you found many platforms without a C
implementation (though someone seems to have located a mainframe
platform with a questionable one). That doesn't mean that you've got
the right cross-platform third-party libraries targeting this platform
to write a non-trivial application in a way that will also work on a
variety of other platforms. If being cross-platform is not a goal of
yours, then this won't matter... but then your decision says nothing
about C being portable or cross-platform in the real world.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Marco van de Voort]

Trapping the "STOP" key on an HP workstation. Only used this on the HP.

Separately compiled files (has that been added to the standard?) Handled
differently on the different Pascal implementations I used.

Extended Pascal standard has a module concept. Borland Pascal's (which branched
inbetween the standards) have something similar with "unit" as such.

A non-standard way to access third party libraries. Handled differently
on the different Pascal implementations I used.

Ok, you mean portable between compilers. Most dialects died out or converge
(usually towards the ansi standards). The only remaining are the Borland dialects
(BP/TP, Delphi and compatibles like FPC, VP) and the ansi standard.

While the avg BP/TP and Delphi code aren't very portable (in the same way
the avg VC++ code isn't very portable), the vast majority maps onto similar
C constructs, the rest can be considered platform dependant extensions (stuff for
dlls etc), just like e.g. VC.

I've Delphi code (compiled using FPC) on PPC and m68k systems.

Probably a number of other things that I can't remember now.

I think the Delphi diverged even further, although I helped people with
Delphi rather than using it myself.

Yes. It is more C++ than C. It includes the older dialect, but is an OOP language
on top of that.

 

[JC]

I have little to add.

You say you're angry. So was I. I'm tired of your cheap shots.

I suggest the best policy for both of us is to simply ignore each
others' posts.

Please don't quote or respond to my mail in your posts, and I'll adopt
the same policy with yours.

Hollerith Cards at dawn??

 

[Mark Gordon]

Extended Pascal standard has a module concept. Borland Pascal's (which
branched inbetween the standards) have something similar with "unit"
as such.

That may be, but since *every* Pascal variant I used provided a
different mechanism it is safe to assume _at_most_ one of them was
standard.

Ok, you mean portable between compilers. Most dialects died out or
converge(usually towards the ansi standards). The only remaining are
the Borland dialects(BP/TP, Delphi and compatibles like FPC, VP) and
the ansi standard.

I know of a lot of embedded code written in Tectronics Pascal that will
have to be maintained for at least the next 15 years. The compiler may
not be under development, but the language is hardly dead. The same
applies to HP Pascal. 3 years ago the BSO Pascal code I wrote was also
still in use.

While the avg BP/TP and Delphi code aren't very portable (in the same
way the avg VC++ code isn't very portable), the vast majority maps
onto similar C constructs, the rest can be considered platform
dependant extensions (stuff for dlls etc), just like e.g. VC.

I've Delphi code (compiled using FPC) on PPC and m68k systems.

The problem is that if Delphi does not follow the ANSI conventions for
seperate compilation of modules then you can't easily include an ANSI
Pascal module in a Delphi project. You can, on the other hand, include
an ANSI C++ module in a VC++ project.

Yes. It is more C++ than C. It includes the older dialect, but is an
OOP language on top of that.

I know what Delphi is, I just don't know how far the ANSI Pascal
standard went, since I *never* used a Pascal compiler claiming ANSI
conformance despite using several Pascal variants.

So my experience of Pascal is one of a heavily extended language with
major incompatibilities between variants. If there are *now* ANSI Pascal
compilers for most targets and a way to easily mix Delphi and ANSI
Pascal then things have changed.

 

[Marco van de Voort]

That may be, but since *every* Pascal variant I used provided a
different mechanism it is safe to assume _at_most_ one of them was
standard.

That's possible.

I know of a lot of embedded code written in Tectronics Pascal that will
have to be maintained for at least the next 15 years. The compiler may
not be under development, but the language is hardly dead. The same
applies to HP Pascal. 3 years ago the BSO Pascal code I wrote was also
still in use.

Sure, but that is the case with all kinds of embedded C's too. Except for
x86, the only other processors I programmed for ( a 68k variant and Hitachi
8051 variant) were also not fully ansi C conforming.

The fact is that the bulk of new pascal development is either in ansi or
borland dialects. (a loose guestimate is ratio 1:100). There are deviate
dialects in circulation, specially in the embedded world, but which older
language doesn't have that?

The problem is that if Delphi does not follow the ANSI conventions for
seperate compilation of modules then you can't easily include an ANSI
Pascal module in a Delphi project.

Yes, and that makes the ansi world and the Borland world pretty much separate
communities (read nearly two languages). There are some that try to bridge the
gap like GNU Pascal (a compiler that supports both BP an ansi, and is working on later
borland dialects like Delphi)

But in general the picture you sketch is no problem since the Delphi
community, codebase etc is at least a magnitude 100 larger than the
ansi-pascal community.

You can, on the other hand, include
an ANSI C++ module in a VC++ project.

You can't use it in C51 :_)

But the real trouble is a C centric view, that puts the standard
automatically in the middle. A standard is a tool to obtain some
unification, not a purpose in itself. Sometimes it works (as in the C case),
sometimes it doesn't succeed in unifying the separate dialects (as in
Pascal)

The situation you mention above is simply no problem. If one uses Delphi,
on can access the largest codebase by far (which is Borland dialects).

I know what Delphi is, I just don't know how far the ANSI Pascal
standard went, since I *never* used a Pascal compiler claiming ANSI
conformance despite using several Pascal variants.

There are two standards and one draft that was never turned into a standard.

The draft being OOP orientated (Object Pascal) in nature and sponsored by
Apple IIRC, was used (but not strictly followed) by Borland too, to create Delphi.

So my experience of Pascal is one of a heavily extended language with
major incompatibilities between variants.

I used three C/C++ compilers. VC++, Keile C51 and gcc on FreeBSD. All codebases were
pretty uncompilable on the compilers they were not written for, because of extensions,
libraries etc.

IOW I don't see a fundamental difference. True, the number of language
variants, and the average number of extensions etc are a bit less in the C
case, but that is more the language popularity.

With both languages carefully crafted codebases are somewhat portable, but
in both cases the subset is too limiting. (ansi C+posix is already a bit
better, but that is more than a mere language standard, and it still sucks
on Windows)

If there are *now* ANSI Pascal compilers for most targets and a way to
easily mix Delphi and ANSI Pascal then things have changed.

Delphi and Ansi Pascal are not really mixable, except on the most minimal
level. Pretty much like VC++ and Keile C51.