Future reuse of code

[WB]

Re: Future reuse of code

Roedy Green wrote:[color=blue]
> 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.[/color]

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....

[Kevin Easton]

Re: Future reuse of code

In comp.lang.c WB <su-news@bossi.com> wrote:[color=blue]
> Roedy Green wrote:[color=green]
>> 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.[/color]
>
> 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....[/color]

If it doesn't support fopen, then it's not a hosted C implementation.

If it doesn't handle identifiers case-sensitively, then it's not a
conforming C implementation at all.

- Kevin.

[Roedy Green]

Re: Future reuse of code

On Fri, 15 Aug 2003 01:21:55 GMT, Kevin Easton
<kevin@-nospam-pcug.org.au> wrote or quoted :
[color=blue]
>It is impossible to
>write incorrect Java code?[/color]

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.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

[Roedy Green]

Re: Future reuse of code

On Fri, 15 Aug 2003 01:32:00 GMT, Roedy Green <roedy@mindprod .com>
wrote or quoted :
[color=blue]
>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.[/color]

The Java version might not work either, but this is because of BUGS.
If the C version did not work, it would be because of FEATURES.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

[Kevin Easton]

Re: Future reuse of code

In comp.lang.c Roedy Green <roedy@mindprod .com> wrote:[color=blue]
> On Fri, 15 Aug 2003 01:32:00 GMT, Roedy Green <roedy@mindprod .com>
> wrote or quoted :
>[color=green]
>>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.[/color]
>
> The Java version might not work either, but this is because of BUGS.
> If the C version did not work, it would be because of FEATURES.[/color]

C code that assumes that int is 32 bit wide is BUGGY.

Is it possible to write non-portable code in C? Yes.

Does it follow from this that it is impossible to write portable code in
C? No.

- Kevin.

[Roedy Green]

Re: Future reuse of code

On Fri, 15 Aug 2003 01:43:18 GMT, Kevin Easton
<kevin@-nospam-pcug.org.au> wrote or quoted :
[color=blue]
>Is it possible to write non-portable code in C? Yes.
>
>Does it follow from this that it is impossible to write portable code in
>C? No.[/color]

Straw man argument Kevin.

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

I merely stated that writing cross platform code in C or C++ takes
considerable effort. It does not happen as a natural side effect of
coding the way it does in Java. You need to find third party
libraries supported on all your platforms. You need to generate
separate executables. You have to keep your wits about you realising
that int means different things on different platforms. To get 32
bits on ALL platforms you have to use macros, and even then, there is
no guarantee of support.

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

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

[Roedy Green]

Re: Future reuse of code

On Fri, 15 Aug 2003 01:49:11 GMT, Roedy Green <roedy@mindprod .com>
wrote or quoted :
[color=blue]
>
>You made the silly assertion that ALL C code would run unmodified on
>any platform correctly. That is nonsense.[/color]

Have not you had to fake missing 64 bit support in some C compiler?

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

[Stephane Richard]

Re: Future reuse of code

Excellent points on your side as well Peter.

And indeed my comments below :-)
--
Stéphane Richard
Senior Software and Technology Supervisor

http://www.totalweb-inc.com

For all your hosting and related needs
"Peter E.C. Dashwood" <dashwood@enter net.co.nz> wrote in message
news:3f3c207c_4 @corp-news.newsgroups .com...[color=blue]
> Thanks for the response, Stephane.
>
> Some good points.
>
> My comments below...
>
> "Stephane Richard" <stephane.richa rd@verizon.net> wrote in message
> news:HcB_a.2659 $jw4.1195@nwrdn y03.gnilink.net ...[color=green]
> > Are you saying that in 20 years, a programmer wont have the tools to[/color][/color]
make[color=blue][color=green]
> > his own programming language, his own OS should he or she decide to?[/color][/color]
And[color=blue][color=green]
> > they call that progress? I call it going backwards here. If this is[/color]
> what[color=green]
> > I'm gonna face in 20 years, I'll be making endless copies of DOS Linux[/color][/color]
and[color=blue][color=green]
> > maybe OS/2 so that I have the choice to do what I want. (note that I[/color]
> didn't[color=green]
> > mention Windows ;-)
> >[/color]
>
> No. I'm not saying that. The "limits" of my view are bounded by BUSINESS[/color]
(ie[color=blue]
> commercial) application development. I don't know what will happen in
> programming research labs (and, to be blunt, I'm not really
> interested...ho pefully, there will be some exciting developments, that[/color]
will[color=blue]
> eventually trickle through to commerce, but that isn't where my particular
> personal interest lies.)[/color]

I have to say that this is exactly where my interest lies. Because
ultimately out of these labs will come out the new intelligent stuff that
you mentionned. But I know that this simulated knowledge based analysis
does exist, I've programmed one myself in one of my contracts...bus iness
rules and knowledge saved in "intelligen tly designed databases" from which
it is possible to generate a whole process "program" based on the knowledge
incorporated in the knowledge base. There are teh so called expert system
wich are pushing their limits further and further away. The whole A.I.
industry is makign tremendous progress as well as robotics. now sure it's
possible to really push forward the "data processing" side of programming
and database related dtechnologies, SQL Server has introduced it's "natural
english query language" not perfect but a step in teh right direction to
incite non programmers to interrogate their own data based on teh business
knowledge that they have. I see that happening too :-). I guess I'm
saying that like in genetics, I wonder how good it is to see if we can do it
before we take the time to see if we SHOULD do it. if we push things to
extremes, how would you feel if a conputer was responsible for pushing the
red button to start WW3 ? no matter how much knowledge it may have to
evaluate a situation? I wouldn't feel too good about it. :-).....be
investing in nuclear shelters ASAP hehehe... It's ok to push it, it's not
ok to push it too far. Even at the scale of a user based programming
concept.


[color=blue]
>[color=green]
> > Here's my view of things, from my point of view, so you can't sue me for
> > saying this...hehehe.
> >
> > We haven't even begun to touch the tip of the iceburg into what we can[/color][/color]
do[color=blue]
> as[color=green]
> > far as software development goes. And while microsoft seems to be[/color][/color]
amazed[color=blue]
> by[color=green]
> > it's Windows, Where it's been, where it is now, and where's it's going[/color][/color]
to[color=blue][color=green]
> > be, since about 3 to 4 thousand programmers went into the making of[/color]
> Windows,[color=green]
> > I'm not impressed by those results. This having been said, So far, all
> > we've done for all these decades, is make the computer do that we dont[/color]
> want[color=green]
> > to do. (Hefty calculations, any repetitive tasks, games (not for the[/color][/color]
same[color=blue][color=green]
> > reasons of course :-). But we haven't even begun to tap into the[/color]
> potential[color=green]
> > that's ahead of us.
> >[/color]
>
> I would agree with the above. The question is HOW we unleash this[/color]
potential[color=blue]
> in the future. I believe it won't be by Procedural code. (There are many
> reasons for this... and I am NOT suggesting that NO-ONE will be writing
> procedural code. It just won't be commercially viable to develop business
> solutions in this way. In fact, it isn't even today. It's just that there
> has been no alternative for 40 years...)[/color]

**** Well the first alternative there has been was the coming of the
BASIC language which was originaly mean as the "easy way out" or
"Programmin g for the rest of us" kind of system. And that's been so for a
while after it came out. Then cam procedural programming

About 12 years ago or so, a product called Clarion (database development
system) attempted to give application development a new twist....by
attempting to manage and develop an application from the same integrated
system with screen generators, report generators, query generators,
relationship generators a good complete package at the time. to no avail
however. Almost as if the user (or dare I say lesser programmer at the
time) wanted anything to change about the way you develop an application.

Later Borland dared to push the wall of user to developer as thin as it
could get with their "ObjectVisi on" development suit. even much less
programming and any kind of logical "way of thinking" was required. it was
as visual as it could get (back then) and the main thing you had to worry
about was that reporting formulas and input masks (along with validation
rules). Their motto was (not quoted but somewhat close) create an
application with your mouse. and that failed faster than you could get a
blue screen on windows (back then, that says all...hehehe).

**** And now CASE Tools are emerging, knowledge base concepts as well,
and we have yet to see how far these technologies can go in replacing
programmers. As a programmer, I would never use something that doesn't
give me 100% of the control of what I can do with it. As a user, that need
becomes secondary to those "results" you mention but at what price? How
much more is a user (commercial or not) willing to be responsible for if
everything fails because he was empowered to do it instead of a developer?

Corporately it's not a wise business decision. not yet anyways. and the
problem today is that no business want to invest in R & D .... they seem to
expect us, the programmer, to spend the long nights and weekends in front of
our systems...devel op a revolutionary programming or user interaction
concept (give them all this free time weeks, months, years even) and if they
are interested then maybe they'll see what's left to do. How fast can a
commercial market expand itself when they aren't willing to pay for the
tools they need for their expansion? I see a circle forming itself here
:-).
[color=blue]
>[color=green]
> > To me What you are suggesting is that we let the others come up with the[/color]
> new[color=green]
> > stuff, give the users the ability adjust/change what the user did[/color][/color]
through[color=blue][color=green]
> > the use of somewhat flexible modules, and that's it for the programmer?[/color]
> I'm[color=green]
> > thinking much longer term than that. After this step of yours happens,[/color][/color]
do[color=blue][color=green]
> > you really think that everything will have been made that can be made in[/color]
> the[color=green]
> > whole computer industry?[/color]
>
> No, that is pushing my argument beyond its limits and I couldn't defend[/color]
such[color=blue]
> a position. I am not speculating on the "whole computer industry", only
> commercial systems development.[/color]

**** Good to hear, I pushed it that far to see your realm of application
scales :-)[color=blue]
>
>[color=green]
> > I beg to differ, as this approach the the future
> > of computing is one of many thousands of avenues, and I'm not saying[/color]
> there's[color=green]
> > only that way out of it, even if this ever gets made, it wont close the[/color]
> door[color=green]
> > to the rest of the potentials that still are, to date, untouched.
> >
> > But that's my vision of it, once your implementation exists and is[/color][/color]
stable,[color=blue][color=green]
> > do you think the users, ever so evolving as you say (which I do have to
> > agree that they are) will stay contended with this? that they wont want
> > more? Give a man an inch, he'll take foot, etc etc etc....I dont seen[/color]
> that[color=green]
> > human behavior stopping anytime soon. To stop that human behavior, we[/color]
> might[color=green]
> > as well stop populating since after 5 billion people we can safely[/color][/color]
assume[color=blue][color=green]
> > we've conceived every possible kind of human being? not at all :-).[/color][/color]
far[color=blue][color=green]
> > from it. And the same goes for programming. Your view is one of many
> > parralel views, views that will all equally evolve, each in their own
> > specific ways, each towards very specific and unique goals. And as long[/color]
> as[color=green]
> > they are computers, there will be programmers.[/color]
>
> The question is whether those "programmer s" will be human... We already[/color]
have[color=blue]
> computers that monitor computers. In heuristic systems, programs modify
> themselves so fast that the only way to know what happened is to monitor[/color]
it[color=blue]
> with another computer. While this is outside the arena I have defined for[/color]
my[color=blue]
> speculation, it is interesting and fun to look at.[/color]

Well see we have windows that's so fast at screwing itself that there IS NO
way to know what happened? is that a close enough adjacent frame of
thought? hehehe...sorry I had to throw that in there. I've heard of those
here and there in my many A.I. readings, and indeed this is good for the
user oriented approach. No user will spit on doing less and getting more
done in the process. even me as a programmer, if I can take Rational
Rose...Give it my frame of mind and it gives me a framework on which I can
build and finalize it's functionality, I dont see why i would spit on that
myself. However, that goes for as long as it gives me full access to what
it did and full permission to change any part of it. There will always be
people (even in the business/commercial and user oriented concepts) that
will want all the rights and all the permissions and tehre will always be
people that quite symply dont need it. the "in between" of these 2 extremes
is what will shift towards one side or another, and probably shift back and
forth until the end of times :-)...[color=blue]
>
> I see a time when some programs will attain a result (based on trial and
> error and a program modifying itself several trillion times within a few
> minutes) where it will not be (humanly) possible to know HOW it arrived at
> the solution. We'll just be thankful we HAVE a solution. There will be no
> way of knowing whether the solution is optimum. The best we could do is[/color]
run[color=blue]
> the program again and hope for a shorter result...[/color]

Ahh but then, how will they get the shorter result? Wait for a faster PC to
arrive? or get the system to reevaluate itself? I always say the short
distance between two points isn't a straight line, it's teleportation.
:-).....How many more business knowledge with the computer need, compared to
what already has (which was initialy supposed to be enough to come up with a
solution to the original problem) in order to do it faster, in less steps,
etc etc....Take the tower of hanoi, 14 steps I believe is the shortest
possible number of steps to solve it. What will tell the future computer
that it was supposed to stop at 14? if we have the knowledge that 14 moves
is in there but all the magnificant A.I. believes it can do it in less and
tries to find a solution it never will find..."endless loop" Take the film
War games, where they whole faith of humanity was a race against time
between two processes running on the same computer? a global thermal
nuclear war simulation and a game of tic tac toe? and the game of tic tac
toe won?[color=blue]
>[/color]

[color=blue]
> This means a computer will attain a result and NO-ONE will know HOW it did
> it.
>
> As a Programmer, you may find this an exciting prospect, or you may find[/color]
it[color=blue]
> terrifying. (personally, I'm in the former category). No matter how you[/color]
feel[color=blue]
> about it, it will happen (has already, actually...).
>[/color]
**** As I mention it's exciting in one category only.. and different
categories of terrifying in the rest of them :-). I think the 3 laws of
robotics, the ones created by Azimov should indeed be translated and applied
to the computing industry.
[color=blue]
> Your statement regarding computers and programmers may be suspect.
>[/color]
**** Suspect? as in?[color=blue]
>[color=green]
> > And programming languages
> > that will range from low level to high level. The way Pascal is[/color][/color]
adjusting[color=blue][color=green]
> > to the current reality of development, I dont fear that it can adapt to[/color]
> any[color=green]
> > new programming concept we can throw at it. It's been doign great at
> > adapting thus far.
> >
> > Remember, software development is not a user only oriented concept. :-)[/color][/color]
at[color=blue][color=green]
> > least not in my book.
> >
> > And that's my 0.02 cents worth :-)....(ok maybe there's a couple dollars[/color]
> in[color=green]
> > there instead :-).
> >[/color]
> I have tried to give you some return on your investment...<G >
>[/color]
**** and indeed you have, but now, I am yet another couple dollars ahead of
you :-)...

**** I must say I do enjoy exchangings thoughts and views with you, I think
we'll both come out winners in the end. :-) which I hope doesn't arrive
anytime soon :-)
[color=blue]
> Pete.
>
>
>[/color]

[ghl]

Re: Future reuse of code

"Roedy Green" <roedy@mindprod .com> wrote in message
news:mmbojvs875 oftp6v7vgilnblm e09s0bihi@4ax.c om...[color=blue]
> On Thu, 14 Aug 2003 23:02:16 GMT, Kevin Easton
> <kevin@-nospam-pcug.org.au> wrote or quoted :
>[color=green]
> >People who *think* they need an exact-width type, rather than an
> >at-least width type, are usually wrong.[/color]
>
> 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. It requires foresight 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.[/color]

Roedy, please rethink this. Anyone coding while thinking an int is 32 bits
or 16 bits is coding wrong. An int is a type, and a type defines a variable
that can contain a specified range of values. That is, a type specifies the
range of values that the named area in memory can contain. An int is defined
in C/C++ as a named area in memory that can contain the values -32768 thru
32767. It has no implied "length" or number of bits. This is different from
Java, where the creators decided to define BOTH the range of values of a
type AND the implementation memory usage.

But in C, a program designed to use an int is only guaranteed that the
memory area will be sufficient to handled the range of values of an int,
regardless of the actual number of bits used. A program written using an int
works for that variable on any standards compliant C compiler.
--
Gary

[Kevin Easton]

Re: Future reuse of code

In comp.lang.c Roedy Green <roedy@mindprod .com> wrote:[color=blue]
> On Fri, 15 Aug 2003 01:43:18 GMT, Kevin Easton
> <kevin@-nospam-pcug.org.au> wrote or quoted :
>[color=green]
>>Is it possible to write non-portable code in C? Yes.
>>
>>Does it follow from this that it is impossible to write portable code in
>>C? No.[/color]
>
> Straw man argument Kevin.
>
> You made the silly assertion that ALL C code would run unmodified on
> any platform correctly. That is nonsense.[/color]

No, I didn't. You must have me confused with someone else (I jumped in
to this thread after seeing the post about fixed size ints).
[color=blue]
> I merely stated that writing cross platform code in C or C++ takes
> considerable effort. It does not happen as a natural side effect of
> coding the way it does in Java. You need to find third party
> libraries supported on all your platforms. You need to generate
> separate executables. You have to keep your wits about you realising
> that int means different things on different platforms. To get 32
> bits on ALL platforms you have to use macros, and even then, there is
> no guarantee of support.[/color]

No, again, to get 32 bits on all platforms you just have to use long
int.
[color=blue]
> You need to test separately, and you need a ton of compile time
> macros to make the magic work.[/color]

You really don't.

However, comparing C with Java is not comparing apples with apples.
ANSI C is more portable than Java in that ANSI C code will compile and
run unmodified on more platforms - but then ANSI C is a much less rich
language than Java (in particular, it doesn't contain specific network
or windowing support). If you want to have a language as rich as Java,
you must use C-augmented-with-libraries - for example,
C-plus-Berkeley-Sockets has networking support, but the concordant
payoff is that it is less portable than plain ANSI C.

- Kevin.

[Kevin Easton]

Re: Future reuse of code

In comp.lang.c Roedy Green <roedy@mindprod .com> wrote:
[...]

....and one more thing...
[color=blue]
> I merely stated that writing cross platform code in C or C++ takes
> considerable effort.[/color]

It's true that writing portable code in C requires that you know what
you're doing, and that because the language doesn't force incorrect code
to fail, you don't always get a lot of help from smoke-tests - but
that's true of coding in C generally, and is (I would consider) a
seperate issue.

- Kevin.

[Bent C Dalager]

Re: Future reuse of code

In article <newscache$scen jh$pmi$1@tomato .pcug.org.au>,
Kevin Easton <kevin@-nospam-pcug.org.au> wrote:[color=blue]
>
>However, comparing C with Java is not comparing apples with apples.
>ANSI C is more portable than Java in that ANSI C code will compile and
>run unmodified on more platforms[/color]

One interesting feature with Java is that while the VM stays the same
across platforms (ignoring MIDP and its like), they have introduced
varying environments that cause a few of the same problems for Java
portability (across environments) as C has for its portability across
platforms. As an example, if I want my Java app to be able to run both
as a normal application and as a Java Web Start application, I must
have conditional code for opening a file. If it's a regular app, I
just use JFileChooser/FileInputStream but if it happens to be running
within a Java Web Start security constrained environment, I need to
use the jnlp file open services to do the same (and be prepared that
the user might turn down the request).

It's a bit ironic that Sun couldn't find a cross-environment solution
to this :-)

Cheers
Bent D
--
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
powered by emacs

[Marco van de Voort]

Re: Future reuse of code

In article <d9bojvkeu50eeb vd7dk3i7v7mqcq1 qnsur@4ax.com>, Roedy Green wrote:[color=blue]
> On Thu, 14 Aug 2003 23:29:07 +0000 (UTC), Marco van de Voort
><marcov@stack. nl> wrote or quoted :
>[color=green]
>>- First there must be a Java implementation
>>- Second there must be a *full* java implementation.[/color]
>
> The big advantage is you have is Sun's licensing. Basically if its is
> called J2SE you can COUNT on classes and methods being there, and
> working in a standard way. EVERY J2SE has these.[/color]

.... If a platform supports GTK, it supports GTK ...
[color=blue]
> I argued for a such standard class libraries back in 1986 October in
> an article in Byte Magazine. It is huge help no matter where you go
> to have the same interfaces to deal with. You are not starting from
> scratch with different tools for every project. With Java they are
> effectively built into the language.[/color]

For the record: I like having something like Java/SWING combination on the
shelf for special purposes. However for me for normal use the disadvantages
of are bigger than the advantages. (non native feel, versionites, speed etc,
less portable)
[color=blue]
> You can count on them just as strongly as you can count on +. That is
> not true with C++. Chances are any given tool WON'T be supported on a
> particular platform[/color]

Again, nice ideals, but are those chances actually lower than the chance
that J2SE exists on that platform? Don't think so..
[color=blue]
> Each tool handles only a handful of platforms. J2SE
> handles EVERYTHING that handled claims to be J2SE, which is basically any
> Java desktop or bigger.[/color]

However that makes J2SE much more bloated and one-size-fits-all, which
actually hampers portability.
[color=blue]
> Platform independent code happens naturally with almost no effort in
> Java. It is requires considerable effort in C++. You can't convince
> me otherwise because I have done both.[/color]

Me too for the opposite :-)

[Peter E.C. Dashwood]

Re: Future reuse of code


"James J. Gavan" <jjgavan@shaw.c a> wrote in message
news:3F3B1F7F.B 0095A32@shaw.ca ...

Jimmy,

your post raised a few questions.

Perhaps you could elucidate...?
[color=blue]
>I could suggest if you have a real problem, use OO COBOL <G>.
>
> BTW - took a very quick look at your Java Glossary, and noted your
> reference to lack of FIFO and LIFO in Java lists. Surely that can't be a
> big deal, possibly cloning your own list class. Although
> collections(lis ts) are included in both Fujitsu and Micro Focus versions
> of OO COBOL - our J4 Standards Committee currently has collections as an
> on-going topic at the moment. I doubt we'll finish up with a collection
> specifically geared to FIFO/LIFO. I can handle it quite easily at
> present from either an Ordered or SortedCollectio n :-
>[/color]
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...
[color=blue]
> *>FIFO
> move 1 to MyIndex
> invoke MyCollection "at" using MyIndex returning anElement
>
> *>LIFO
> invoke MyCollection "size" returning lsSize
> *> above gives total elements
> *> then I can do either of the following :-
>
> invoke MyCollection "at" using lsSize returning anElement
> *> OR
> move lsSize to MyIndex
> invoke MyCollection "at" using MyIndex returning anElement
>[/color]
What about retrieving subsequent members of the queue or stack?

Are you actually removing the members by retrieving them?

If you are, then the code posted will certainly work, but only so long as no
members arrive in the interim...

If you are not, then the code posted will only succed for the first member
of the queue or the last member of the stack.

Usually stacks and queues are dynamic structures with members being stored
and retrieved constantly, at random intervals.

Methods to manage them would need to be a bit more substantial than simply
getting the first member of a queue or the last member of a stack
[color=blue]
> If you haven't got what you want - James Gosling's fault. (He was born
> in Calgary).
> Guess he should have checked the Smalltalk hierarchy more closely before
> he sat down to re-invent the wheel <G>.
>[/color]
Is he "REALLY using OO COBOL"...?

[color=blue]
> I might add I can invoke both C and Java, with COBOL classes written to
> support invoking Java. I have no need at the moment as I have rich
> support of collections and GUIs built into the product.
>
> One comment that came up here in this thread early on was "Use the right
> tools for the job", not necessarily those exact words, but a point made
> often in the COBOL group. Somebody of course nodded sagely at this pearl
> of wisdom. Not always, but more often than not, that phrase translates
> to "Use the free or cheapest tools you can get to do the job". Can't
> knock people for that attitude, but I do wish they would come on in an
> 'honest' mode.
>[/color]
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.
[color=blue]
> "Using the right tool" - here's one that came up recently from Brazil
> in my Tech Support group. "How can I emulate an on-line Help file where
> you key in some characters and then the entry is highlighted in the
> Listbox ?".
>
> Quite naturally a support person suggested, "Go to this site
> www.xxxxx.com and check out their OCX".[/color]

As you don't quote the OCX site, we can't judge for ourselves whether the
suggested component was appropriate or not.
[color=blue]
>I thought, "I betcha that's
> possible in COBOL". It is. It was a piece of cake. Micro Focus has
> values for Windows events, and it looked like some four were
> possibilities. All I had to do was a quick test of the four to get the
> one which would immediately trigger an event based on a single
> keystroke.
>
> Problem solved ! Having done that as an interest exercise, I can already
> see where it can be RE-USED in real applications.
>[/color]

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?

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...)

<snip>
[color=blue]
> Note, none of the above has anything to do with the proselytizing of
> components by Pete. Dashwood - I'm talking about REALLY using OO COBOL !
>[/color]

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".
(Here's the link, in case you've forgotten...:
http://www.aspalliance.com/aldotnet/...boldotnet.aspx)
The same link also contains the advice regarding "best tools for the job"
which you were so dismissive of above...)

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

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

If that happens, maybe we can talk.

Pete.

[John D.]

Re: Future reuse of code

Roedy Green <roedy@mindprod .com> wrote in message news:<2peojvcoo efi2ns75l3on5mk r3rmomtr77@4ax. com>...
[color=blue]
> I merely stated that writing cross platform code in C or C++ takes
> considerable effort. It does not happen as a natural side effect of
> coding the way it does in Java. You need to find third party
> libraries supported on all your platforms. You need to generate
> separate executables. You have to keep your wits about you realising
> that int means different things on different platforms. To get 32
> bits on ALL platforms you have to use macros, and even then, there is
> no guarantee of support.[/color]

You argument is flawed. Java is language + libraries, C/C++ is just
a language. If will have to find third party libraries to write
C/C++ applications anyway. If you choose portable libraries then
it takes the same effort to write portable code in C/C++ as it does
in Java.

If you really need to enforce int range then it can be easily done
with typedefs (int16, int32, int64). It is just one macros buried in the
project config file. Besides, if the libraries you chose are portable
then they already define types consistent accross platforms.
[color=blue]
> You need to test separately, and you need a ton of compile time
> macros to make the magic work.[/color]

You need to test on separately even Java applications because of
differences in JavaVM implementations from different vendors/different
platforms. If you encounter these differences you are pretty much stuck
since there are no compile-time macros to help you.