July 28, 2006 Re: FLTK native in 'D'. Would that be useful? | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Reimer | John Reimer wrote:
>> C++: D:
>>
>> Fl_Window -> fl.Window (or just Window, if no name conflict)
>> Fl_Group -> fl.Group
>> fl_draw() -> fl.draw()
>
> # // import all symbols in gui.fl.window module into the 'fl' namespace
> #
> # import fl = gui.fl.window;
JJR, that's just what I need.
I have decided to port the code literally first. After all, I need to maintain the C++ and D version now. As soon as the literal port id working flawlessly, I'll pick up on the Fl_ prefix issue and possibly remove the Fl_ for both the C++ and D version and keep them compatible.
I'll set that as a general rule for myself: first a complete port, the improve on it. Otherwise, I'll lose track.
Matthias
|
July 28, 2006 Re: FLTK native in 'D'. Would that be useful? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dave | Dave wrote:
>
> Make sense?
Yes, absolutely! Another issue solved ;-)
|
July 28, 2006 Re: FLTK native in 'D'. Would that be useful? | ||||
---|---|---|---|---|
| ||||
Posted in reply to MatthiasM | MatthiasM wrote:
> Dave wrote:
>>
>> Make sense?
>
> Yes, absolutely! Another issue solved ;-)
One other note on this <g> If a member function needs to be protected or public but is not to be overridden, it can be made 'final'. Then the compiler will always call it directly and it can be inlined, etc. (the compiler is free to 'auto-finalize' anyhow but I don't think it does that now). Since private and package functions are never virtual, this always applies to them.
Likewise a whole class can be made 'final'.
I don't know if this would apply to FLTK, but if there are some core protected or public functions that are called in tight loops then it might make a performance difference even over the C++ implementation.
Thanks,
- Dave
|
July 28, 2006 Re: FLTK native in 'D'. Would that be useful? | ||||
---|---|---|---|---|
| ||||
Posted in reply to MatthiasM | On Thu, 27 Jul 2006 23:36:22 -0700, MatthiasM <dm@matthiasm.com> wrote:
> John Reimer wrote:
>>> C++: D:
>>>
>>> Fl_Window -> fl.Window (or just Window, if no name conflict)
>>> Fl_Group -> fl.Group
>>> fl_draw() -> fl.draw()
>> # // import all symbols in gui.fl.window module into the 'fl' namespace
>> #
>> # import fl = gui.fl.window;
>
> JJR, that's just what I need.
>
> I have decided to port the code literally first. After all, I need to maintain the C++ and D version now. As soon as the literal port id working flawlessly, I'll pick up on the Fl_ prefix issue and possibly remove the Fl_ for both the C++ and D version and keep them compatible.
>
> I'll set that as a general rule for myself: first a complete port, the improve on it. Otherwise, I'll lose track.
>
> Matthias
Sounds great, Matthias. I understand. :)
-JJR
|
July 28, 2006 Re: FLTK native in 'D'. Would that be useful? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dave | Dave wrote:
> MatthiasM wrote:
>> Dave wrote:
>>>
>>> Make sense?
>>
>> Yes, absolutely! Another issue solved ;-)
>
> One other note on this <g> If a member function needs to be protected or public but is not to be overridden, it can be made 'final'. Then the compiler will always call it directly and it can be inlined, etc.
Yup. In general, all C++ functions that are not virtual should be marked 'final' in D. Also, any private virtual functions must be made protected instead.
Sean
|
July 28, 2006 Re: FLTK native in 'D'. Would that be useful? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | Sean Kelly wrote:
>>
>> One other note on this <g> If a member function needs to be protected or public but is not to be overridden, it can be made 'final'. Then the compiler will always call it directly and it can be inlined, etc.
>
> Yup. In general, all C++ functions that are not virtual should be marked 'final' in D. Also, any private virtual functions must be made protected instead.
I see. I do not want to finalize too many functions, simply because I have stumbled over a few functions in FLTK that I would love to have virtual, but can't change it anymore in FLTK1.1.x because we are keeping binary compatibility within a branch, and we are not ready yet to open a true 1.2 ;-)
Matthias
PS: I am really interested in what the performance of the "D" code will be. It won't matter too much for FLTK itself, but eventually, should I port my Robotics simulation, performance is a requirement.
|
July 28, 2006 Re: FLTK native in 'D'. Would that be useful? | ||||
---|---|---|---|---|
| ||||
Posted in reply to MatthiasM | MatthiasM wrote: > Sean Kelly wrote: >>> >>> One other note on this <g> If a member function needs to be protected or public but is not to be overridden, it can be made 'final'. Then the compiler will always call it directly and it can be inlined, etc. >> >> Yup. In general, all C++ functions that are not virtual should be marked 'final' in D. Also, any private virtual functions must be made protected instead. > > I see. I do not want to finalize too many functions, simply because I I don't want to leave the impression that D code needs to be 'tuned' to match C++ in general, I don't think that's the case but the compilers are young yet <g> In general the virtual method dispatch is probably just as good, it's just that it's on by default so final is low hanging fruit if you run into call speed issues. IMHO, it's easier to write first-cut fast code with D. > have stumbled over a few functions in FLTK that I would love to have virtual, but can't change it anymore in FLTK1.1.x because we are keeping binary compatibility within a branch, and we are not ready yet to open a true 1.2 ;-) > > Matthias > > PS: I am really interested in what the performance of the "D" code will be. It won't matter too much for FLTK itself, but eventually, should I port my Robotics simulation, performance is a requirement. Many would be interested in that too... Don't know if you've seen these or not: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&calc=Calculate&xfullcpu=1 They are trivial but I think it is a good reference for D apps. w.r.t. common library functions, etc. DMD and GDC seem pretty close, w/ DMD maybe being a tad faster for integer and GDC for floating point. The main thing with any D implementation right now is to pre-allocate memory if possible before tight loops. D's easy array slicing makes it easy to do things like: const char[] s = "hello\n"; const int n = 1_000_000; const int l = s.length; char[] str; for(int i = 0; i < n; i++) { str ~= s; } to: char[] str = new char[n * l]; for(int i = 0; i < n; i++) { str[i*l .. i*l+l] = s; } - Dave |
July 29, 2006 Re: FLTK native in 'D'. Would that be useful? | ||||
---|---|---|---|---|
| ||||
Posted in reply to matthiasm | "matthiasm" <matthiasm_member@pathlink.com> wrote in message news:e9r97s$1dg2$1@digitaldaemon.com... > Hi, > > I am one of the co-authors of FLTK. I like 'D' and as a test I have > manually > translated parts of FLTK into > native 'D' code. This is obvioulsy very different from just writing a > wrapper, > more involved, but also > more rewarding. > > Before I jump into manually porting a few hundred thousand lines of code, > I > would really like to know > first if the 'D' community is interested in such a thing at all and if I > can get > sufficient support and a > reasonable number of users. > > What do you folks think? > > Matthias > > > FLTK is a Fast and Light user interface Tool Kit. It sets directly onto > the low > lever interfaces of the three > main supported platforms (MSWindows:WIN32, Unix including Linux: X11, Mac > OS X: > Carbon/Quartz). > FLTK is in use by several thousand people all over the world. It comes > with a > visual user interface > designer that spews out readable C++ (and after the coversion 'D'). > > Come check it out at http://www.fltk.org/ > > I am an author of Harmonia D gui toolkit. See: http://harmonia.terrainformatica.com/ I know FLTK and I beleive some ideas of FLTK is there already. It is different though. In particular event propagation schema. It also has lightweight HTML engine (form layout manager, renderer, form resource definition, etc. ) BTW: One of design goals of Harmonia was to create sort of FLTK but in D and for D. Package class map: http://harmonia.terrainformatica.com/map.htm It would be extremely nice if someone will take care about Linux port: http://harmonia.terrainformatica.com/pmwiki.php/Harmonia/Porting Andrew Fedoniouk. http://terrainformatica.com |
July 29, 2006 Re: FLTK native in 'D'. Would that be useful? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Fedoniouk | Andrew Fedoniouk wrote: ... some shameful self-promotion in someone else's thread <shakes head, sadly> ========================= Yes, MatthiasM ~ a native FLTK would be awesome! Are there other skins available, floating around somewhere? |
July 29, 2006 Re: FLTK native in 'D'. Would that be useful? | ||||
---|---|---|---|---|
| ||||
Posted in reply to kris | kris wrote: > > Yes, MatthiasM ~ a native FLTK would be awesome! Are there other skins available, floating around somewhere? I am working on it now. I have seen a few designs that are reachable via the "links" section. I do not know how current they are and if they require much or any core source code changes. For example here: http://www.tts-sf.com/alexeyp/index.php?act=themes (in FLTK lingo, they are called schemes (FLTK1) and themes (FLTK2) - no idea why ;-) |
Copyright © 1999-2021 by the D Language Foundation