Jump to content

C++ proposition

Jief_Machak

By Jief_Machak,
in Clover Development

 Share
823 posts in this topic

Recommended Posts

apianti
apianti
Posted
Posted (edited)

You would just create predefined widgets, like label, button, textbox, image, panel, etc. Then your menu information would just be the properties of these widgets, like 

<key>Menu</key>
<array>
  <key>Panel</key>
  <dict>
    <key>Properties</key>
    <whatever />
    <key>Children</key>
    <array>
      <key>Label</key>
      <dict>
        <key>X</key>
        <integer>0</integer>
        <key>WidthPercent</key>
        <integer>100</integer>
        <key>Text</key>
        <string>Hello World!</string>
      </dict>
      <key>Image</key>
      <dict>
        <key>Align</key>
        <string>Center</string>
        <key>Data</key>
        <data>...</data>
      </dict>
    </array>
  </dict>
</array>

Etc.

 

EDIT: Obviously, the best thing to use would be HTML, JS, and SVG. But it doesn't have to be that complicated...

Edited by apianti
Link to comment
Share on other sites
Slice
Slice
Posted
Posted
13 hours ago, Slice said:

The message is 


12:072  2:196  XArray::ElementAt(xsize) const -> Operator [] : index > m_len

when I pressed SPACE on Mojave icon.

The operator is

Entries[ScrollState.CurrentSelection]

Probably Entries.size() is less then index. In C version there was EntryCount which calculated as maximum index.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

You said Title should be CONST CHAR16* but I see for example this line

AboutMenu.Entries[AboutMenu.EntryCount-2]->Title = PoolPrint(L" Screen Output: %s", egScreenDescription());

This is not const as a pointer nor as a value.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted
13 hours ago, apianti said:

You would just create predefined widgets, like label, button, textbox, image, panel, etc. Then your menu information would just be the properties of these widgets, like 


<key>Menu</key>
<array>
  <key>Panel</key>
  <dict>
    <key>Properties</key>
    <whatever />
    <key>Children</key>
    <array>
      <key>Label</key>
      <dict>
        <key>X</key>
        <integer>0</integer>
        <key>WidthPercent</key>
        <integer>100</integer>
        <key>Text</key>
        <string>Hello World!</string>
      </dict>
      <key>Image</key>
      <dict>
        <key>Align</key>
        <string>Center</string>
        <key>Data</key>
        <data>...</data>
      </dict>
    </array>
  </dict>
</array>

Etc.

 

EDIT: Obviously, the best thing to use would be HTML, JS, and SVG. But it doesn't have to be that complicated...

We have 120 input parameters we want set by menu. There is a little problem to write menu.plist(.svg) for this parameters as it will be thousands lines.

Link to comment
Share on other sites
Jief_Machak
Jief_Machak
Posted
  • Author
Posted
2 hours ago, Slice said:

You said Title should be CONST CHAR16* but I see for example this line

AboutMenu.Entries[AboutMenu.EntryCount-2]->Title = PoolPrint(L" Screen Output: %s", egScreenDescription());

This is not const as a pointer nor as a value.

CONST CHAR16* means the pointer points to something const. But the pointer can still change value. Which what’s happening here.

Mas we said, let’s replace this by XStringW.

Link to comment
Share on other sites
apianti
apianti
Posted
Posted (edited)
9 hours ago, Slice said:

We have 120 input parameters we want set by menu. There is a little problem to write menu.plist(.svg) for this parameters as it will be thousands lines.

 

Nah, you can easily just bind a variable by name to a widget by adding a binding key to it's properties and storing the configuration by key/value pairs or like a registry. It will be the same amount of data either way but the way that it is maintained is different. It won't be hardcoded, it will all be located in one place, and it will be easier to understand the hierarchy. In fact you could have entire sections generated by the type of value they have. I just don't see the point in doing all this effort for c++ when it literally is only bloating the code and providing no plausible improvement over using c, and not fixing the actual problem, that the GUI is absolutely terrible and has become unwieldy....

 

EDIT: Also there is no reason you can't have separate files. You can easily have includes to other files.

Edited by apianti
Link to comment
Share on other sites
apianti
apianti
Posted
Posted (edited)

I do like c++, a lot. I just don't think it is the correct language to use and there are reasons why EDK2 does not use it. You are bloating the binary. I can see it just in the building. Look back at the previous releases and see that the size has been increasing as you add more support for c++. There is no way that you are going to get a smaller binary with c++, because c++ has much more overhead, you are having to deal with it. Constructors, destructors, new, etc, all of this is overhead that wasn't there before, they are all function calls, calling functions is more expensive than you think. There are entire architectures designed to remove the overhead of function calling with overlapping register windows that have massive amounts of registers and they operate significantly better than the same architecture without.

 

EDIT: Also, when exactly do you think you have proved me wrong?

Edited by apianti
Link to comment
Share on other sites
apianti
apianti
Posted
Posted

Seriously? I put years of work into this. So you can stop. I am pointing out facts. FACTS. You are in denial if you think I am not. If what you are doing can't stand up to me criticizing it, then it's probably not worth doing. So far all you've done is deflect and tell me I'm wrong without providing any evidence that I am. When I have provided evidence that I am correct. The binary is growing in size, period.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

I agree that menu shouldn't be hardcoded. It will be better to use common interpreting system and menu definition in separate plist file (or may be svg). The real problem is to make final result.

Now we make old system in new language.

c++ is better then c because it more strict for catching bugs. Then it provide common libraries for same operations.

Code size is growing? But we added new code not erasing old codes. When I exclude all EG_IMAGE operations code size will fall down.

Link to comment
Share on other sites
apianti
apianti
Posted
Posted (edited)

I understand the code base is growing because there is new stuff but I'm saying that literally just allocating something with new became three function calls when it was one before (or two if a zero allocate but this also adds one to the previous if done as well), i.e. calling allocation went from alloc() to new() -> alloc() -> ctor(). Same thing with delete, operators, etc. There is more overhead with everything that c++ does, and as you add more, the same functionality will consume more space for handling object oriented behavior. UEFI is not object oriented and should be small and fast, c does these same things perfectly if used correctly, it's why pretty much every other language is written in c. You can't use any of the c++ libraries because they are platform dependent, also UEFI has basically all of this functionality but in c with less overhead so I am just confused as to why there is such a push to change to c++. I have yet to hear one good reason why c++ is a better choice than c besides it's easier because it has many more subtle rules that you guys are running into problems with that would never have happened in c, the overhead is higher, and the performance is lower, just by the nature of the languages...

 

EDIT: I forgot about alloc() vs new[]() -> alloc() -> for n items do { ctor() }... Very much worse performance.

Edited by apianti
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Tiano don't want C++ because they create sources which must be compilable on all platform and on all compilers.

The universality is a obstruction for optimisation. EDK2 is full of unused codes, checks and asserts because of this.

C is very bad language while it is universal and easy to compile. 

Clover sources has huge amount of checks and type casting and anyway it still has bugs origin from bad programming style inflicted by C language. Rewriting codes to C++ causes more compact codes with more internal proofs. If I'll loose 20% performance it is nothing compared to different computers performance. Let it be more reliable.

Link to comment
Share on other sites
apianti
apianti
Posted
Posted (edited)

I think you two have a fundamental misunderstanding of the differences between the two languages, c++ is a superset of c. It is not more reliable. It contains nothing more than object oriented behavior on top of c, the creator bjorn stroustrup named it "c with classes". The only things that it does contain that would be useful is runtime typing, exceptions, and templates, which you can't even use those because they are platform and compiler dependent unless you decide to use only one version of one compiler, and rewrite all the support.... So effectively the only feature, is object oriented behavior, which has increased overhead to the same c program, and relies on the exact same code as before underneath, lol. There is also another reason why you don't see as many issues as you should with c, you use gcc or clang, and did not disable the compiler specific extensions and use c90 with all warnings. If you compile with VS, suddenly there are many more mistakes that get caught...

 

EDIT: I forgot, unused names can be stripped so having code that is unused from a library does not matter, it can be removed from the final binary when it is determined not to be used. It is a compiler optimization.

Edited by apianti
Link to comment
Share on other sites
apianti
apianti
Posted
Posted

You may be able to but it probably won't be reliable across compilers depending on the standard they conform with, I assume most conform somewhat to c++17 by now. Usually if you disable typing, it disables templates because c++17 type deduction allows you to not specify the types anymore and have them automatically determined from type information...

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...