Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

Somebody's terminal is dropping bits. I found a pile of them over in the corner.


programming / comp.lang.c / latest

Re: eficient float sign routine (thread)

comp.lang.c

Posted: 18 Minutes ago by: fir

thet copysigfn also roughly the same, maybe 5-10% faster but im not sure and have a terible headache today and cant test it too much initially i tgought this < > version would be much slower (as ifs are slow) but if there is not such big d

Re: eficient float sign routine (thread)

comp.lang.c

Posted: 21 Minutes ago by: Tim Rentsch

The output doesn't match when the input is 0.

Re: eficient float sign routine (thread)

comp.lang.c

Posted: 30 Minutes ago by: Ben

gcc, with -O2, generates shorter code for the one you didn't try: copysignf(1, x) That does not mean it's faster, but gcc probably has a reason to do what it does. Also, in many cases, it's copysign[fl]? that you want, but with some

Re: eficient float sign routine (thread)

comp.lang.c

Posted: 1 Hour 6 Minutes ago by: fir

not to say its -2*signbit(x)+1 is not all i woulkd beed as it returns +1 for zero...but if i see no difference i may left he < > version though it looks weird imo

Re: eficient float sign routine (thread)

comp.lang.c

Posted: 1 Hour 12 Minutes ago by: fir

inline float sign2(float x) { return -2*signbit(x)+1 ; } inline float sign1(float x) { return (x>0)-(x<0); } for(float f= -333333.33; f< 333333.3; f+=0.33) sum += sign2(f); i tested the efficiency and there is no visi

Re: eficient float sign routine (thread)

comp.lang.c

Posted: 1 Hour 30 Minutes ago by: fir

return -2*signbit(x)+1 ; seem to wrok, though i not tested it except one case

Re: eficient float sign routine (thread)

comp.lang.c

Posted: 1 Hour 50 Minutes ago by: fir

ok i will see, though it would be better tho have normal functions to not add/multiply not quite necessary references

Re: eficient float sign routine (thread)

comp.lang.c

Posted: 2 Hours 52 Minutes ago by: Ben

Standard C has copysign. A call to your sign(f) function is equivalent to copysign(1, f). There is also a standard signbit macro that returns 0/1 depending on the sign of the argument. These two treat NaNs differently.

eficient float sign routine

comp.lang.c

Posted: 3 Hours 28 Minutes ago by: fir

is there some ? people seem tend to use inline float sign (float x) { return (x > 0) - (x < 0); } but im not sure if it is efficient afaik float standard says that sign bit is the highest bit ot 32bit representation so maybe something

Re: cdcl and floats and doubles (thread)

comp.lang.c

Posted: 16 Hours 40 Minutes ago by: fir

i checked how it looks like in case of doubles double xxx(float x) { return x*333; } sub esp 0xc pxor xmm1 xmm1 movss xmm0 (0x406044)] ; .rdata: 0x00 0x80 0xa6 0x43 mulss xmm0 (esp+0x10) cvtss2sd xmm1 xmm0 movsdd mmword ptr (esp) xm

Re: function declarations are evil (thread)

comp.lang.c

Posted: 16 Hours 59 Minutes ago by: fir

and so what? many systems need to have its analogon .. i speak on dlls as i use windows in c world its a basic thing as its basic module so its very important and basic thing

Re: function declarations are evil (thread)

comp.lang.c

Posted: 17 Hours 14 Minutes ago by: Vir Campestris

If you've been writing C code for 10 years you should have realised by now that a DLL is a Windows feature, and not relevant to other operating systems. Andy

cdcl and floats and doubles

comp.lang.c

Posted: 17 Hours 20 Minutes ago by: fir

i find cdcl as not so stupid becouse it allows to pass any number of arguments (as te first, leftiside argument is closest to call when being push) it also allows in fact to return variable arguments when used like void foo int x int y i

Re: Shortcut operators (thread)

comp.lang.c

Posted: 20 Hours 44 Minutes ago by: Stefan Ram

No. Branches are not expensive, unless mispredicted. Use "perf stat" to find out whether you have many mispredictions. You should have much less than 1 %. /If/ you have many mispredictions, you can try indeed to replace code by

Experts would agree that my reviewers are incorrect

comp.theory

Posted: 22 Hours 57 Minutes ago by: olcott

All of the recent discussions are simply disagreement with an easily verifiable fact. Any smart software engineer with a sufficient technical background can easily confirm that H(P,P)==0 is correct: Where H is a C function that correctl

Re: function declarations are evil (thread)

comp.lang.c

Posted: 1 Day 4 Hours ago by: fir

i remember i once wrote a post here "biggest c mistake" or som,ething like that, it was one of my firsts posts here 10 years ago iirc ..i dont clearly remember but it was on thing that given symbil exported from module has a kinda globa

Re: Question for Olcott [ summing up where we are ] (thread)

comp.theory

Posted: 1 Day 9 Hours ago by: olcott

Since you always knew this: that you are a liar when you claimed that they are equivalent. to back that up. I don't think that we are getting anywhere. All of the recent discussions are simply disagreement with an easily verifiable fa

Re: size and length (thread)

comp.lang.c

Posted: 1 Day 22 Hours ago by: fir

for me its nonsense (in te context said) should be > int bytes = sizeof(array[0]) * array.length();

Re: size and length (thread)

comp.lang.c

Posted: 1 Day 22 Hours ago by: fir

i wouldnt say it sailed .. but if there us as you say it may mean people dont notice the difference and this difference possibly should be noticed more wide

Re: size and length (thread)

comp.lang.c

Posted: 1 Day 22 Hours ago by: olcott

std::vector<int> array; int bytes = sizeof(int) * array.size(); That makes the most sense to me.

Re: size and length (thread)

comp.lang.c

Posted: 2 Days 13 Hours ago by: Malcolm McLean

A lot of languages don't make it easy to determine the number of bytes used by an array. So there's no convention that "size" represents a number of bytes whilst "length" represents a number of elements. If would make sense for C, but the

Are my reviewers dishonest or technically incompetent ?

comp.ai.philosophy

Posted: 2 Days 19 Hours ago by: olcott

That H(P,P)==0 is easily verified as correct by reverse engineering what the behavior of the input to H(P,P) would be if we assume that H performs a pure x86 emulation of its input. The x86 source-code of P specifies everything that we n

Halting problem undecidability and infinitely nested simulation (V5)

comp.ai.philosophy

Posted: 3 Days 15 Hours ago by: olcott

Halting problem undecidability and infinitely nested simulation (V5) This is an explanation of a key new insight into the halting problem provided in the language of software engineering. Technical computer science terms are explained us

Re: H(P,P)==0 is proven to be correct thus refuting the halting (thread)

comp.ai.philosophy

Posted: 3 Days 21 Hours ago by: olcott

The assumption is that H(P,P) correctly emulates its input. You are required to show the execution trace of the input to H(P,P) under that assumption for one emulation and one nested emulation. The one that you provided for the emulation

Re: H(P,P)==0 is proven to be correct thus refuting the halting (thread)

comp.ai.philosophy

Posted: 3 Days 21 Hours ago by: Richard Damon

Well, I wopuld need to have the code for H to do that, since that is PART of P. It would begin as: machine stack stack machine assembly address address data code language ======== ========

Re: H(P,P)==0 is proven to be correct thus refuting the halting (thread)

comp.ai.philosophy

Posted: 3 Days 21 Hours ago by: olcott

You know that you are a liar so I challenge you to provide the execution trace that a pure single level nested emulation of the input to H(P,P) would be. Any failure to provide this basis for your damned lies will be considered direct a

Re: H(P,P)==0 is proven to be correct thus refuting the halting (thread)

comp.ai.philosophy

Posted: 3 Days 22 Hours ago by: Richard Damon

No, it is easy to verify that it does NOT. No execution path from P actually CALLS another copy of P, as your trace implies. Remember, an execution trace is supposed to show the sequence of instructions that a CPU would actually execu

H(P,P)==0 is proven to be correct thus refuting the halting problem

comp.ai.philosophy

Posted: 3 Days 22 Hours ago by: olcott

It is an easily verified fact that the execution trace provided by H(P,P) of the nested simulation of its input exactly matches the behavior of the correctly reverse-engineered nested execution trace would be. To reverse-engineer this e

size and length

comp.lang.c

Posted: 4 Days 1 Hour ago by: fir

writing dynamic arys i noticed one thing (not even noticed but like bumped my head on it): imo the size is probably appriopriate name for axemple on this what realloc takes this is teh size of ram allocked (for example 1 MB) -when to know

Re: exremally stupid error (thread)

comp.lang.c

Posted: 4 Days 12 Hours ago by: fir

cleanded the syntax a bit, like void SetupLight SetPointLight 0 1 -1100.0 0.0 0.0 7000.0 50000.0 0.30 1.9 1.3 1.3 0.01 0.01 0.01 0.18 1.1 1.1 1.1 0.01 0.01 0.01 SetPointLight 1 3 1100.0 500.0 500.0

function declarations are evil

comp.lang.c

Posted: 4 Days 16 Hours ago by: fir

i rarelu use function declarations in my code (i mean that inside ones, yhis is those of my own function in given module put up in file to be visible) but sometimes i use - and if i then change a name of function or declaration it will c

Re: exremally stupid error (thread)

comp.lang.c

Posted: 7 Days 6 Hours ago by: fir

they are float i made demo showing that one can add balls in space when pressing space hovever i made a bit of mess with some thingand as to compiler only crazy elements of syntax work (something like shattered glass), hovever the demo

Re: exremally stupid error (thread)

comp.lang.c

Posted: 7 Days 6 Hours ago by: Rosario19

if the parameter 0 1 2 3 4 5 6 are in the function defined as double example DrawLine3d(double, double, double ecc, int) the assembly code is not ok because one double is 2 ints here

Re: exremally stupid error (thread)

comp.lang.c

Posted: 7 Days 14 Hours ago by: fir

ok i implemented basics of it and it seem to work may show pieces of implementation as its maybe interesting - showing its wuite easy //catch definition if(atoms_len == 2) // ints tab if( CCS(a0, "ints") ) if( CCL(a1

Re: Who is and how to contact Jeff Lee? (thread)

comp.lang.c

Posted: 7 Days 23 Hours ago by: Scott Lurndal

Check with Georgia Tech - it looks like Jeff is/was an Alum thereof. "On the other hand, the grammar given in the current draft(s) of the ANSI C standard can be easily made LALR(1). A YACC grammar based on the Nov 11 draft was p

Who is and how to contact Jeff Lee?

comp.lang.c

Posted: 7 Days 23 Hours ago by: Philipp Klaus Krause

"In 1985, Jeff Lee published his Yacc grammar (which is accompanied by a matching Lex specification) for the April 30, 1985 draft version of the ANSI C standard. Tom Stockfisch reposted it to net.sources in 1987;" (https://www.lysator.l

Re: exremally stupid error (thread)

comp.lang.c

Posted: 8 Days ago by: fir

i must say i very get liked this _Add() pattern (based on realooc seed) in C, this simplifies typing a lot like /////////////////////////// ints spheres for(int i=0; i<100; i++) spheres.add(i); ////////// instedad of //////////

Re: exremally stupid error (thread)

comp.lang.c

Posted: 8 Days 2 Hours ago by: fir

floats[30] could be added as floats with size set to 30 initially; what i need to generate floats x ? when i generate int[100] z i only need to emit FlushOutAsm("\n .bss %.*s: %d ", ChunkLength(a4) ,

Re: exremally stupid error (thread)

comp.lang.c

Posted: 8 Days 3 Hours ago by: fir

i probably should implement in native support for chunks, the question is how to name it simple static arrays i wil made like int10000 tab1 float2048 tab2 so dynamic maybe ints tab floats tab so chunk will be chars wonder if then i

Re: simplifying c syntax & thoughts from inside the compiler (thread)

comp.lang.c

Posted: 9 Days 6 Hours ago by: fir

this is not even a trick , i just use here newline as a separator, so the rule is just if first atom is a function call (and if this is a functiob call i know becouse first scaning pass collected definition names and import names) then th

Re: simplifying c syntax & thoughts from inside the compiler (thread)

comp.lang.c

Posted: 9 Days 10 Hours ago by: luser droog

This has some similarities to the Logo language, an unparenthesized Lisp. If all your functions (and/or operators) have a fixed arity, then you can parse them straight up without needing any parens. This is actually the original way Poli

Re: exremally stupid error (thread)

comp.lang.c

Posted: 9 Days 13 Hours ago by: fir

somewjat later i will probably do an option to put this for loop not only at the begining of log line, i mean to be able to use tab[10:18] = 0; same as 10:18: tab[i] = 0;

Re: exremally stupid error (thread)

comp.lang.c

Posted: 9 Days 13 Hours ago by: fir

maybe but i trade total simplicity and mess for moving forward ..need some results.. good that anybody writes on this gropu though... sad bartc is inactive as i said i sometemes would say he writes to much about the same things but bow

Re: exremally stupid error (thread)

comp.lang.c

Posted: 9 Days 13 Hours ago by: fir

this loop form 0$ i$999$4 is a stub coz i got : (which i guess more fits) used (to break on log line after foo: and things like that) ..i changed to break on ":"+whitespace so now loop is 10:100{ something} //loop on 10 to 100 inclus

Re: exremally stupid error (thread)

comp.lang.c

Posted: 9 Days 13 Hours ago by: Ben

That may be a wasted opportunity. I've found that when things go wrong with high-levels of optimisation, 9 times out of 10 it's a opportunity to find a bug that's currently not showing up in testing yet.

Re: exremally stupid error (thread)

comp.lang.c

Posted: 9 Days 16 Hours ago by: fir

it compiles now weird subset of what i call gneralized c, nut i already made a terrible mes in the source of this compiler writing compiler is in fact not so easy, or i got things not enough retinked to dwell in swamp again this is beco

Re: exremally stupid error (thread)

comp.lang.c

Posted: 9 Days 16 Hours ago by: fir

when i discovered it dont work with O3 i dont wnat to much spoend time on it now, one need to prioritize work and there are more important things im not sure but its posible that my demo work on linux by wine emulation https://filebin

Re: exremally stupid error (thread)

comp.lang.c

Posted: 9 Days 17 Hours ago by: David Brown

If you think the problem is with stack alignments, then it is not a matter of optimisation flags. x86-64 processors require certain stack alignments for some of the SIMD instructions (which are more likely to be used in higher optimisati

Re: How to avoid an overflow during multiplication? (thread)

comp.lang.c

Posted: 9 Days 23 Hours ago by: Tim Rentsch

Yes, the statement is only about type specifiers, not other declaration specifiers. A post from Dave Thompson gave this same observation, and I have just now responded to his posting.

Re: How to avoid an overflow during multiplication? (thread)

comp.lang.c

Posted: 9 Days 23 Hours ago by: Tim Rentsch

Thank you for the follow-up (and no worries about the delay). To the best of my knowledge all of the following are true statements. K&R C did not have a void type (although some pre-standard C compilers may have had support for void).

Re: exremally stupid error (thread)

comp.lang.c

Posted: 9 Days 23 Hours ago by: fir

you should better check than talking generalities which are often false - and i say this becouse its better to know than talk false generalities becouse its misleading and harmfull ..sadly many people do that i remember i got -O3 issues

Re: ANSI C89/ISO C90 - Reference where mixing declarations and code is forbidden (thread)

comp.lang.c

Posted: 9 Days 23 Hours ago by: Tim Rentsch

But doing that would make it harder for people to read and understand, which is after all the primary purpose of the C standard.

Re: exremally stupid error (thread)

comp.lang.c

Posted: 10 Days 3 Hours ago by: David Brown

The "-funsafe-math-optimizations" flag does not give you a risk of the compiler generating bad code. It means that the generated code might not give the same results as specified by the IEEE standards - perhaps rearrangements will lea

Re: How to avoid an overflow during multiplication? (thread)

comp.lang.c

Posted: 10 Days 18 Hours ago by: Andrey Tarasevich

Oh... My mistake. Apparently I misunderstood what was being said. You mean that `cases` is a macro that unfolds into a bunch of separate `case` labels. Got it. No problems then. I missed the fact that it is spelled as `cases`. I misre

Re: How to avoid an overflow during multiplication? (thread)

comp.lang.c

Posted: 10 Days 18 Hours ago by: Andrey Tarasevich

True. With one remark: in C89/90 a declaration has to specify at least one declaration-specifier, which is a storage-class-specifier, type-specifier or a type-qualifier. Declarations that have none are illegal in C89/90 /* File

Re: How to avoid an overflow during multiplication? (thread)

comp.lang.c

Posted: 10 Days 21 Hours ago by: dave_thompson_2

(Sorry for delay, I just found this somehow went in a file folder instead of outbox) On Fri, 04 Feb 2022 21:14:59 -0800, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: .... ....

Re: exremally stupid error (thread)

comp.lang.c

Posted: 10 Days 21 Hours ago by: fir

i dont think so note they have such flags as -funsafe-math-optimizations -mfpmath=both and so on, they just turn things to ride on the edge i guess, i suspect that maybe they needed 16 bytes aligned stack frame or something, but i dont car

Re: exremally stupid error (thread)

comp.lang.c

Posted: 10 Days 21 Hours ago by: Ben

It's more accurate (usually) to say that a bug is revealed by an optimisation setting. It's possible that -Ofast introduced a bug, but that's a rather rate occurrence.

Re: exremally stupid error (thread)

comp.lang.c

Posted: 10 Days 21 Hours ago by: Kaz Kylheku

Yes; but what newsreaders need is stronger killfiles that can't be temporarily circumvented with a couple of keystrokes in situations when they report "3 new articles" and they are all killed.

Re: exremally stupid error (thread)

comp.lang.c

Posted: 10 Days 22 Hours ago by: fir

alright it was caused by -Ofast flag used to compile the library (it turns on -O3 and i got problems with this O3 already back then)

Re: exremally stupid error (thread)

comp.lang.c

Posted: 11 Days 3 Hours ago by: fir

well i should add you weak shittalkers..never say something valueable on point, first to talk shit

Re: exremally stupid error (thread)

comp.lang.c

Posted: 11 Days 5 Hours ago by: Jan van den Broek

And that is the reason that newsreaders have killfiles.

Re: exremally stupid error (thread)

comp.lang.c

Posted: 11 Days 12 Hours ago by: fir

maybe in your brainwashed world...in fact this is normal c programming

Re: exremally stupid error (thread)

comp.lang.c

Posted: 11 Days 12 Hours ago by: Kaz Kylheku

What the hell, indeed. Is it a bird? ... a plane? No! It's a dumb pollack writing incoherent nonsense about things having no relation to C. In a few minutes, we will have your local weather, followed by the bridges-and-tunnels traffic

exremally stupid error

comp.lang.c

Posted: 11 Days 12 Hours ago by: fir

i write my compiler and i got some rutine RunFrame { DrawLine3d 20.0 30.0 40.0 100.0 0.0 400.0 0xaaaa77 DrawLine3d 22.0 30.0 43.0 130.0 0.0 400.0 0xaaaa77 DrawLine3d 29.0 30.0 42.0 130.0 0.0 400.0 0xaaaa77 } I got

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 11 Days 17 Hours ago by: Chris M. Thomasson

Flip a coin; heads left, tails right. Heads, try to pop from left. Tails, try to pop from right. Just joking around here, in a sense... ;^) Actually, back in the day with my threading work, I have subdivided a lock-free stack into re

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 11 Days 21 Hours ago by: Mr Flibble

And what happens if Left is empty, Right is non-empty and you call pop_front()? /Flibble

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.theory

Posted: 11 Days 21 Hours ago by: olcott

// Tape_Type implements a two-way Turing machine tape. // Right contains Tape_Head >= 0 values (right expansion) // Left contains Tape_Head < 0 values (left expansion) // // Grows with Right.push_back() as Tape_Head increases above 0.

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 6 Hours ago by: tth

Not with any version of the C language.

Re: Implementing a two-way Turing Machine tape as an improvement to std::deque (thread)

comp.ai.philosophy

Posted: 12 Days 6 Hours ago by: Mr Flibble

You cannot implement all of std::deque's member functions meeting std::deque requirements using your chosen data structure of two std::vectors. /Flibble

Re: ANSI C89/ISO C90 - Reference where mixing declarations and code (thread)

comp.lang.c

Posted: 12 Days 11 Hours ago by: luser droog

Mapping to BNF is easy enough, true. I (and I suspect others) would have an easier time with it if it were left factored so it can be used directly by the simpler parsing algorithms. Left factoring by hand I've found to be tedious and er

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 12 Hours ago by: olcott

All these things can be added and we end up with a simple, faster, std:deque that has most the conventional overhead and complexity abolished. It just a matter of defining more member functions.

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 12 Hours ago by: Mr Flibble

What you have does not offer what std::deque offers so is not equivalent to std::deque so can't be considered better than std::deque for the general case (I don't care about your specific use-case). /Flibble

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 13 Hours ago by: olcott

I could allow all elements to be popped from the front or the back too. Mine is much faster when you need far less than all elements.

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 13 Hours ago by: Mr Flibble

Then it is totally different to what std::deque offers: std::deque allows ALL elements to be either popped from the front or back. Try reading AND UNDERSTANDING what I wrote again. /Flibble

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 13 Hours ago by: olcott

Mine words the same way and has the added benefit of contiguous storage. I don't think that this applies to the way that I implemented it. pop_front pops from the end of Left. pop_back pops from the end of Right. This is the key aspect

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 13 Hours ago by: Mr Flibble

I see you are choosing to ignore my reply in the other thread. OK, I will repost why you are wrong here: * referential integrity and iterator invalidation are different things: when you add or remove elements to either end of a

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 13 Hours ago by: olcott

It is faster then std::deque. I couldn't find what you mean by referential integrity it has too many different meanings. invalidating iterators seemed to be what you mean otherwise I have no idea.

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 14 Hours ago by: olcott

Good catch. I just wrote that function as a simplification.

Re: Implementing a two-way Turing Machine tape as an improvement to std::deque (thread)

comp.ai.philosophy

Posted: 12 Days 14 Hours ago by: Richard Damon

Looks at what indexing with an index value of 0 does. Operator [] want to test index >= 0, not > 0

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 14 Hours ago by: Mr Flibble

Because it doesn't meet the complexity and referential integrity requirements of std::deque. /Flibble

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 14 Hours ago by: olcott

I didn't see any reason why it would not make a better std::deque.

Re: Implementing a two-way Turing Machine tape as an improvement to (thread)

comp.ai.philosophy

Posted: 12 Days 14 Hours ago by: Mr Flibble

It might be a more appropriate solution than std::deque for your specific use-case however it is NOT an improvement to std::deque for the general case -- see my reply in the other thread for why. /Flibble

Implementing a two-way Turing Machine tape as an improvement to

comp.ai.philosophy

Posted: 12 Days 14 Hours ago by: olcott

C/C++ people please critique this as the basis for an improvement to std::deque. It seems to have the key functionality of std::deque and does it much more simply while saving time and space. https://www.cplusplus.com/reference/deque/dequ

Re: simplifying c syntax & thoughts from inside the compiler (thread)

comp.lang.c

Posted: 12 Days 18 Hours ago by: fir

i added void goo int z1 int z2 int z3 -> int z4 int z5 int z6 z4=z1+z2 z5=z2+z3 z6=z3+z1; void doo { a b c = goo 2 3 4, printf " a %d b %d c %d \x00" a b c } this is function retuirning many values (bit

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 13 Days 9 Hours ago by: Bonita Montero

I think most people generally understanding code would argue like that. Less code, not simpler. It's less complication.

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 13 Days 10 Hours ago by: james...@alumni.calt

On Wednesday, May 11, 2022 at 12:44:23 PM UTC-4, Bonita Montero wrote:

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 13 Days 20 Hours ago by: Bonita Montero

The optimizer generates the same code and mine is more readable.

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 13 Days 21 Hours ago by: james...@alumni.calt

Which is precisely what you get with either return l < r ? -1 : l > r ? 1 : 0;, as you originally wrote it, or with l > r ? 1 : 0 simplified to l > r, giving return l < r ? -1 : l > r; as was implicitly by Dolores' comment.

Re: ANSI C89/ISO C90 - Reference where mixing declarations and code is forbidden (thread)

comp.lang.c

Posted: 13 Days 22 Hours ago by: Tim Rentsch

[.. regarding C grammar rules ..] The C90 and C99 grammar rules are not written in BNF, but surely they deserve to be termed something similar. They can easily be mapped to BNF, for example, if one wants to do that. I don't know what

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 13 Days 22 Hours ago by: Bonita Montero

Right, but that's not what qsort needs. qsort doesn't need a less -predicate like std::sort but a ternary result which is either negative, zero or positive.

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 13 Days 23 Hours ago by: james...@alumni.calt

No one suggested that it was. The original code was return l < r ? -1 : l > r ? 1 : 0; Doloros was pointing out that the sub-expression l > r ? 1 : 0 was exactly equivalent to l > r, implying that the code should be changed to

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 14 Days 4 Hours ago by: Öö Tiib

The qsort does not require you to write redundant code in callback. The "l > r ? 1 : 0" you are discussing is subexpression that is exactly equivalent with "l > r" so the "? 1 : 0" part of it is superfluous.

Re: Proof that H(P,P)==0 is correct [ refuting the halting problem (thread)

comp.lang.c

Posted: 14 Days 5 Hours ago by: Mark Bluemel

Did someone say his name between 2 mirrors or something?

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 14 Days 8 Hours ago by: Bonita Montero

Of course, but isn't a sufficient result for the qsort-callback.

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 14 Days 8 Hours ago by: Bonita Montero

I'm not referring to the standard but what I implement.

Re: Validating that the implementation meets the spec for TM (thread)

comp.theory

Posted: 14 Days 11 Hours ago by: olcott

Not in the least little bit. Please wait until you see my full implementation before passing judgement. David's solution is optimal. My implementation of David's solution essentially redefines the whole notion of std::deque with std:v

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 14 Days 20 Hours ago by: Andrey Tarasevich

What point are you trying to make? The result of `(l > r ? 1 : 0)` is 1 or 0. The result of `(l > r)` is also 1 or 0. So? P.S. Notwithstanding that callback result does not have to be "-1, 0 or 1"

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 14 Days 21 Hours ago by: Scott Lurndal

Neither of the relevant standards agree with you. C99 (n1256.pdf) The comparison function pointed to by compar is called with two arguments that point to the key object and to an array element, in that order. The function shall return a

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 14 Days 21 Hours ago by: Bonita Montero

The result of the comparison-callback of qsort() is -1, 0 or 1.

Re: simplifying c syntax & thoughts from inside the compiler (thread)

comp.lang.c

Posted: 14 Days 22 Hours ago by: fir

so for example this syntax is compiled void ProcessKeyDown int last_key_pressed { .PAGE_UP=33 .keyR=0x52 .keyG=0x47 .keyB=0x42 last_key_pressed?=PAGE_UP{ToggleFullscreen} last_key_pressed?=0x41{foo frame_size_x frame_size_y

Re: simplifying c syntax & thoughts from inside the compiler (thread)

comp.lang.c

Posted: 14 Days 23 Hours ago by: fir

compare it to standard c void OnResize3(){if(a==2){doo;}} its quite longer - 7 characters its quite a lot where in my versiondoo may be both a variable or function call - if defined

Re: simplifying c syntax & thoughts from inside the compiler (thread)

comp.lang.c

Posted: 14 Days 23 Hours ago by: fir

ok i added it accepts all 3 syntaxes now void OnResize1:a?=2:doo;. void OnResize2:a?=2:doo;; void OnResize3{a?=2{doo}} void OnResize. void OnResize; void OnResize{} i think teh first ist most basic/fundamental but the third is liek to

Re: simplifying c syntax & thoughts from inside the compiler (thread)

comp.lang.c

Posted: 15 Days ago by: fir

i changed so now . is return and ; is loop and if end block this sole dot is lookin weird though its standable imo so this is for example legal void OnResize:a?=2:doo;. i could also use ; as for ending block some could maybe say this vo

Proof that H(P,P)==0 is correct [ refuting the halting problem proofs

comp.ai.philosophy

Posted: 15 Days 1 Hour ago by: olcott

(a) Verify that the execution trace of P by H is correct by comparing this execution trace to the ax86 source-code of P. (b) Verify that this execution trace shows that P is stuck in infinitely nested simulation (a non-halting behavior).

simplifying c syntax & thoughts from inside the compiler

comp.lang.c

Posted: 15 Days 1 Hour ago by: fir

in compiler i go simple thpugh im not saying this is final form of language i just want to s\go for simple (most or almost most 'naked' from various decorators_ syntax and see how can it go for example i now may compile such things voi

Re: ANSI C89/ISO C90 - Reference where mixing declarations and code (thread)

comp.lang.c

Posted: 15 Days 16 Hours ago by: Kaz Kylheku

The rule is that in a compound statement, there is a list of zero or more declarations, followed by zero or more statements. Look for the compound statement syntax.

Re: ANSI C89/ISO C90 - Reference where mixing declarations and code (thread)

comp.lang.c

Posted: 15 Days 16 Hours ago by: Guillaume

Yes. It's not *explicitely* stated in the C90 std other than from the grammar, which defines compound statements as a declaration list (optional) followed by a statement list (optional). Thus, as per the grammar, declarations can't com

Re: ANSI C89/ISO C90 - Reference where mixing declarations and code is forbidden (thread)

comp.lang.c

Posted: 15 Days 17 Hours ago by: Scott Lurndal

Looking at n1256 (C99 draft), the productions in 6.8.2 (Compound Statement) cover the mixing of code and declaration by allowing either in 'block-item'. C99 draft: Syntax compound-statement: { block-item-listo

ANSI C89/ISO C90 - Reference where mixing declarations and code is

comp.lang.c

Posted: 15 Days 18 Hours ago by: Poprocks

Hi folks, We all know that when one writes code like this: ``` int main(void) { int x; x = 42; int y = 5; return 0; } ``` ....under strict C89/90, one will get a warning or error with, eg, GCC (depending on the flags, o

Re: The missing sgn() function (thread)

comp.lang.c

Posted: 15 Days 18 Hours ago by: Keith Thompson

[...] C doesn't have operator overloading. The equality and relational operators return a result of type int with the value 0 or 1.

Re: The missing sgn() function (Was: qsort() vs. std::sort) (thread)

comp.lang.c

Posted: 15 Days 18 Hours ago by: Malcolm McLean

The relational operators don't have to be overloaded to return a boolean. It's normal to do so, but not required. I suppose a use case would be a fuzzy logic type system whereby you could have full or partial equality, and == returned a re

Re: The missing sgn() function (Was: qsort() vs. std::sort) (thread)

comp.lang.c

Posted: 15 Days 20 Hours ago by: Dolores Filandro

But what I was getting at, is that for OP representing any relational or equality operator, ==, !=, >, <, et cetera, and with any text substitutions for A and B the expression ((A) OP (B)) means *Exactly* the same thing as the expression

Re: The missing sgn() function (Was: qsort() vs. std::sort) (thread)

comp.lang.c

Posted: 16 Days 20 Hours ago by: Andrey Tarasevich

Of course, one can always argue that `(l > r) - (l < r)` is also a variation of `l - r` where the values are pre-normalized to ensure they "are so small that overflow can't happen". :O)

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 16 Days 20 Hours ago by: Stefan Ram

I did a search for it, and found only few definitions: |#define sign(z) ((z) < 0 ? -1 : ((z) > 0 ? 1 : 0)) nethack . Sometimes, first, a two-argument sign is defined, sign(a,b), as the value of a with the sign of b. The one-argu

Re: The missing sgn() function (Was: qsort() vs. std::sort) (thread)

comp.lang.c

Posted: 16 Days 20 Hours ago by: Andrey Tarasevich

No. `l - r` is a major anti-pattern and is often a bug. Firstly, this will not work at all for unsigned types as in the original example. Secondly, in general this will not work for signed types since it can/will overflow. The only ca

Re: furia (fir's proto-c compiler) (thread)

comp.lang.c

Posted: 16 Days 20 Hours ago by: fir

some newer version https://filebin.net/qg6zad6s27xb80vt i upgraded those 'vector' separation code and allowed both use ; or | separators or none like foo a b c foo a|b|c i throwed old reducer code to trash bin and wrote one notably

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 16 Days 21 Hours ago by: Stefan Ram

A programmer might implement a specification that says, -1 if l < r result = { 1 if l > r 0 , otherwise. . Then, - somewhat redundant - code such as return l < r? -1: 0; might make it easier

The missing sgn() function (Was: qsort() vs. std::sort) (thread)

comp.lang.c

Posted: 16 Days 22 Hours ago by: Kenny McCormack

Which is why I've always thought it was dumb that the standard library (both in C and in some "C-like" languages) doesn't provide the sgn() function. It means that everybody has to re-invent the above idiom. Incidentally, is any of this

Re: Memorizing C operator precedence (thread)

comp.lang.c

Posted: 17 Days 3 Hours ago by: fir

i dont remember them still.. thought probabbly it would be really nice to learn them for example i was surprised recently by bug in my code i wrote if(!atoms.first[right_bracket ].beg[0]==']') i thought ! negates this == , it showed i

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 17 Days 4 Hours ago by: Andrey Tarasevich

.... which is why one usually expresses the above as the idiomatic return (l > r) - (l < r);

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 17 Days 8 Hours ago by: Dolores Filandro

Re: harder problem i encountered (thread)

comp.lang.c

Posted: 18 Days 5 Hours ago by: fir

in fact this topic is a mess, i stopped coding for 2 days becouse of this cognitive drop down but i feel like im bori9ng so maybe yet will try to mend it a bit i wonder if i turn this into again: ReduceMulsAndDivs1Pass(); //l

Re: i take propositions for a set of x = b d operators (thread)

comp.lang.c

Posted: 18 Days 16 Hours ago by: fir

btw i looked on this compiler group slightly and it seems they do that other way than I, use someones other theory than me, (i use my own theory if coulpe of thoughys may be named that ).. i dont looked there to much but as the frst glanc

Re: harder problem i encountered (thread)

comp.lang.c

Posted: 19 Days 16 Hours ago by: fir

the assign operator i added and it seem to work, the a[b]=c reduction i wrote but not even tested getting to weary... good scheme for work for me seem to be intense 2-3 weeks and then a longer break (asm i wrote in one such session in 201

Re: harder problem i encountered (thread)

comp.lang.c

Posted: 19 Days 22 Hours ago by: fir

maybe lets think whay would happan if i would treat = as an normal operator to be reduced, maybe thats the way (obviously this pack of loops abowe as i said reduces things in wrong, almost random, order but as i said i dont wory for now f

harder problem i encountered

comp.lang.c

Posted: 20 Days 3 Hours ago by: fir

back then i wrote code which i found initially silly (it was taken becouse i found some text on it (i mean compilng expressions with operators and parenthesis ) herdly readable and i wanted something quick now when i run it i found it quit

Re: thoughts on digger /pieces digger (thread)

comp.lang.c

Posted: 20 Days 17 Hours ago by: fir

if someone want to test last version https://filebin.net/6267ej32fxfhab0d meybe its not so fun untill i will code some more new features like native support for chunks and micromodules, but there still some way to go and im not sure if

Re: thoughts on digger /pieces digger (thread)

comp.lang.c

Posted: 20 Days 17 Hours ago by: fir

i may add that being inside the machine feels other than i thought eventually thinking back then how code of compiler looks inside...possibly i thinked the code is more homogeneus and right now it dont feel that way as i said got splitter

Re: i take propositions for a set of x = b d operators (thread)

comp.lang.c

Posted: 20 Days 19 Hours ago by: fir

well this overally work, the implementation of this library needs specific thinking so i may do it later , but some i checked work - so i may go to something other overally it is quite nice to code own compiler gives you nice freedom you

Re: i take propositions for a set of x = b d operators (thread)

comp.lang.c

Posted: 20 Days 21 Hours ago by: fir

i think i could write <min> <max> <mid> <dist> but the problem is i need to emit assembly for that doeas maybe someone know what assembly would be effective for <min> or <dist> ? x <dist> y would make abs(x-y) its not shorter but maybe i

Re: i take propositions for a set of x = b d operators (thread)

comp.lang.c

Posted: 20 Days 22 Hours ago by: fir

it also resembles me this great song of Busta Niggaz quick to talk shit.. OOPS! Upside your head Put your head to bed -- let me do my thing -- nuff said Shit so hot make your chickenhead do the spread Tell me what you said -- I said I n

Re: i take propositions for a set of x = b d operators (thread)

comp.lang.c

Posted: 20 Days 23 Hours ago by: fir

added some shifts that maps on x86 shifts commands c1 = 0x011111<shl>1 c2 = 0x011111<shr>2 c3 = 0x011111<sal>3 c4 = 0x011111<sar>1 c5 = 0x011111<rcl>3 c6 = 0x011111<rcr>1 c7 = 0x011111<rol>1 c8 = 0x

Re: i take propositions for a set of x = b d operators (thread)

comp.lang.c

Posted: 21 Days 1 Hour ago by: fir

overally ading this operatos is fairly easy for example emiting xor void Emit_xor(chunk right_operand) { if( unsigned(right_operand.beg) < max_temp_registers) FlushOutAsm("\n xor eax (__t%d) ", unsigned(right_operand.beg) );

Re: i take propositions for a set of x = b d operators (thread)

comp.lang.c

Posted: 21 Days 5 Hours ago by: fir

if you mean strictly |&%^ i agree (as i said) i would also prefer x = xor(6,b); y= and(x, 0xf0) and so on this unlocks precious punctuation marks, if to unlock them seems like all on teh uperline of keyboard on left side are free (exce

Re: i take propositions for a set of x = b d operators (thread)

comp.lang.c

Posted: 21 Days 5 Hours ago by: fir

hovever this last may be somewhat resolved becouse operator is strict <neg> or (neg) without spaces.. if i put one (neg) i may see this as a avariable name in parenthesis hovever this still may be confusing if someone would like use a

Re: i take propositions for a set of x = b d operators (thread)

comp.lang.c

Posted: 21 Days 5 Hours ago by: fir

what do you mean based on a function call? if i use word inside <> it is sorta like function call but not quite, becouse it is differently resolved (like has its ovn priority level) x = a <min> b <min> c i typed most of code for it yest

Re: i take propositions for a set of x = b d operators (thread)

comp.lang.c

Posted: 21 Days 9 Hours ago by: Siri Cruise

In article <ad3f8cb3-e76c-452a-8242-af0467402e30n@googlegroups.com>, fir <profesor.fir@gmail.com> wrote: I prefer basing it on a function call. We have implementations with multiply-add operators that look like C functions and transl

Re: i take propositions for a set of x = b d operators (thread)

comp.lang.c

Posted: 21 Days 18 Hours ago by: fir

i dont write code in pascal etc, i write c0like compiler code in c, and share soem thought on this.. some may moan and roar but i would like sse some better c content from them and i see none...

Re: i take propositions for a set of x = b d operators (thread)

comp.lang.c

Posted: 21 Days 18 Hours ago by: Kenny McCormack

For the same reason(s) that people often discuss (and post code in) various other languages here, such as Python, C++, Perl, C#, and others. Because they can't help themselves.

Re: i take propositions for a set of x = b d operators (thread)

comp.lang.c

Posted: 21 Days 21 Hours ago by: fir

i meant the problem is that the other topics it to less and this afects ratio also note what i write is sorta specialistic (though not fully) but it may be find in archive and someone may use it later (right now i will not make furia op

Re: i take propositions for a set of x = b d operators (thread)

comp.lang.c

Posted: 21 Days 22 Hours ago by: fir

it depends...for me for example those over and over standard mangling is boring as hell.. i find it as a kinda content for standard talkers not c programmers and imo it could be group for people who real program in c and here my topics

Re: i take propositions for a set of x = b d operators (thread)

comp.lang.c

Posted: 21 Days 22 Hours ago by: Jack Lemmon

Stupid or not but you should really be posting on " comp.compilers " where this belongs. Here, on this newsgroup, people wants to see standard C code which you are not using.

Re: i take propositions for a set of x = b d operators (thread)

comp.lang.c

Posted: 21 Days 22 Hours ago by: fir

besides dont worry lat years i read/write here once a half a year or once a year and maybe less and i will wanish soon again i thought i get weary sooner but soon i will get weary and to this taime i need yet to upcode something, maybe su

Re: i take propositions for a set of x = b d operators (thread)

comp.lang.c

Posted: 21 Days 22 Hours ago by: fir

this is btw stupid thinking for people see ma i compile for example foo x y z 10 instead foo(x,y,z,10); as a big difference ..and teh second is talking on c and first its not ...this is on c but in a dose genaralised form...same with this

Re: i take propositions for a set of x = b d operators (thread)

comp.lang.c

Posted: 21 Days 22 Hours ago by: fir

im implementing c extensions - some of it is general, some it is specific and possibly not c, but there is some part deeply rooted with c and says on c) besides i dont said i not implement c- i rather implement not only c but also c... fo

Re: i take propositions for a set of x = b d operators (thread)

comp.lang.c

Posted: 21 Days 22 Hours ago by: Jack Lemmon

Because he's a troll. From time to time we get all sorts here and you just have to get used to them. Today I am seeing an Indian posting websites that he found where he can find women for sex. He's not posting any C codes here.

Re: i take propositions for a set of x = b d operators (thread)

comp.lang.c

Posted: 21 Days 22 Hours ago by: Mark Bluemel

If you're not implementing C (and you are clearly not, as you are not following the language specification), why are you posting here?

i take propositions for a set of x = b d operators

comp.lang.c

Posted: 21 Days 22 Hours ago by: fir

as i maybe said i think i will not use those chars |&%^ (and maybe soem alike ) as an operators for logical or and rest and xor becouse i think in practice they are not so commonly used to allow them to block this characters for other bett

Re: Free Chat Now - Free Adult Sex Chat Room Near Me (thread)

comp.lang.c

Posted: 22 Days 4 Hours ago by: soc women

Yes definitely. Fuck me up and I'll fuck you up good

Re: Online Dating Where Single Women, Men Looking Each Other for Date (thread)

comp.lang.c

Posted: 22 Days 4 Hours ago by: soc women

Hey sexy I'm horny and wanna fuck.

Re: Sluts Near Me for Local Fuck | Horny Local Sluts (thread)

comp.lang.c

Posted: 22 Days 4 Hours ago by: soc women

seeking casual partner for women and girls having sex

Re: thoughts on digger /pieces digger (thread)

comp.lang.c

Posted: 22 Days 4 Hours ago by: fir

at the moment i decided to go this way: after atomizer i run kinda switch on loglines and detect and microcompile 1 loop header 2 if header 3 4 loop/if end 5 fuunction def 6 function call the rest i assume is a vector of expressions whic

Re: C := A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-B;

comp.lang.c

Posted: 22 Days 7 Hours ago by: Jan van den Broek

[Schnipp] Sorry, couldn't resist: Ac-Cent-Tchu-Ate The Positive - Bing Crosby & The Andrews Sisters https://www.youtube.com/watch?v=5Qk9o_ZeR7s

Re: C := A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-B;

comp.lang.c

Posted: 22 Days 11 Hours ago by: Öö Tiib

Also it converts anything shorter than int into signed int.

Re: C := A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-B;

comp.lang.c

Posted: 22 Days 11 Hours ago by: Richard Damon

No +-x is just +(-(x)) i.e., start with x, unary negate it, the unary plus it. unary plus isn't normally a very useful operation, but is defined, I suppose so you can write numbers like +5 to accentuate that they are positive.

Re: thoughts on digger /pieces digger (thread)

comp.lang.c

Posted: 23 Days 1 Hour ago by: fir

overeally it shows i got not it wel concepotualized still group of atoms (like a+b/d) i could name particles, and this expression digger could be then also names particles digger , particles grouper, particles collector and so on i thin

Re: C := A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-B;

comp.lang.c

Posted: 23 Days 7 Hours ago by: Freethinker

In Math negative doesn't win over positive. In Math +- is undefined behaviour (and most silly idea to start with).

Re: C := A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-B;

comp.lang.c

Posted: 23 Days 12 Hours ago by: Sams Lara

It is correct because the statement is: A + (-B) = 50 -25 = 25 I haven't checked your entire code because you have fundamental misunderstanding how basic mathematics work. If you balance out your pluses and minuses you will find that m

Re: thoughts on digger /pieces digger (thread)

comp.lang.c

Posted: 23 Days 18 Hours ago by: fir

in fact maybe its better to go rigorous on a function call and assume each one is in separate log line, same ad fun-deff..its quite different than those freestanding values which are just vectors..maybe i will limit that diggers dig only

Re: thoughts on digger /pieces digger (thread)

comp.lang.c

Posted: 23 Days 18 Hours ago by: fir

digger role is generally to provide pices that are able to be microcompiled end everything is plain except this function call becouse normally freestandiung pieces are sequential and plain but when met something lik int x int y = foo a*b

Re: thoughts on digger /pieces digger (thread)

comp.lang.c

Posted: 23 Days 19 Hours ago by: fir

i think reasonable assumption would be that in fnction definition i do not add nothing more there as it not mixes well in rest of the lines i may assume that int definition is something to begins with "int" as i di pre pass scan i know w

Re: thoughts on digger /pieces digger (thread)

comp.lang.c

Posted: 23 Days 20 Hours ago by: fir

i need for example to dig such lines int a int b int c int d /// define variables int a int b int c foo int e int f ///define function (taking 2 returns 3 ints) a b c d e f //call variables a*b+5 d-3*h doo*(a-b) ///expressions a b c = f

Re: thoughts on digger /pieces digger (thread)

comp.lang.c

Posted: 23 Days 20 Hours ago by: fir

what complicates things i want to dig lines with as many commas ommited as its possible right now i use commas just to split on logical lines thus spliter almost works like digger... almost but not fully becouse i dont wanted to split arg

Re: thoughts on digger /pieces digger (thread)

comp.lang.c

Posted: 23 Days 23 Hours ago by: fir

one thing i can say is that using this while pattern, i mean for example iterating on on atoms which are function all arguments finding first argument/expression sonsuming it (it is compiling and flushing asm) going to another untic end

thoughts on digger /pieces digger

comp.lang.c

Posted: 23 Days 23 Hours ago by: fir

i reserve this thread to share some thoughts on pieces digger (normally i called it expresion digger but im not sure if some things like 1 or loop header may be named expressions, so in title i name it maybe a pieces digger, though probabl

Re: about line atomizer (thread)

comp.lang.c

Posted: 24 Days ago by: fir

the fourth thing/stage after the splitter atomizer digger i could probably name as microcompiler - it just compiles what was dug

Re: about line atomizer (thread)

comp.lang.c

Posted: 24 Days ago by: fir

feeling my head partially went back old ways on thinking on c again (partially) could say that after splitter and atomizer i need this one thing mentioned here which i would name expression digger (so you got 3 splittr atommizzr diggr) th

Re: thought on switch (thread)

comp.lang.c

Posted: 24 Days 1 Hour ago by: fir

possibly the form as for now could compile elements mentioned (chars k) myswitch(chars k) { "aaa" : "ssccc"; "aacc" : "akjhs jshkjh" "11" : " sddd" if(len(k)<10) : " aaaaa" "ruu" : { runsomething(); return " "; } } printf(my

thought on switch

comp.lang.c

Posted: 24 Days 1 Hour ago by: fir

watching a bit of code i used to compile when developing fury void ProcessKeyDown int last_key_pressed : int PAGE_UP{33}, int keyR{0x52}, int keyG{0x47}, int keyB{0x42} last_key_pressed?=PAGE_UP: ToggleFullscreen . last_key_

Re: furia (fir's proto-c compiler) (thread)

comp.lang.c

Posted: 24 Days 4 Hours ago by: fir

i added yet new version https://filebin.net/hhwx77gjc4zmeyax this compiles a bit cleanised syntax ////////////////////////////// import "green_fire.dll" (cdecl) DrawSomeText2 ToggleFullscreen ClearFrameData DrawCircle

Re: top_level_regex_token_iterator - Don't match between nested brackets (thread)

comp.lang.c

Posted: 24 Days 17 Hours ago by: Stefan Ram

Newsgroups: comp.lang.c++,comp.lang.c Followup-To: comp.lang.c Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> writes: #include <stdio.h> void sink( char const * const start, char const * const top ) { for( char const * p = star

Re: furia (fir's proto-c compiler) (thread)

comp.lang.c

Posted: 24 Days 17 Hours ago by: fir

the compiler is now, i checked 100k bytes source )including commented and not needed parts_ which gave 5k lines (which in turn stands for 2 weeks of crazy work, as for me month of crazy work is 10k lines - this was whan i was younger and

Re: Memorizing C operator precedence (thread)

comp.lang.c

Posted: 24 Days 23 Hours ago by: Tim Rentsch

[...] I should note here that I have read through your previous comments but don't have any response to them at this time. My statement is a statement of opinion, not a statement of fact, and so it is neither true nor false -- it is j

Re: furia (fir's proto-c compiler) (thread)

comp.lang.c

Posted: 25 Days 4 Hours ago by: fir

somewhat upgraded version https://filebin.net/pethf87gfgorfuz7 takes code like ////////////////////////////// import "green_fire.dll" (cdecl) DrawSomeText2 ToggleFullscreen ... ClearFrameData DrawCircle RegisterRunFrame RegisterMous

Re: operator precedence (thread)

comp.lang.c

Posted: 25 Days 22 Hours ago by: David Brown

Such languages exist to remind us not to generalise too much! Certainly whitespace is significant in some languages, just not in C (except for newlines in preprocessing). It is relevant in Python, to pick a common modern example. Bu

Re: operator precedence (thread)

comp.lang.c

Posted: 25 Days 22 Hours ago by: James Kuyper

On 4/29/22 04:04, David Brown wrote:

Re: what about this pattern? (thread)

comp.lang.c

Posted: 25 Days 23 Hours ago by: fir

hovever i might omit dots here in micromodular/C2 way Expression_list expression_list expression_list add(1,222); expression_list add'(2,211); expression_list add( 3,22); expression_list add'( 4,133); expression_list dump();

Re: operator precedence (thread)

comp.lang.c

Posted: 26 Days ago by: David Brown

Sure I can. I don't advise using spacing to influence the way some people might interpret the code. But I /do/ advise using spacing to make it faster and easier to read. It is, arguably - some might prefer that spacing, others migh

Re: what about this pattern? (thread)

comp.lang.c

Posted: 26 Days 2 Hours ago by: fir

btw why bartc is so inactive here? i once was writing he do weird thing fighting the same battles 200+ times instead of say 5 or 10 (becouse inded not much sense in this, hovever 'side effects' of that repeating could (and did) give som

Re: what about this pattern? (thread)

comp.lang.c

Posted: 26 Days 2 Hours ago by: fir

and what with using long long int command; and limit self to 8-character long comands at most? do this have serious disadvantages? note im using gcc/mingw in 32 bit mode (i even work on 32 bit old comp becouse writing assembler i decided

Re: operator precedence (thread)

comp.lang.c

Posted: 26 Days 3 Hours ago by: Malcolm McLean

You can't have it both ways. Either you advise using spacing to help indicate intent, or you don't. In fact I would advise doing so. image[y*width + x] = col; is arguably a bit easier to read because it is more obvious that the width ass

Re: what about this pattern? (thread)

comp.lang.c

Posted: 26 Days 4 Hours ago by: fir

this is recognized on level below atomizer and its not so hard, often the small if three suffice if(atoms_len >= 6) // double a = 23.45 if( CCS(a0, "double") || CCS(a0, "%") ) if( CCL(a1) ) if( CCS(a2, "=") )

Re: what about this pattern? (thread)

comp.lang.c

Posted: 26 Days 5 Hours ago by: fir

its also reminder how this cross acces to static is needed.. i will write my own extended c compiler giving that and the rest , but just having it in C would make this language notably stronger the second thing of this measure (this le

Re: operator precedence (thread)

comp.lang.c

Posted: 26 Days 5 Hours ago by: David Brown

Yes. Spacing influences how people read things - it is significant to people. It does not affect how the compiler sees things (once you have the bare minimum for the syntax, of course). So IMHO using spacing as an extra clue to int

Re: what about this pattern? (thread)

comp.lang.c

Posted: 26 Days 5 Hours ago by: fir

one could ask why not use (c way) expression_list_add(1,222); expression_list_add'(2,211); expression_list_add( 3,22); expression_list_add'( 4,133); expression_list_dump(); expression_list_print_sum(); which is faster (at l

Re: operator precedence (thread)

comp.lang.c

Posted: 26 Days 5 Hours ago by: David Brown

Agreed on all points.

Re: what about this pattern? (thread)

comp.lang.c

Posted: 26 Days 6 Hours ago by: fir

im not sure what you re talking aboput .. in c there are rules thay says what such thing as x++++y are and if i need to check if space is before something i may write IsWhitespace(atom[i].beg[-1]) becouse pointers in chonks point into

Re: what about this pattern? (thread)

comp.lang.c

Posted: 26 Days 12 Hours ago by: Ben

Sometimes it helps to think about things before you code too much. Once you have only the three 'atoms' +, + and x it's too late to be able to tell what the expression should be.

Re: what about this pattern? (thread)

comp.lang.c

Posted: 26 Days 12 Hours ago by: fir

you may propose some rule or code if you want... i stopped thinking on this when coding this as i began to study this mentioned pattern more than the extracting expressions task

Re: what about this pattern? (thread)

comp.lang.c

Posted: 26 Days 12 Hours ago by: fir

i dont know how to name this pattern, temporarely maybe i will name it functoid (functolist?) pattern i made some test of efficiency out of curiiosity inline void int_list(unsigned long long command, int i) { // printf("\n size of %d

Re: what about this pattern? (thread)

comp.lang.c

Posted: 26 Days 13 Hours ago by: fir

i not thinked on this yet..this code is not finished (as it seen it works bad as it broke on args of nested function )... i need to invent some rule but the pattern i said simplify coding this a lot

Re: what about this pattern? (thread)

comp.lang.c

Posted: 26 Days 13 Hours ago by: Ben

How will you distinguish between "++x" and "+ +x"?

Re: what about this pattern? (thread)

comp.lang.c

Posted: 26 Days 14 Hours ago by: fir

i know, there was discusiion on this here back then, i think on 64 bit there can be used 64 bit unsigned and thats nice 8 characters .. here i dont much care as tis was side for ilustrating whole pattern and this 'command' format is a side

Re: what about this pattern? (thread)

comp.lang.c

Posted: 26 Days 14 Hours ago by: Andrey Tarasevich

Multicharacter character constants produce implementation-defined values. On a 32-bit-int platform a 2-4 character multicharacter character constant is indeed viable for some uses, as long as you know what you are doing and assuming th

Re: what about this pattern? (thread)

comp.lang.c

Posted: 26 Days 14 Hours ago by: fir

there is a bug above should be ++size not size++ besides the name expresion_list is here becouse i added this experimenting with code that will give me the boundaries of expresions like 2+ 3 b/b++ siz.a.b.c* (2 + 3) when they are not sep

what about this pattern?

comp.lang.c

Posted: 26 Days 15 Hours ago by: fir

void expression_list(unsigned command, int i, int j) { struct list { int x; int y; }; static list* ram = NULL; static int size = 0; if(command=='add') { ram = (list*) realloc(ram, size++ * sizeof(list) ); ram[size-1] = {i,j

Re: operator precedence (thread)

comp.lang.c

Posted: 26 Days 16 Hours ago by: Kaz Kylheku

Human error; some people will make the mistake some of the time due to following visual clues over formal syntax, mistaking closer spacing for tighter binding. It't the same as: char* p, q; // oops, q is of type char, not char *.

Re: operator precedence (thread)

comp.lang.c

Posted: 26 Days 17 Hours ago by: Richard Harnden

I read them like ... (1/2)π 1/(2π) same as a) same as b) On the blackboard, a) and c) would be more like: π

Re: operator precedence (thread)

comp.lang.c

Posted: 26 Days 18 Hours ago by: Ben

The layout, yes. That's not the point that got my attention. I didn't think you meant in general. I am sure something like that would not have escaped my attention. Were you talking about "typed" mathematics? Because ASCII symbols

Re: operator precedence (thread)

comp.lang.c

Posted: 26 Days 23 Hours ago by: Dan Purgert

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Stefan Ram wrote: Seems "spelling" is also not a strong suit of mine today :) -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmJqpwEACgkQbWVw5Uzn KGCHBg/9EK0ep

Re: operator precedence (thread)

comp.lang.c

Posted: 26 Days 23 Hours ago by: Stefan Ram

Yes. To clarify the precedence, there are parentheses; whitespace is not intended for this. "Parenthesis" is the singular; for the plural, you can use "parentheses" or "parens". parenthesis  pə ˈɹɛnθ əs ɩs p

Re: operator precedence (thread)

comp.lang.c

Posted: 26 Days 23 Hours ago by: Dan Purgert

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 David Brown wrote: Those mathematicians must not have been paying attention in class :). As written, given my (fuzzy) recollection of gradeschool mathematics, whitespace doesn't matter

Re: operator precedence (thread)

comp.lang.c

Posted: 27 Days 1 Hour ago by: David Brown

I get the feeling that we've been talking past each other a bit in this thread - something has been lost along the way (and I don't think my examples have helped in the slightest). The original example was "8 / 2 * (2 + 2)". The stand

Re: operator precedence (thread)

comp.lang.c

Posted: 27 Days 1 Hour ago by: Stefan Ram

You would be right! Usually, one would typeset this as "10 x 2 + 3" using a distance of 4/18 em instead of the spaces. Binary operators are sorrounded by 4/18 em, except the slash for division, which is not sorrounded by any sp

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 27 Days 2 Hours ago by: Thiago Adams

What I mean by " removing the function comparison pointer and using the function directly." is to create a copy of the code replacing the function pointer. Like instantiating the template function manually. The idea C++ is faster than C

Re: operator precedence (thread)

comp.lang.c

Posted: 27 Days 2 Hours ago by: Ben

I get that. I never thought there were rules. But somehow you learned something that I didn't. I would never say "You don't need parenthesis because in written mathematics, size of spacing /is/ significant" so I wondered how you came

Re: operator precedence (thread)

comp.lang.c

Posted: 27 Days 2 Hours ago by: Malcolm McLean

Yes you would. You'd wonder what was going on. Especially since, except in classroom exercises, mathematical expressions have a context. If the room is ten metres long and has a wooden strip two metres wide and a carpet three metres wide,

Re: operator precedence (thread)

comp.lang.c

Posted: 27 Days 2 Hours ago by: David Brown

That is the rule, yes. But if someone else wrote it with such spacing, would you not think that perhaps they meant it to be interpreted as though they had written "(10 × 2) + 3" ? When faced with something that has a conflict betwee

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 27 Days 2 Hours ago by: Malcolm McLean

That an interesting one. The comparison function can have side-effects, so it could do something with its own address, like printing it out. Does that address have to match the address of the fucntion when taken globally? I think it does.

Re: operator precedence (thread)

comp.lang.c

Posted: 27 Days 3 Hours ago by: Giovanni

Humans _can_ but not all humans do. I would interpret 10 × 2+3 as (10 x 2)+3 This was the basic rule I learned at the times of primary school. Ciao Giovanni

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 27 Days 3 Hours ago by: William Ahern

See disassembly posted elsethread. I've given all the information needed to quickly reproduce this for yourself, assuming some minimal familiarity with GCC. Alpine Linux isn't even needed, it's just what I started with out of caution. I

Re: operator precedence (thread)

comp.lang.c

Posted: 27 Days 3 Hours ago by: David Brown

I think you are reading too much into this. To my knowledge, there is no ISO Mathematics Standard document we can refer to. Written mathematics is written by people, and read by people, as a method of communication between humans. T

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 27 Days 3 Hours ago by: William Ahern

I posted two sets of benchmarks, one for qsort-inline and another for qsort-extern. qsort-inline clearly has a substantially different performance profile, and that could only happen if the comparison callback itself was inlined into the

Re: operator precedence (thread)

comp.lang.c

Posted: 27 Days 3 Hours ago by: Ben

Where does this come from? It's news to me. Where did you find out about it?

Re: operator precedence (thread)

comp.lang.c

Posted: 27 Days 5 Hours ago by: David Brown

I mean the way you space things in how you write mathematics gives additional information, in a way that cannot be done in a programming language. If you see mathematics written : 10 × 2+3 you'll interpret it differently from :

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 27 Days 7 Hours ago by: Juha Nieminen

The performance boost doesn't come from inlining. One single function call wouldn't make a difference when it comes to sorting. It doesn't matter if the std::sort() function gets inlined into the calling code or whether the compiler decid

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 27 Days 8 Hours ago by: Bonita Montero

The qsort-function is a static piece of code and the comparison -function is never inlined.

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 27 Days 8 Hours ago by: Bonita Montero

No, the numbers aren't useless, they compare the C- and the C++-way to sort things. LOL, there's no C compiler which will do that. The qsort-function is just a static piece of code and nothing is inlined.

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 27 Days 13 Hours ago by: William Ahern

The same is true in C++. That's a toolchain issue. Nothing prevents C environments from inlining qsort and it's callback; most simply haven't done so historically. Other language environments like Rust implicitly rely on static compilat

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 27 Days 13 Hours ago by: William Ahern

Unsurprising that inlining can improve performance. Your raw numbers are useless, though, as you're comparing different algorithms (C++ header template vs libc), which shall be demonstrated below. Also, technically speaking your gripe is

Re: about line atomizer (thread)

comp.lang.c

Posted: 27 Days 14 Hours ago by: fir

this example is btw a bit fictional as i got such code for scaning this variables (and this is a piece of cace to be written in half an hour or something like that) but in reality this FindVariableDefinition not returns the info but calls

Re: about line atomizer (thread)

comp.lang.c

Posted: 27 Days 15 Hours ago by: fir

specifically im not convinced they write compilers in such nice form like main() { chunk d = LoadChunk(input_file_name); chunks lines = SplitOnLogLines4Furia(d); int n = ChunksLength(lines);

Re: about line atomizer (thread)

comp.lang.c

Posted: 27 Days 16 Hours ago by: fir

sorta but not fully... they not use as far as i know the chunks resizable arrays also some decisions how to see things i think may be different.. and note my goal is not to write compiler but to rethink some inner things in a way i see it

Re: about line atomizer (thread)

comp.lang.c

Posted: 27 Days 16 Hours ago by: Ben

No. In C, -11.22 is not a number, it's an operator followed by a number (a floating point constant). The generally accepted technique is to split the input into lexical tokens and then apply a parser to that token stream. All of thes

Re: about line atomizer (thread)

comp.lang.c

Posted: 27 Days 18 Hours ago by: fir

finally i dont know...i wrote two wersions, one not glues 11.22 type atoms and other that does (with this previously mentioned rule if it srarts with digit it not takes dot as an end of an atom) i would need to check what is more pract

Re: operator precedence (thread)

comp.lang.c

Posted: 27 Days 18 Hours ago by: Ben

Is it? Where can I find out about this?

Re: about line atomizer (thread)

comp.lang.c

Posted: 27 Days 19 Hours ago by: fir

it (i mean those dotted and negative numbers) makes so damn problem thet i got serious doubt if i should do that on this atomic layer for exampla take -11.22 this seems to be number but it depends also what as before and after like 1

Re: about line atomizer (thread)

comp.lang.c

Posted: 27 Days 19 Hours ago by: fir

i will maybe do that way -> aa"xx" are two atoms aa and "xx" 11.22ssz.3.s.s.s$zzz.z.z.33.@zz i will treat as a number (it is idientifier is letters digits and _$@ number is the same but begins with digit and also may have dots. i forgot i

Re: about line atomizer (thread)

comp.lang.c

Posted: 27 Days 20 Hours ago by: fir

sorry if that was probably extremly hard to read what i think is i need to balance clarity of rules and and usability of the outcome and those dotted numbers make problem here.. they are needed to be atoimised for usability but their form

Re: about line atomizer (thread)

comp.lang.c

Posted: 27 Days 20 Hours ago by: fir

i thinked of it (becouse i also see that most of the punctuation marks work alone but some ot them work like two ++ -- // += etc) but this eventually is not so good idea (im stil not sure) this is becouse if i check in later code things

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 27 Days 21 Hours ago by: Bonita Montero

1. You can't inline a function with arbitrary recursion. 2. The comparison-function for qsort() is never inlined.

Re: about line atomizer (thread)

comp.lang.c

Posted: 27 Days 21 Hours ago by: Ben

That depends on your objectives, but even for a simple subset of C you should probably recognise sequences like ++, --, += (etc), ..., ->, << and so on being single tokens. As for numbers, "1ull" is a number in C as are "0x.1P-1" and "1

Re: about line atomizer (thread)

comp.lang.c

Posted: 27 Days 21 Hours ago by: fir

im rather inventyng new wheel then reinventing old i guess - and thats a bit of difference i dont know what this yaxx is, always seem too boring to learn but if someone want to talk something i may read this splitter+atomizer (based on

Re: about line atomizer (thread)

comp.lang.c

Posted: 27 Days 21 Hours ago by: Scott Lurndal

Rather than re-inventing the wheel, why don't you just use lex(1) to generate your tokenizer? DIGIT [0-9] ID [a-zA-Z_][a-zA-Z0-9_]* %% {DIGIT}+ { push_uint64(yyextra, strtoul(yytext, NULL, 10)); } 0[xX][0-9a-fA-F]+ {

Re: about line atomizer (thread)

comp.lang.c

Posted: 27 Days 21 Hours ago by: fir

there is for example confusion for me what treat as a number chunk, right now i just treat all alphanumeric particles as atoms, (like zzzz 1111 1zzz z111) probebly i could treat those starting with digit 0-9 as number (including 1zzzzz) and

about line atomizer

comp.lang.c

Posted: 27 Days 23 Hours ago by: fir

i was writing about code splitter (which breaks input text file on logical lines) - this splitter i find very important thus i was writing about it many times.... second important thing ius line atomizer wchich in turn breaks logical li

Re: qsort() vs. std::sort (thread)

comp.lang.c

Posted: 28 Days 2 Hours ago by: Thiago Adams

If a C programmer has concerns about qsort performance he just make it inline removing the function comparison pointer and using the function directly.

Re: operator precedence (thread)

comp.lang.c

Posted: 28 Days 5 Hours ago by: David Brown

C++ programmers are used to seeing statements like : cout << stuff << more stuff << even more stuff; Ben's thought here is that they are used to this pattern, and will automatically think of the "basic arithmetic" parts (which does

Re: operator precedence (thread)

comp.lang.c

Posted: 28 Days 6 Hours ago by: David Brown

If it were written as mathematics, exactly like that, it /would/ be ambiguous. Writing mathematics you have a lot more freedom to make the meaning clear (especially when using pencil and paper), and you are writing for human readers r

Re: operator precedence (thread)

comp.lang.c

Posted: 28 Days 6 Hours ago by: Öö Tiib

I have used simple rule that whatever static style analysis / code formatting tool settings are accepted by team have to be followed. Best is to integrate auto-formatting tool (like Clang-Format) into build system and done. If formattin

Re: checking back chars when scaning - best way ? (thread)

comp.lang.c

Posted: 28 Days 6 Hours ago by: fir

ifs are costly, so from optimisation/eficiency point of view probably, but from 'nativity' point of view its probably worse imo as it complicates a loop, ..as i pointet in such scann pass you may need to check for nomber of various ;subw

Re: operator precedence (thread)

comp.lang.c

Posted: 28 Days 12 Hours ago by: Sams Lara

Is this basic arithmetic: int result = 8 / 2 * (2 + 2); You'll be amazed to find that even top notch mathematicians will tell you that the result of this statement is ambiguous. Order of evaluation is very important here.

Re: operator precedence (thread)

comp.lang.c

Posted: 28 Days 14 Hours ago by: Ben

Yes, that's was my point.

Re: checking back chars when scaning - best way ? (thread)

comp.lang.c

Posted: 28 Days 15 Hours ago by: Andrey Tarasevich

Quite the opposite! This is actually a very elegant and useful pattern, which I'd personally call "strive to prologue/epilogue the special case" or something more catchy. Pretty often when people write cyclic code they run into situati

Re: operator precedence (thread)

comp.lang.c

Posted: 28 Days 16 Hours ago by: bart c

<< isn't basic arithmetic. The relative precedences of * and + are fairly universal so this is going too far. But I'd have to go and look up those for & and <<. Parentheses would be a good idea especially for fragments of code that mi

Re: checking back chars when scaning - best way ? (thread)

comp.lang.c

Posted: 28 Days 16 Hours ago by: fir

it seems most people do this way but in respect to what i was sayin this seem to me to be kinda bad pattern

Re: checking back chars when scaning - best way ? (thread)

comp.lang.c

Posted: 28 Days 17 Hours ago by: Andrey Tarasevich

Um... Start searching from `text + 2`, obviously. And generally from `pattern_length - 1` position. The pattern cannot possibly occur before that position, no point in searching there.

Re: checking back chars when scaning - best way ? (thread)

comp.lang.c

Posted: 28 Days 18 Hours ago by: fir

btw bartc was once asking on speed of compiler processing sources i checked now how many sole such splitter takes (though i not do much care for cerefull testing and observations) 100 iterations of splitting 1MB of some .c code (which ha

Re: operator precedence (thread)

comp.lang.c

Posted: 28 Days 18 Hours ago by: David Brown

Yes, on the whole. I try not to get worked up about it, but I don't think I am as patient and understanding as you! That's a reasonable point. A lot of people in my line of programming come from the other direction - electronics, the

Re: checking back chars when scaning - best way ? (thread)

comp.lang.c

Posted: 28 Days 19 Hours ago by: Stefan Ram

....

Re: checking back chars when scaning - best way ? (thread)

comp.lang.c

Posted: 28 Days 20 Hours ago by: fir

well that probably is better? if(*c== '/') if(c-text.beg>=1) if( *(c-1)== '/') inside_commentary = 1; looks unnatural but spares many ifs

Re: checking back chars when scaning - best way ? (thread)

comp.lang.c

Posted: 28 Days 20 Hours ago by: fir

probably suficient way here is if(c-text.beg>=1) if(*c== '/' && *(c-1)== '/') inside_commentary = 1; though this is probably runtime not optimal (and i may put megabyte long texts thru that too) changing the loop header is strongly no

Re: Memorizing C operator precedence (thread)

comp.lang.c

Posted: 28 Days 20 Hours ago by: Alan Mackenzie

That condition just checks that we're not trying to close a C line comment with a */, for example. Yes, unfortunately so. There's an ad-hoc convention where this variable is -1 in non-nested comments. It plays a role whe

Re: checking back chars when scaning - best way ? (thread)

comp.lang.c

Posted: 28 Days 20 Hours ago by: fir

shoud be int quote_mark_count = 0;

Re: Memorizing C operator precedence (thread)

comp.lang.c

Posted: 28 Days 20 Hours ago by: Alan Mackenzie

You make my point more eloquently than I could. ;-) 5 lines have become 20 non-comment lines plus comments, and several more lines will be needed to handle the decrementation of the variable `nesting'. These 2

Re: checking back chars when scaning - best way ? (thread)

comp.lang.c

Posted: 28 Days 20 Hours ago by: fir

i need genarally this loop to be preserved for(char* c = text; c<txt+end; c++) { //acces *c here } becouse i do more things here in that loop besides this kind of scanning is more general pattaern which i encounter from time to

Re: checking back chars when scaning - best way ? (thread)

comp.lang.c

Posted: 28 Days 20 Hours ago by: Richard Harnden

What is wrong with: strstr(text, "...") ?

Re: checking back chars when scaning - best way ? (thread)

comp.lang.c

Posted: 28 Days 20 Hours ago by: Jack Lemmon

Try using strstr function: char *strstr(const char *s1, const char *s2); <https://www.ibm.com/docs/en/i/7.4?topic=functions-strstr-locate-substring>

checking back chars when scaning - best way ?

comp.lang.c

Posted: 28 Days 22 Hours ago by: fir

assume you got routine that takes long string/literal char* txt as an input i need to scan for some patterns in it like "..." in this exist convenient is to check for(char* c = text; c<txt+end; c++) if(*c=='.' && *(c-1)=='.' *(c-2)=='.'

Re: operator precedence (thread)

comp.lang.c

Posted: 28 Days 22 Hours ago by: Ben

I think mean you prefer the a fixed number of spaces (one) around each binary operator and, guessing, none between unary operators and operands. Indeed I would not. As you know, I am not that interested in surface syntax. I have pref

Re: Memorizing C operator precedence (thread)

comp.lang.c

Posted: 28 Days 23 Hours ago by: Kaz Kylheku

I will take a set of test cases that break right away, over some comment that started lying 13 years ago, but nobody noticed untl now.

Re: operator precedence (thread)

comp.lang.c

Posted: 29 Days ago by: David Brown

I tend to stick to consistent spacing, but I am always open to bending such rules if it results in clearer code. (And I also understand that different people have different spacing rules that they apply at least reasonably consistentl

Re: Memorizing C operator precedence (thread)

comp.lang.c

Posted: 29 Days ago by: Malcolm McLean

/* Does a comment ender token actually end a comment? Params: code - the token (e.g. Sendcomment, Receivecomment [Malcolm ??]) syntax - syntax flags for current comment style (see SYNTAX_FLAGS) style

Re: Memorizing C operator precedence (thread)

comp.lang.c

Posted: 29 Days 1 Hour ago by: Ben

One concern is that this is not a plain condition since it sometimes has side effects. I'm comfortable with trivial cases of that (while (*cp++) .... for example) but there is more to check here. For example, it's not obvious that the

Re: Memorizing C operator precedence (thread)

comp.lang.c

Posted: 29 Days 3 Hours ago by: Alan Mackenzie

That was my point. Such rewriting bloats code, making it more difficult, as a whole, to understand. I disagree. The condition being coded is "horrible", so the code cannot be "nice". That condition is testing whether

Re: Memorizing C operator precedence (thread)

comp.lang.c

Posted: 29 Days 3 Hours ago by: Malcolm McLean

However code tends to change over time. Since the compiler has no way of understanding the comments, it can't warn when a comment is not updated to reflect a change in the code. If you have a "self-documenting" language or system, like Do

Re: operator precedence (thread)

comp.lang.c

Posted: 29 Days 8 Hours ago by: Tim Rentsch

Your comments cover most of what I was going to say. To add one more thought, the function definition can be simplified: inline _Bool bit_is_set( uintmax_t bits, unsigned n ){ return bits>>n & 1; } This definition

Re: Verbose assert (thread)

comp.lang.c

Posted: 29 Days 14 Hours ago by: Tim Rentsch

Just a few comments on this. One, the filename and line number can be combined to produce a single string literal at compile time, using the preprocessor and "gluing together" of string literals (and which can then be combined with the

Re: Memorizing C operator precedence (thread)

comp.lang.c

Posted: 29 Days 15 Hours ago by: Tim Rentsch

[...] I definitely agree with this. I also agree with this. Sometimes, but rarely. In most cases another choice is better. Yuck. Any expression complicated enough to need parentheses _and_ multiple lines _and_ some indication o

Re: Memorizing C operator precedence (thread)

comp.lang.c

Posted: 29 Days 15 Hours ago by: Tim Rentsch

Speaking for myself I would rather see something like this: [...] unsigned n = quantity; double price = item_price; return sale_charge( n, price ) + shipping_charge( n, price ); double sale_charge(

Re: operator precedence (thread)

comp.lang.c

Posted: 29 Days 17 Hours ago by: Ben

But this makes me wonder why uint64_t and not uint_least64_t. Do you really need no more than 64 bits? And why 1ul rather than UINT64_C(1) (or (uint64_t)1)? And what is going on with the cast, the != and the return value conversion?

Re: operator precedence (thread)

comp.lang.c

Posted: 29 Days 17 Hours ago by: Ben

You presumably think that there is only one notion of consistent spacing, but spacing to show operator binding is consistent with... well, with doing so. I've seen it quite a lot. I do it myself even when it hardly matters: int mid

Re: operator precedence (thread)

comp.lang.c

Posted: 29 Days 18 Hours ago by: Scott Lurndal

Or, inline _Bool test_bit(uint64_t qword, size_t bitnum) { return (_Bool) (qword & (1ul << bitnum)) != 0; } if (test_bit(board, row*COLS+col)) { ... } Easily extended to support an array of uint64_t when ROWS*COL

Re: operator precedence (thread)

comp.lang.c

Posted: 29 Days 18 Hours ago by: David Brown

If I saw that coming from someone in my team, I would treat it as worse than the original. Anyone who thinks mixing inconsistent spacing into this improves things, has completely missed the point (unless they are using some programming l

Re: operator precedence (thread)

comp.lang.c

Posted: 29 Days 19 Hours ago by: Tim Rentsch

Human readability can be improved as follows: board & 1 << row*COLS+col

Re: some observation about declaration in loop (thread)

comp.lang.c

Posted: 29 Days 19 Hours ago by: John Bode

In this loop the object designated by 'x' has "auto" storage duration - its lifetime is limited to a single loop iteration. Logically speaking, a new instance of 'x' is created and initialized at the beginning of the loop body and des

Re: C isn't a programming language (thread)

comp.lang.c

Posted: 29 Days 19 Hours ago by: Tim Rentsch

I think you are making assumptions about how the parser will be structured to reach this conclusion. It is quite possible to structure a parser that can accommodate any context free language, including those that have ambiguities, and w

Re: C isn't a programming language (thread)

comp.lang.c

Posted: 29 Days 19 Hours ago by: Tim Rentsch

Right. Context-free-style parsing is not limited to LR(k) parsers.

Re: ERROR: INVALID MEMORY REFERENCE (thread)

comp.lang.c

Posted: 29 Days 19 Hours ago by: Tim Rentsch

This call to fgets() will read at most 19 characters. Assuming the return value is not null, the memory pointed to by s might or might not contain a \n, but it will always contain a null character. In N1570, section 7.21.7.2, describi

Re: operator precedence (thread)

comp.lang.c

Posted: 29 Days 20 Hours ago by: james...@alumni.calt

On Monday, April 25, 2022 at 11:40:47 AM UTC-4, Tim Rentsch wrote:

Re: operator precedence (thread)

comp.lang.c

Posted: 29 Days 21 Hours ago by: Tim Rentsch

In conjunction with the other thread on operator precedence, I am interested to ask about what people know without having to look it up. So my question is, which operators, or precedence levels, do you feel confident that you can say co

Re: Verbose assert (thread)

comp.lang.c

Posted: 29 Days 21 Hours ago by: Tim Rentsch

I believe there is nothing to stop an implementation from defining #define __func__ __func__ The point, obviously, is that __func__ cannot be a macro that is useful in the same way that the predefined identifier is.

Re: Memorizing C operator precedence (thread)

comp.lang.c

Posted: 29 Days 21 Hours ago by: Vir Campestris

Absolutely. It has the great advantage that the comments say what the code is _supposed_ to do. If they disagree that's a great big alarm bell to anyone looking for bugs. "self documenting code" doesn't do that. Andy

Re: operator precedence (thread)

comp.lang.c

Posted: 29 Days 21 Hours ago by: Tim Rentsch

[...] The stated rule -- under the "either" interpretation -- requires (a+b) && c, not (a+b) && (c).

Re: Linus Torvalds prepares to move the Linux kernel to modern C

comp.lang.c

Posted: 29 Days 22 Hours ago by: Tim Rentsch

[...] I think it was done earlier in other languages, although I don't have a specific reference. Lisp goes back to 1958, the second oldest programming language still in common use.

Re: University Challenge (thread)

comp.lang.c

Posted: 29 Days 22 Hours ago by: Tim Rentsch

[...] Neither does anyone else. Different people just have different ideas about what tools are unnecessary.

Re: What part of... (Well, you know the rest!) (Was: gosub.c) (thread)

comp.lang.c

Posted: 29 Days 22 Hours ago by: Tim Rentsch

Even Algol had nested functions.

288 recent articles found.

rocksolid light 0.7.2
clearneti2ptor