Open source my OIOIC, a completely new object-oriented mechanism for the C.

[pervise.zhao]

Looking at Chapter 3: Single Inheritance of your tutorial (English), all of your code is presented as snapshots. Since I have not downloaded OIOIC to follow the directions, perhaps you could post the code necessary for that example to compile (I use GCC).

Based on that, I'll be happy to write the corresponding C++ code for comparison. I already noticed that you appear to have a LOT of custom datatypes that don't all appear to be defined in the code you posted.

EDIT: Never mind the first part, I saw the download link for the source code. I find it somewhat odd that the source code for such a simple application spans 20 files. I find it stranger that you are creating aliases for built-in data types. Why should float be refered to as SR32, for example?

I am working on the corresponding C++ code now.

[/CODE]

Even though all examples are assumed the Visual C++, but a minor modification will make them to adapt to GCC in Linux/Unix. Perhaps the necessary changes are:

1. In the “oioic.h” file, postfix “LL” for the following each macro, as follows:
#define MSKOS 0xFFFF000000000000LL
#define MSKHO 0x0000FFFFFFFF0000LL
#define MSKSO 0x000000000000FFFFLL

#define OID_OICOS 0x0001000000000000LL
#define OID_UNIX 0x0002000000000000LL
#define OID_LINUX 0x0003000000000000LL
#define OID_WINDOWS 0x0004000000000000LL

2. In the “oioic.h” file, define OID_OS as OID_LINUX, as follows:
#define OID_OS OID_LINUX

3. In the “ho.h” file, postfix “LL” for the “0x0000xxxxxxxx0000” in commentary, as follows:
/* #define OID_HO (0x0000xxxxxxxx0000LL | OID_OS) /-* HO’s OID.*-/ */


This is a good thing to to write the corresponding C++ code for comparison. Look forward to your results of the comparison

SR32 is the data type of 32 bits signed real number.
UR32 is the data type of 32 bits unsigned real number.

[Phoenixz]

I'm still reading. I find it quite interesting, but I do think pervise.zhao is fighting a losing battle and I don't know C++ so well, but C++ haas a lot of things different, and I kinda like code that is neat, but 3000 lines to do a 40 line job? kinda way OTT.

[WingedPanther]

Even though all examples are assumed the Visual C++, but a minor modification will make them to adapt to GCC in Linux/Unix. Perhaps the necessary changes are:

1. In the “oioic.h” file, postfix “LL” for the following each macro, as follows:
#define MSKOS 0xFFFF000000000000LL
#define MSKHO 0x0000FFFFFFFF0000LL
#define MSKSO 0x000000000000FFFFLL

#define OID_OICOS 0x0001000000000000LL
#define OID_UNIX 0x0002000000000000LL
#define OID_LINUX 0x0003000000000000LL
#define OID_WINDOWS 0x0004000000000000LL

2. In the “oioic.h” file, define OID_OS as OID_LINUX, as follows:
#define OID_OS OID_LINUX

3. In the “ho.h” file, postfix “LL” for the “0x0000xxxxxxxx0000” in commentary, as follows:
/* #define OID_HO (0x0000xxxxxxxx0000LL | OID_OS) /-* HO’s OID.*-/ */


This is a good thing to to write the corresponding C++ code for comparison. Look forward to your results of the comparison

SR32 is the data type of 32 bits signed real number.
UR32 is the data type of 32 bits unsigned real number.

So what you are saying is: the generated code is not cross-platform. That's a bit inconvenient.

You have started responding to my analysis. Ultimately, it's the difference between 15 vs 5 files, 3000 lines vs 50 lines, many many many typedefs vs 2 classes, well-contained coded versus code sprawl across files.

What you have done is a brilliant bit of programming that does a great job of giving an OO feel to the C language, but at a significant cost. I cannot imagine trying to do a large project in this, especially since it seems to require violating good programming practices to make it work.

[pervise.zhao]

I'm still reading. I find it quite interesting, but I do think pervise.zhao is fighting a losing battle and I don't know C++ so well, but C++ haas a lot of things different, and I kinda like code that is neat, but 3000 lines to do a 40 line job? kinda way OTT.

Do not use the number of rows or pages of the code to measure the complexity of a programme. If we write a programme as simple as "Hello, world", not need OO at all. In reality, a software is much more complex, no such simple car, ship, amphicar ...

[pervise.zhao]

The name of example 3 code and example 2 code are the same, it is "Factory.tar.gz", But their contents are not the same, NOTICE, not to cover one another when download one.

[pervise.zhao]

So what you are saying is: the generated code is not cross-platform. That's a bit inconvenient.

You have started responding to my analysis. Ultimately, it's the difference between 15 vs 5 files, 3000 lines vs 50 lines, many many many typedefs vs 2 classes, well-contained coded versus code sprawl across files.

What you have done is a brilliant bit of programming that does a great job of giving an OO feel to the C language, but at a significant cost. I cannot imagine trying to do a large project in this, especially since it seems to require violating good programming practices to make it work.

I think, for beginners, it requires time to experienced the tremendous energy of OIOIC. I do not think this is a huge cost to use OIOIC, but I think this will greatly reduce costs. I very much look forward to everyone's views, whether your comments are positive or negative.

[WingedPanther]

Here's a more details response, then.
From a philosophical standpoint, I believe that anything that is auto-generated should be left alone. I immediately run into a problem in example 3 when, in step 6, you modify oioic.h. Again, you make changes to ho.c, which to my mind should not be necessary. There are numerous declarations of constants, which are not obviously or automatically kept distinct. The overall result is that you cannot simply take your car.* files and use them in another project without modifying a lot of other files in the other project. The same is true of the vehicle.* files. Because so much is inter-related, the potential for bugs with a small change strikes me as huge. Debugging strikes me as a nightmare.

[pervise.zhao]

Here's a more details response, then.
From a philosophical standpoint, I believe that anything that is auto-generated should be left alone. I immediately run into a problem in example 3 when, in step 6, you modify oioic.h. Again, you make changes to ho.c, which to my mind should not be necessary. There are numerous declarations of constants, which are not obviously or automatically kept distinct. The overall result is that you cannot simply take your car.* files and use them in another project without modifying a lot of other files in the other project. The same is true of the vehicle.* files. Because so much is inter-related, the potential for bugs with a small change strikes me as huge. Debugging strikes me as a nightmare.

NO, After you are familiar with the OIOIC, you will find they are only easy, regular, small troubles.
Of course, if there will be a C IDE that supports OIOIC in the future, these small troubles will be also gone.

[TkTech]

Ah, this was a truly amusing read.

[WingedPanther]

NO, After you are familiar with the OIOIC, you will find they are only easy, regular, small troubles.
Of course, if there will be a C IDE that supports OIOIC in the future, these small troubles will be also gone.

Have you ever worked with a language that supports OOP natively? Have you worked with any GUI libraries in an OOP language? I'm thinking of things like wxWidgets, Ultimate++, FLTK, QT or GTK+ for C++; Delphi (VCL + Object Pascal); .NET languages. In every one of those instances, I am able to simply include a component, such as a socket listener, and the only code I have to write is a #include! I do NOT every touch the library to make the component work with my code. While I need to know a component's properties, I never need to worry about incorporating its implementation details into my own project. The #include simply handles that for me.

By contrast, if you gave me a network socket class written in OIOIC, it appears that I would have to worry about merging multiple source files together with my own project, managing any potential conflicts in the various aliases used, etc. My concern, when looking at this, is simple: it looks like it makes my life harder, not easier. It also looks like it does not support many of the OOP concepts that I rely on.

As I said before, it is a brilliant creation. Unfortunately, I am having a hard time seeing how it would make my life easier. I can, however, envision it making my life harder.