Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » The plan....
Re: The plan.... [message #18537 is a reply to message #18536] Tue, 07 October 2008 12:32 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
koldo wrote on Tue, 07 October 2008 05:59

Hello luzr

I mean, as String seems to be the by default option, it tends to produce some mistakes as programmers tend to use it in functions that usually are going to be used worldwide.



It works quite well as long as you use UTF-8.

Quote:


Perhaps it would be better that the by default String would be international. In addition it would be possible to have other types with smaller sizes for special things like binary files management.



Actually, I would say that String is used to store texts in only about 50% of usages, i18n texts in only 20% Smile

Anyway, I believe that the correct way is UTF-8. Note also that there is HUGE performace difference between String and WString (more than magnitude). So if you e.g. have any map of names (of e.g. employees), your software might run 10x faster if they are stored as UTF-8.

Of course, this also means WString<->String flupping if you are about to manipulate individual characters, but IME this is not that big problem.

Mirek
Re: The plan.... [message #18541 is a reply to message #18537] Tue, 07 October 2008 13:13 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3354
Registered: August 2008
Senior Veteran
Hello luzr

Sorry, I thought that to comply with UTF8 it was necessary to use WString.

In some minutes I am going to report an error in FileSel.cpp related with this, really confirming it:

The struct FileIconMaker has a member declared String file. If the file name has non english characters the function virtual Image Make() does not work.

To solve it I simply change this in FileSel.cpp:

for(int i = 0; i < 2; i++) {
     SHFILEINFO info;
     SHGetFileInfo(file, dir ? FILE_ATTRIBUTE_DIRECTORY : FILE_ATTRIBUTE_NORMAL, &info, sizeof(info),

with this;

WString wfile = file.ToWString();
for(int i = 0; i < 2; i++) {
     SHFILEINFOW info;
     SHGetFileInfo(wfile, dir ? FILE_ATTRIBUTE_DIRECTORY : FILE_ATTRIBUTE_NORMAL, &info, sizeof(info),

and it works.

It is not a problem with String type. It is just that we have to check our code with international samples!.

Best regards
Koldo


Best regards
IƱaki
Re: The plan.... [message #19573 is a reply to message #17646] Wed, 17 December 2008 19:18 Go to previous message
Sender Ghost is currently offline  Sender Ghost
Messages: 301
Registered: November 2008
Senior Member
luzr wrote on Sun, 24 August 2008 22:56


OK, feel free to add to the list.

Mirek


Firstly, we can use static code analysis tools to improve existing Ultimate++ code base, such as (open source; in alphabetical order): Clang Checker, CppCheck, FlawFinder, Sparse, Splint, Yasca and so on. Or send request to Coverity as open source software (e.g. the LAMP stack). Example of FlawFinder v1.27 output you can see in the file attachment.
Also, we can create own static analysis tool inside TheIDE based on (future preprocessed) Assist++ information and existing (probably converted) analysis rules. Examples: Eclipse PDT, JetBrains IntelliJ IDEA.

Secondly, add support for LLVM front end for GNU GCC as compiler and linker.

[Updated on: Fri, 19 December 2008 21:48]

Report message to a moderator

Previous Topic: Releases thoughts....
Next Topic: MMX - no gain again...
Goto Forum:
  


Current Time: Thu Mar 28 10:18:47 CET 2024

Total time taken to generate the page: 0.01049 seconds