May I introduce myself to cobol?...

Hello Everyone,

one handy feature with C++ language is that it allows the
programmer to Introduce a function (win32 API function, his own
function or some formula) for the requested arguments --- when
calling a win32 API, in an effort to save storage space and reduce
the number of declared variables in the program. That said, I know
that cobol is equally resourceful as C++, (if not exceeding,
business wise) I would like to know why cobol did not implemented
such feature in the ISO 2002 standard?, or why Micro Focus did not
include it as an extension to their cobol compiler?

thanks a lot for the comments. Kellie.

case in point source code:

*> C++ Window (1)
hMainWnd = CreateWindowEx(0, ClassName,
TEXT("Main Window"),
WS_OVERLAPPEDWINDOW,
GetSystemMetrics(SM_CXSCREEN)/4,
GetSystemMetrics(SM_CYSCREEN)/4,
GetSystemMetrics(SM_CXSCREEN)/2,
GetSystemMetrics(SM_CYSCREEN)/2,
NULL, NULL, hInstance, NULL);

*> C++ Window (2)
hMainWnd = CreateWindowEx(0, ClassName,
TEXT("Main Window"),
WS_OVERLAPPEDWINDOW,
(DesktopRect.right  - 340) / 2,
(DesktopRect.bottom - 200) / 2,
340, 200,
NULL, NULL, hInstance, NULL);

*> Cobol window (3)
call WINAPI "CreateWindowExA" using
by value     0 size 4
by reference MyClass
by reference MyHeading
by value     hstyle
by value     CW-USEDEFAULT
by value     0 size 4
by value     CW-USEDEFAULT
by value     0 size 4
by value     hParent
by value     hMenu
by value     hInst
by value     0 size 4
returning       hWindow
end-call.

"Kellie Fitton" <KELLIEFITTON@YAHOO.COM> wrote in message
news:1108510305.006428.237000@g14g2000cwa.googlegroups.com...
>
> one handy feature with C++ language [ and the BASIC language. MCM] is that
it allows the
> programmer to Introduce a function (win32 API function, his own
> function or some formula) for the requested arguments --- when
> calling a win32 API, in an effort to save storage space and reduce
> the number of declared variables in the program. That said, I know
> that cobol is equally resourceful as C++, (if not exceeding,
> business wise) I would like to know why cobol did not implemented
> such feature in the ISO 2002 standard?, or why Micro Focus did not
> include it as an extension to their cobol compiler?

While I agree if would be nice to not have to go thru the COBOL coding steps
necessary replace a a function call with a dataname set up in
working-storage, such a construct does NOT save any storage space at all:
the compilers just use part of the stack to store a temporary variable, and
since you are already 'paying' for the stack space, it's free.

AFAIK, COBOL is not only stingy with functions, but has also been stingy
about allowing expressions; e.g.,

MOVE WS-MULTIPLIER * WS-COUNTER TO  DEST-FIELD
can't be done, instead you have to COMPUTE DEST-FIELD or MULTIPLY
WS-MULTIPLIER BY WS-COUNTER GIVING DEST-FIELD

Yup, COBOL can be a tad verbose. But look on the bright side: it works.

MCM

> one handy feature with C++ language is that it allows the
> programmer to Introduce a function (win32 API function, his
> own function or some formula) for the requested arguments

It is called overloading.  Several functions can have the same name
within one class, these are differentiated by the parameters supplied.
This is usually implemented using 'name mangling'.

It is most useful in doing operator overloading where an object may be
used in an expression as if it were a built-in type.

eg:

|    complex a, b, c, d;
|    a = new complex(1.0, 2.1);
|    b = new complex(1.0, 3.0);
|    c = a + b;
|    d = a + 1;

The two + operators would have quite different effects which would be
defined by two different operator methods.

The way that name mangling usually works is that the parameter types
are coded and added to the method name so that you actually wind up
with: complex.operator_plus_complex(complex self, complex a) and
complex.operator_plus_int(complex self, int i)

In other words the use of operator overloading is shorthand.

Cobol OO does not support the use of operator overloading or the use of
objects in expressions.  These things are C++'s solutions to C problems
that were never a problem in Cobol.

It is not a big deal to use unique method names for named functions
when developing a class.  Operator overloading would be impossible
without name mangling or some similar scheme and that this also works
for named functions is a bonus, but one that may cause confusion, it
may not always be obvious which particular function is being used as it
will depend on promotion.

> in an effort to save storage space and reduce
> the number of declared variables in the program.

Why do you think that is an objective or an outcome ? How are these
actually achieved ?

Well, declaring variables in cobol programs is a Major job, you need to
define the correct
type, the correct size, the correct location (working storage section,
local section and
linkage section), and you need to define all these variables with
descriptive names --- so
you can remember them when you are coding the main logic in the
procedure division.
most programs (Real World Applications) make a large number of calls to
the win32 AP's
system ---- so, if you can reduce the number of declared variables
(overloading functions),
it will make the program much smaller in size, and therefore will run
much faster, and
that should improve the performance of the application. Right?  Also,
if we can perform
two functions simultaneously (overloading) that should save CPU
execution time as well.
most C++ programmers claim that cobol have a major problem with
Prolixity, too Verbose
and very Wordy language --- so, why declare a storage in memory when we
can have the
win32 API function use a temporary location on the stack, while
executing that function?
this way, we can hit two birds with one stone, and silence our critics.
:--)  am I correct?

Regards, Kellie.

"Kellie Fitton" <KELLIEFITTON@YAHOO.COM> wrote in message
news:1108526697.928623.234600@g14g2000cwa.googlegroups.com...
> Well, declaring variables in cobol programs is a Major job, you need to
> define the correct
> type, the correct size, the correct location (working storage section,
> local section and
> linkage section), and you need to define all these variables with
> descriptive names --- so
> you can remember them when you are coding the main logic in the
> procedure division.
> most programs (Real World Applications) make a large number of calls to
> the win32 AP's
> system ---- so, if you can reduce the number of declared variables
> (overloading functions),
> it will make the program much smaller in size, and therefore will run
> much faster, and
> that should improve the performance of the application. Right?  Also,
> if we can perform
> two functions simultaneously (overloading) that should save CPU
> execution time as well.
> most C++ programmers claim that cobol have a major problem with
> Prolixity, too Verbose
> and very Wordy language --- so, why declare a storage in memory when we
> can have the
> win32 API function use a temporary location on the stack, while
> executing that function?
> this way, we can hit two birds with one stone, and silence our critics.
> :--)  am I correct?
>
No Kellie, you are not strictly correct on this occasion. (But you are not
totally wrong either  :-))

Read Richard's explanation again. (I found it informative and interesting)

As to why you are not 'correct' consider this:

1.  Most application programs do NOT make a large number of calls to the
API. This is manipulated by another layer, often provided by a third party
supplier. By tying your program directly to the API (rather than to an
abstract layer) you are sentencing it to life with ONE operating system.
That's why we use multi-tier systems and multi-tier design. Separate the
business logic from the 'presentation' layer. How do you do that?... make
your application code communicate with a memory buffer that 'represents' a
window or screen display. This is an interface to the presntation layer.

2. Your observations about defining data in COBOL are right on the button;
it IS tedious... BUT it takes no more space at run time than any other
method in any other language. I think you may be confusing source code and
runtime object code here.
Do not incorrectly assume that because data is pushed on the stack it does
not occupy space in memory. Where do you think the stack is? :-)

3. Making a program smaller in size (by overloading functions, or any other
way, short of removing code that it currently executes) does NOT guarantee
that it will run faster. It will load faster (although the difference would
be impossible for a human to detect). The time it takes to run will be
determined by the execution path (the capture time), not by the size of it.
(I covered this in an article about components some time ago; here's a link:
http://www.aboutlegacycoding.com/archives/v3/v30201.asp

4.Overloading a function does not necessarily allow it to execute
simultaneously with another instance of itself. This will be determined by
threading models and instantiation, not by overloading.

Hope this helps.

Pete.







> Regards, Kellie.
>
>

Kellie Fitton wrote:
> Well, declaring variables in cobol programs is a Major job, you need
> to define the correct
> type, the correct size, the correct location (working storage section,
> local section and
> linkage section), and you need to define all these variables with
> descriptive names --- so
> you can remember them when you are coding the main logic in the
> procedure division.
> most programs (Real World Applications) make a large number of calls
> to the win32 AP's
> system ---- so, if you can reduce the number of declared variables
> (overloading functions),
> it will make the program much smaller in size, and therefore will run
> much faster, and
> that should improve the performance of the application. Right?  Also,
> if we can perform
> two functions simultaneously (overloading) that should save CPU
> execution time as well.
> most C++ programmers claim that cobol have a major problem with
> Prolixity, too Verbose
> and very Wordy language --- so, why declare a storage in memory when
> we can have the
> win32 API function use a temporary location on the stack, while
> executing that function?
> this way, we can hit two birds with one stone, and silence our
> critics. :--)  am I correct?
>
> Regards, Kellie.

Observations:

1. I dispute "most real world applications" make direct API calls.
Specifically, API calls are not usually part of the COBOL programmer's tool
kit. COBOL programmers avoid them for several reasons: 1) They're not needed
for the kinds of problems attacked by COBOL programming, 2) They are not
portable, 3) They are difficult - sometimes impossible - to use.

2. Your definition of the "problem" - smaller size and improved
performance - is simply not a problem worthy of study to most COBOL
programmers, especially at the micro level.

"Kellie Fitton" <KELLIEFITTON@YAHOO.COM> wrote in message
news:1108526697.928623.234600@g14g2000cwa.googlegroups.com...
> if we can perform
> two functions simultaneously (overloading) that should save CPU
> execution time as well.

Only in multi-processor systems. As my late sainted mother might have said,
" there are only so many 'clocks' available from a processor, and a single
processor can only do one little thing at a time."   (Ok, so it's a pretty
tiny "might").

> if you can reduce the number of declared variables
> (overloading functions), it will make the program much smaller in size,
and therefore will run
> much faster, and that should improve the performance of the application.
Right?

Sorry, Kellie, that's an urban myth, an old wives tale, a bunch of
hooey.....All that stuff you don't do is done by the compiler anyway. (part
of what you pay for).

MCM

"JerryMouse" <nospam@bisusa.com> wrote in message
news:1116las5aadl881@news.supernews.com...
> Observations:
>....
>  3) [Direct Windows' API calls ] are difficult - sometimes impossible - to
use.

Thou, sir, speaketh but for thyself. Calling the Windows API is no different
from calling any other external support library.


MCM

> declaring variables in cobol programs is a Major job

I misunderstood the feature you were illustrating.  It wasn't
overloading at all.  You were wanting to use expressions as call
parameters.

In C (not just C++) and C like languages, expressions, including those
with function calls,  can be used where a value is required.  This
includes parameter lists for calls.

In Cobol the function call must be used to return a value to a variable
which is then used in the call.

If you had used C extensively then you would understand some of the
problems and limitations of the way that C uses expressions.  An
experienced programmer knows these issues and knows when to use them
and when not to, when casts are required, or coersion, when short
circuiting will bypass function evaluation, when to worry about order
of evaluation.

Instead of burdening Cobol programmers with all those issues, the
language avoids them completely by disallowing constructs that would
require the programmer to know about such things.

Hi Rien,
first of all, a clarification on what the win32 API
functions are. The win32 API's is a generic term
meaning "Application Programming Interface",
However, in the context of the OS Windows
programming, it means specifically the Windows
API's, which is the Lowest-Level of Interaction
between an applications and the existing
Operating System. Drivers of course have even
lower-levels code, and maybe different sets of
function calls to work with, but for the majority of
windows development, this is not a problem at
all. That said, if a business application is
running on a different OS other than windows,
then these programs are using some low-level
system library supports (Assembly api or
C++ api), which is the same thing as the win32
API's --- except it is coded for a different
environment, with different names and maybe
different entry-points. After all, why would you
re-invent the cobol wheel?  Regards.

Kellie.