|
|
|
Home » Community » U++ community news and announcements » Upp 2008.1beta2 v2 released
|
|
| Re: Upp 2008.1beta2 v2 released [message #15020 is a reply to message #15015] |
Wed, 26 March 2008 09:55   |
Tom1
Messages: 1303
Registered: March 2007
|
Ultimate Contributor |
|
|
Hi,
I just successfully compiled my project with Upp 2008.1beta2v2 using builder MSC8 but with MSC8x64 I encountered the following error:
C:\upp-beta\uppsrc\Core/Defs.h(499) : error C3861: '_byteswap_int64': identifier not found
// Tom
|
|
|
|
|
|
|
|
| Re: Upp 2008.1beta2 v2 released [message #15173 is a reply to message #15015] |
Mon, 07 April 2008 12:28 |
mr_ped
Messages: 826
Registered: November 2005
Location: Czech Republic - Praha
|
Experienced Contributor |
|
|
I'm trying all examples with beta2, and OleCalc is giving me some compilation problems, I will have to dig deeper into them to understand what's going on, but so far I found some disturbing things in other packages as well.
C:\upp\uppsrc\Core\Dli.cpp(138) : warning C4390: ';' : empty controlled statement found; is this the intent?
if(!missing)
LLOG(fn << " missing exports:");
I suggest to enclose the LLOG into {} to make sure the "if" will work even when LLOG consists of thing like "Function1(); Function2()".
c:\upp\uppsrc\core\lang.cpp(1088) : warning C4715: 'Upp::GetLanguageInfo' : not all control paths return a value
LanguageInfo *rinfo = 0; //line 1072
Shouldn't this be static? Doesn't make sense to me in current version.
And as far as I can tell calling this with lcode != 0 will reach the end of function without "return" statement.
Digging more into OleCalc itself:
The calc_idl.cpp has pending UVS conflict! 
Under MINGW I get:
C:\upp\uppsrc/Ole/Ctrl/OleCtrl.h:141: error: 'Guid' was not declared in this scope
This is due to uppsrc/Ole/util.h starting with #if defined(PLATFORM_WIN32) && defined(COMPILER_MSC)
Should be this "Ole" package compiled only under MSVC? If so, can we add some WHEN MSC into build, so it will not compile under MINGW at all, and into OleCalc/calc.cpp some #if !defined(COMPILER_MSC)
#error "This example is for MSC only!"
#endif
So anyone trying this with MINGW will get only single error message?
[Updated on: Tue, 08 April 2008 14:15] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Upp 2008.1beta2 v2 released [message #15221 is a reply to message #15216] |
Thu, 10 April 2008 09:33 |
mr_ped
Messages: 826
Registered: November 2005
Location: Czech Republic - Praha
|
Experienced Contributor |
|
|
| luzr wrote on Thu, 10 April 2008 02:59 |
| mr_ped wrote on Tue, 08 April 2008 08:13 |
Also the -Wall switch for GCC throws many warnings in Core package, some of them can be easily fixed (like for example:
C:\upp\uppsrc/Core/Parser.h:2: warning: suggest parentheses around && within ||
|
Sorry. I am not gonna to fix this. I am no slave of some idiot who does not remember that && has higher priority than || and thus adds such idiotic warning.
What will be next? What about (x * y) + 10?
The whole purpose of operator priorities is to reduce the number of parenthesis. Do you really think this code is more readable
return ((c >= 'a') && (c <= 'z')) || ((c >= 'A') && (c <= 'Z')) || (c == '_');
??
Mirek
|
Actually, I'm one of those idiots, and I prefer exactly that return like you wrote it. 
I have 2 reasons to do so... from my historic experience I don't believe compilers (it's not like I hit a bug in them every month or so, actually probably less than 1 bug per year, but it made my faith gone), and for me it's easier to "parse" parentheses in head, than to think about interaction between operators, as the parentheses is one *single* rule, and there are *many* operators. I got so far that in my source I already see ((a * b) + c); 
edit: but this is the least important "problem" from those I reported. Look rather at that weird LanguageInfo without return issue.
[Updated on: Thu, 10 April 2008 09:35] Report message to a moderator |
|
|
|
| Re: Upp 2008.1beta2 v2 released [message #15223 is a reply to message #15221] |
Thu, 10 April 2008 12:48 |
|
|
| Quote: |
I have 2 reasons to do so... from my historic experience I don't believe compilers (it's not like I hit a bug in them every month or so, actually probably less than 1 bug per year, but it made my faith gone)
|
this must be a really historical argument 
| Quote: |
, and for me it's easier to "parse" parentheses in head, than to think about interaction between operators, as the parentheses is one *single* rule, and there are *many* operators. I got so far that in my source I already see ((a * b) + c);
|
ok, that's an argument. However parentheses in every subexpression is wrong imo. I think acceptable form for you and us (not idiots )is
return (c >= 'a' && c <= 'z') || (c >= 'A' && c <= 'Z') || (c == '_');
only to split ors
|
|
|
|
|
|
| Re: Upp 2008.1beta2 v2 released [message #15225 is a reply to message #15216] |
Thu, 10 April 2008 15:02 |
mdelfede
Messages: 1308
Registered: September 2007
|
Ultimate Contributor |
|
|
| luzr wrote on Thu, 10 April 2008 02:59 |
Sorry. I am not gonna to fix this. I am no slave of some idiot who does not remember that && has higher priority than || and thus adds such idiotic warning.
What will be next? What about (x * y) + 10?
The whole purpose of operator priorities is to reduce the number of parenthesis. Do you really think this code is more readable
return ((c >= 'a') && (c <= 'z')) || ((c >= 'A') && (c <= 'Z')) || (c == '_');
|
Well, operator precedence warnings are (IMO) really not necessary, in particular for usual operator precedence rules.
I can see them useful only in few cases, as ternary operator ?:, but not on && and || which have well known precedence rules.
What I think we should make go away are other warnings :
1- unused variables. Those usually means that old/broken code is still present, or at least that code is still unpolished
2- missing return statement. That can hide nasty bugs too.
3- non virtual destructor on polymorphic classes. Well, in upp code style they may be not necessary, but can still bring bugs if classes are used in non-upp style code.
4- some automatic type conversions. In my experience, they can bring very difficult to find bugs.
5- un-initialized variables
6- some bad uses of references
7- other stuffs that now I don't remember
I don't know which of those are still caught by upp default warning style, but I've seen that compiling it with -wall bring really tons of warnings....
BTW, working on an open source well established library, I just caught a bug just enabling a bit more warnings on it... si I think that making compiler a bit stricter can bring benefits.
Max
|
|
|
|
| Re: Upp 2008.1beta2 v2 released [message #15228 is a reply to message #15015] |
Thu, 10 April 2008 15:52 |
Tom1
Messages: 1303
Registered: March 2007
|
Ultimate Contributor |
|
|
Hi,
Found a bug in 2008.1beta2:CtrlLib/FileSel.cpp line 1024 causing Desktop entry with international characters in path to be incorrectly shown on directory listing. Please apply the following fix adding FromSystemCharset(..) to the existing line of code:
dir.Add(FromSystemCharset(GetWinRegString("Desktop", "Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders", HKEY_CURRENT_USER)));
// Tom
|
|
|
|
|
|
| Re: Upp 2008.1beta2 v2 released [message #15239 is a reply to message #15224] |
Fri, 11 April 2008 11:57 |
 |
bonami
Messages: 186
Registered: June 2007
Location: Beijing
|
Experienced Member |
|
|
| luzr wrote on Thu, 10 April 2008 20:09 |
| bonami wrote on Wed, 09 April 2008 23:13 |
winXP sp2 chinese version. default language is simplified chinese.
1. why About still shows it as 2008.1 beta?
2. MinGW compiles nice. MSVC9 fails as below,
d:\work\upp\uppsrc\CtrlLib/CtrlLib.t : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss
d:\work\upp\uppsrc\CtrlLib/CtrlLib.t(112) : error C2001: newline in constant
d:\work\upp\uppsrc\CtrlLib/CtrlLib.t(179) : error C2001: newline in constant
....
|
Damn it... I know what this bug probably is, but I hoped they would fix it in MSC9...
Well, unfortunately, they did not. MSC still seems to ignore "pragma locale("C")". Means the only possible fix is to switch your codepage.
Well, maybe you could try to put even other locale somewhere. It might help.
Mirek
|
i did not quite understand "put even other locale somewhere". so i changed my Windows' regional options to US-EN as default. what i cannot change is only my Win's Chinese version.
now when it compiles as below, a cl.exe failure pops out by Windows,
----- CtrlLib ( GUI MT MSC9 DEBUG BLITZ WIN32 MSC ) (1 / 9)
----- CtrlCore ( GUI MT MSC9 DEBUG BLITZ WIN32 MSC ) (2 / 9)
----- RichText ( GUI MT MSC9 DEBUG BLITZ WIN32 MSC ) (3 / 9)
----- Draw ( GUI MT MSC9 DEBUG BLITZ WIN32 MSC ) (4 / 9)
----- plugin/bmp ( GUI MT MSC9 DEBUG BLITZ WIN32 MSC ) (5 / 9)
BLITZ: Bmp.cpp BmpWrite.cpp Icon.cpp
----- Core ( GUI MT MSC9 DEBUG BLITZ WIN32 MSC ) (6 / 9)
BLITZ: Cpu.cpp Mt.cpp lheap.cpp heap.cpp heapdbg.cpp String.cpp WString.cpp StrUtil.cpp CharSet.cpp P
ath.cpp NetNode.cpp App.cpp Stream.cpp BlockStream.cpp Log.cpp Debug.cpp Util.cpp mathutil.cpp Vc
ont.cpp Hash.cpp Callback.cpp TimeDate.cpp Value.cpp Format.cpp Convert.cpp Color.cpp Gtypes.cpp
t.cpp Lang.cpp parser.cpp XML.cpp Xmlize.cpp Uuid.cpp Ptr.cpp z.cpp Topic.cpp CoWork.cpp Dli.cpp
Win32Util.cpp
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Fri May 09 15:51:47 CEST 2025
Total time taken to generate the page: 0.01569 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
