In well-structured code, conditional loops should always prove to be the most elegant approach.Tenaja wrote:It can be elegant, but if one of the exit conditions is only combined with a handful of other specific conditions (i.e. nested deep in some IF's), placing that whole pile into the conditional loop test can be ugly, confusing, and slower since the condition is tested with every iteration... And is no longer elegant.
Maybe you can add an internal break_level for inner loops?Fred wrote:It's the plan, it's just not implemented yet.User_Russian wrote:Why aren't you using goto?
Bkeak 2 can be translated like this in C.Code: Select all
for (uint8_t i=0; i<10; i++) { for (uint8_t x=1; x<100; i++) { goto break2; // This Bkeak 2 in PB. } } break2:;
Code: Select all
#include <stdio.h>
unsigned long long break_level;
#define break_with_level(level) break_level=level-1; break;
#define check_break_level if(break_level>0) { break_level--; break; }
int main() {
break_level = 0; for (int i=0; i<10; i++) {
break_level = 0; for (int j=0; j<10; j++) {
break_level = 0; for (int k=0; k<10; k++) {
break_with_level(3);
printf("end of k loop\n");
}
check_break_level;
printf("end of j loop\n");
}
check_break_level;
printf("end of i loop\n");
}
return 0;
}
Stay cool and wait and see. The first goal should be that Pb under C runs as stable as it does now with the current language set.StarBootics wrote:Will all this be introduced into the PureBasic language
Code: Select all
; ; Type, Bytes, Min, Max, C Type
;;ul.ul[0] ; ULong, 4, 0, 4294967295, unsigned long, unsigned int, DWORD(C++)
;;uq.uq[0] ; UQuad, 8, 0, 18446744073709551615, unsigned long long, ULONGLONG
;;ld.ld[0] ; LDouble, 10, -3.4e-4932, 1.1e+4932,long double(19 decimal places)
Code: Select all
; #PB_Compiler_Unicode = 1 (PB v5.4+ dropped Ascii compiles)
Structure ScanAllTypes ;-!PB Datatypes
; Allows 1 Define for all datatypes to be scanned.
; Define *p.ScanAllTypes = @somevariable or *somememory
; Consider as a StructureUnion. Takes no memory and overflow is not checked.
; Ex. *p\d[i] ; 'i' can be incremented in a loop without compiler error.
; ; Type, Bytes, Min, Max, C Type
b.b[0] ; Byte, 1, -128, 127, char, bool(C++)
a.a[0] ; Ascii, 1, 0, 255, unsigned char, UCHAR, BYTE
c.c[0] ; Character, 2, 0, 65535, unsigned short, USHORT
u.u[0] ; Unicode, 2, 0, 65535, unsigned short, USHORT
w.w[0] ; Word, 2, -32768, 32767, short, VB6 integer
l.l[0] ; Long, 4, -2147483648, 2147483647, long, int (long & $FFFFFFFF = unsigned)
;;ul.ul[0] ; ULong, 4, 0, 4294967295, unsigned long, unsigned int, DWORD(C++)
i.i[0] ; Integer, 4, -2147483648, 2147483647, long, int(x86 or 32-bit),sizeof*
;i.i[0] ; Integer, 8, -9223372036854775808, 9223372036854775807, long long(x64 or 64-bit),sizeof*
q.q[0] ; Quad, 8, -9223372036854775808, 9223372036854775807, long long
;;uq.uq[0] ; UQuad, 8, 0, 18446744073709551615, unsigned long long, ULONGLONG
f.f[0] ; Float, 4, -1.175494e-38, 3.402823e+38, float (6 decimal places)
d.d[0] ; Double, 8, -2.2250738585072013e-308, 1.7976931348623157e+308, double (15 decimal places)
;;ld.ld[0] ; LDouble, 10, -3.4e-4932, 1.1e+4932,long double(19 decimal places)
;;s.s ; String$, 2/char + 2 for chr(0), , wchar_t, TCHAR
;s.s[0] ; FAIL, -> *p = @x$, *p\s[0] = IMA ERROR.
s.s{1}[0] ; {FixedLen}, 2/char, , char *, char var[] <-- Convert to Ascii
ss.s[0] ; Scan String array.
;s.s[0] ; FAIL, -> *p = @x$(), *p\s[1], *p\s[2], etc.
;s.s[0] ; OK, -> *p = @x$, *p\s[1], *p\s[2], etc.
;ss.s[0] ; OK, -> *p = @x$(), *p\ss[1], *p\ss[2], etc.
EndStructure
100% correct STARGATE.STARGÅTE wrote:Just because a C-compiler is used in the backend does not mean that the C-syntax is adopted into PB! Of course not!
All items you listed are feature request for the PureBasic syntax but they are not directly correlated to the compiler backend change.
It's me or you are little bit rough, it's probably me ...STARGÅTE wrote:Just because a C-compiler is used in the backend does not mean that the C-syntax is adopted into PB! Of course not!
All items you listed are feature request for the PureBasic syntax but they are not directly correlated to the compiler backend change.
Thought I might join the party with my simple response :
+1 ... that will do nicely for meJosh wrote:Stay cool and wait and see. The first goal should be that Pb under C runs as stable as it does now with the current language set.
... Exactly!!kenmo wrote:I think everyone should relax
Fred & team know PureBasic internals better than all of us. They know the pros and cons of what they're doing, and I'm sure they'll make it as backwards-compatible as possible. Also, it's the PB team... you know they love simplified toolchains and fast write-and-run cycles!
It's newly announced, and some people are already asking for specific C output for PB input snippets?! Too soon