|
|
Home » Community » U++ community news and announcements » 2020.2rc1
Re: 2020.2rc1 [message #55181 is a reply to message #55069] |
Fri, 16 October 2020 00:41 |
Oblivion
Messages: 1092 Registered: August 2007
|
Senior Contributor |
|
|
Hi,
There seems to be a problem with linking the latest freetype2 library (2.10.3) on Upp with GCC: 10.2.0, CLANG: 10.0.1, GNU ld: 2.35.
/usr/bin/ld: /home/maldoror/.cache/upp.out/Playground/Draw/GCC.Gui.Shared/Draw.a(FontFc.o): in function `Upp::GetFontInfoSys(Upp::Font)':
FontFc.cpp:(.text._ZN3Upp14GetFontInfoSysENS_4FontE+0x11a): undefined reference to `FT_Get_X11_Font_Format(FT_FaceRec_*)'
This can be fixed in FontFc.cpp, by putting the mentioned function into a C block:
extern "C" {
FT_EXPORT( const char* ) FT_Get_X11_Font_Format( FT_Face face ); // Put here to avoid include path issues...
}
As a side note FT_Get_X11_Font_Format function name seems to be deprecated with v2.10.
Best regards,
Oblivion
Github page: https://github.com/ismail-yilmaz
upp-components: https://github.com/ismail-yilmaz/upp-components
Bobcat the terminal emulator: https://github.com/ismail-yilmaz/Bobcat
[Updated on: Fri, 16 October 2020 00:49] Report message to a moderator
|
|
|
|
Re: 2020.2rc1 [message #55186 is a reply to message #55180] |
Fri, 16 October 2020 09:55 |
|
mirek
Messages: 13975 Registered: November 2005
|
Ultimate Member |
|
|
Klugier wrote on Fri, 16 October 2020 00:30The idea is that someday we become mainstream Beside that we could introduce some mainstream things still offering our uniqueness. In such case I do not think this big change in the philosophy or simplicity. I still think that we should keep with the best standards and practices for C/C++ if applicable. So moving in some areas towards mainstream solution is not something that we should afraid of. This will give us broader horizons
If we become mainstream, maybe so will become "using namespace"
Realistically, I agree with most things in "mainstream", but there are several dogmas that seem out of context. This is one of them...
Think about what you gain / loose by having / not having using namespace Upp in the header....
In practical terms, with using namespace, you can use U++ types without qualification at the risk of nameclash with either your own code or some other namespace that you have are "using". In the case of nameclash, you have to explicitly qualify namespace. Note that there also is no chance for error: nameclash is reported at compile time.
Without "using namespace", you have to qualify everything. Does not seem like a win option to me...
BTW, now thinking about it, I really dislike
namespace Upp {
#define LAYOUTFILE <Rajce/Rajce.lay>
#include <CtrlCore/lay.h>
} // namespace Upp
- that is something we should fix in the next release. This should work without Upp... I think the most correct fix is in the Layout designer - add namespace setting to .usc file and make layout designer to use it / insert into .lay....
Mirek
[Updated on: Fri, 16 October 2020 10:03] Report message to a moderator
|
|
|
|
|
|
|
Re: 2020.2rc1 [message #55224 is a reply to message #55221] |
Tue, 20 October 2020 21:03 |
Tom1
Messages: 1212 Registered: March 2007
|
Senior Contributor |
|
|
Hi Mirek,
Not missed! I have been working with this since day one it was released and have no complaints so far.
Thanks and best regards,
Tom
EDIT: Well not this, but the RC2 of course!
[Updated on: Tue, 20 October 2020 21:04] Report message to a moderator
|
|
|
Goto Forum:
Current Time: Thu Apr 25 01:58:07 CEST 2024
Total time taken to generate the page: 0.06971 seconds
|
|
|