No. GnuCOBOL would be available for that, if you want to work on it (there was an old approach for that but this is so outdated in both the GnuCOBOL and the GCC parts that it would be reasonable to start from scratch).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2020-12-12
One of the original objectives of OpenCOBOL was the eventual integration with GCC.
The lack of interest and support by the GCC community however, quickly put an end to that objective.
The writing a compiler back end is usually substantially a much bigger task than the front end.
The peculiarities of COBOL will likely make the task even larger and more complex.
In my view, such an endeavour would require a small team working full time, with a good knowledge of COBOL and the GCC back end. A rare breed indeed.
The preliminary work done is still valid, and could be used as an outline.
Personally I just do not have the time work on this project, not even in a small capacity.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It should be noted that migrating GnuCOBOL to C++ instead of C will help move forwards GC towards an OO product see existing old C++ code which is a starter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2020-12-13
Compiling the GnuCOBOL front end and RTL using C++ should not be a big problem.
Conversion of the GnuCOBOL syntax tree to the GCC abstract syntax tree format would be the second step and where the real work begins.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2020-12-14
I do not know of a single OO Cobol application.
Never seen one.
I do know that at least 2 major COBOL vendors needlessly expended millions of USD to create an OO COBOL.
I do not think the professional COBOL programmers will ever embrace OO COBOL.
I cannot imagine practical applications.
Jusy sayin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On 14/12/2020 06:54, noreply@sourceforge.net wrote:
I do not know of a single OO Cobol application.
Never seen one.
I do know that at least 2 major COBOL vendors needlessly expended
millions of USD to create an OO COBOL.
I do not think the professional COBOL programmers will ever embrace OO
COBOL.
I cannot imagine practical applications.
Jusy sayin
A large number use it - via Micro Focus Visual Cobol to name but one but
then there are the mainframe users.
At a guess hundred of thousands and no I am not one but at my age I
think I would have a major problem trying to learn OO.
Vince
.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2020-12-15
Anybody familiar with the adage "shelf ware" ?
We defined shelf ware to be software that has been purchased but never used.
Such software sits on a shelf in my cubicle.
Such a definition is apt for OO COBOL
An elaborate solution is search of a problem to solve :-)
Microsoft .NET for COBOL Programmers Paperback (Amazon - Circa 20
Best Sellers Rank: #19,613,275 in Books (See Top 100 in Books) #3,216 in Microsoft .NET
So there are probably many purchases of MF or Fujitsu OO COBOL but I gotta think they are currently of the shelf ware ilk.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please leave rants for OO COBOL out of discussions they don't belong to - that topic was about GCC integration which has exactly zero to do with OO COBOL (or C++, as far as I see).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2020-12-16
There appears to be no interest in working on GCC integration.
Perhaps it is time to set up a foundation.
- org anise proper funding
- hire and administer personnel
etc ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there any work being done to integrate COBOL into the GCC back-end.
No. GnuCOBOL would be available for that, if you want to work on it (there was an old approach for that but this is so outdated in both the GnuCOBOL and the GCC parts that it would be reasonable to start from scratch).
One of the original objectives of OpenCOBOL was the eventual integration with GCC.
The lack of interest and support by the GCC community however, quickly put an end to that objective.
The writing a compiler back end is usually substantially a much bigger task than the front end.
The peculiarities of COBOL will likely make the task even larger and more complex.
In my view, such an endeavour would require a small team working full time, with a good knowledge of COBOL and the GCC back end. A rare breed indeed.
The preliminary work done is still valid, and could be used as an outline.
Personally I just do not have the time work on this project, not even in a small capacity.
It should be noted that migrating GnuCOBOL to C++ instead of C will help move forwards GC towards an OO product see existing old C++ code which is a starter.
Compiling the GnuCOBOL front end and RTL using C++ should not be a big problem.
Conversion of the GnuCOBOL syntax tree to the GCC abstract syntax tree format would be the second step and where the real work begins.
I do not know of a single OO Cobol application.
Never seen one.
I do know that at least 2 major COBOL vendors needlessly expended millions of USD to create an OO COBOL.
I do not think the professional COBOL programmers will ever embrace OO COBOL.
I cannot imagine practical applications.
Jusy sayin
On 14/12/2020 06:54, noreply@sourceforge.net wrote:
A large number use it - via Micro Focus Visual Cobol to name but one but
then there are the mainframe users.
At a guess hundred of thousands and no I am not one but at my age I
think I would have a major problem trying to learn OO.
Vince
.
Anybody familiar with the adage "shelf ware" ?
We defined shelf ware to be software that has been purchased but never used.
Such software sits on a shelf in my cubicle.
Such a definition is apt for OO COBOL
An elaborate solution is search of a problem to solve :-)
Microsoft .NET for COBOL Programmers Paperback (Amazon - Circa 20
Best Sellers Rank: #19,613,275 in Books (See Top 100 in Books) #3,216 in Microsoft .NET
So there are probably many purchases of MF or Fujitsu OO COBOL but I gotta think they are currently of the shelf ware ilk.
Please leave rants for OO COBOL out of discussions they don't belong to - that topic was about GCC integration which has exactly zero to do with OO COBOL (or C++, as far as I see).
There appears to be no interest in working on GCC integration.
Perhaps it is time to set up a foundation.
- org anise proper funding
- hire and administer personnel
etc ...
IBM Cobol (1990's) could be OO but as you say why would you use it when procedural programming would suffice.