Author Topic: How many people code in C these days, and if so, why?  (Read 48750 times)

0 Members and 4 Guests are viewing this topic.

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23096
  • Country: gb
Re: How many people code in C these days, and if so, why?
« Reply #225 on: May 10, 2020, 09:41:18 am »
Compiler and flags please?

Edit: irrelevant. Actually I just grepped about 3 megs of C code and can't find a single assignment to _Bool like that. I'm nto sure why you'd do it. Also works in python:

a = True
a = "hahahaa fuck the rules"

 :-//

Play stupid games, win stupid prizes. No one is stupid enough to play that game in our code. Just yours.

« Last Edit: May 10, 2020, 10:04:41 am by bd139 »
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8822
  • Country: fi
Re: How many people code in C these days, and if so, why?
« Reply #226 on: May 10, 2020, 09:45:10 am »
Yes, I don't disagree with the fact that your if("string") example is valid C (equivalent code is valid in many other languages, as well; and equally not making any sense), as is your modified code in post #204, which nobody has commented about, I was just looking for the point you are trying to make with your messages, but now that you have admitted you have none, and didn't even intend to, it explains many things, and it is unnecessary to discuss any further.

I would recommend you think before posting, so that you have actually something to say (not just some true/false/true/false claims without any point or reason behind them), in the future, to avoid driving threads into this kind of bullshit argumentation, for the argumentation's sake. This is because while you may be OK by just  :blah: ing for no reason, it's only natural that others expect there to be a reason, even a point, and are trying to find it, and fail. In other words, we are all trying to give you a chance, but you fail to deliver - assuming the deliverable of an internet forum is an "interesting discussion" or "increasing one's understanding"; not just fighting about whether claim X is true or false. What a waste of time, especially when coupled with classical goal shifting and outright lying.

So please just stop doing this, and start being honest with us. Thanks for your consideration.

This was inevitable, though. These kind of threads attract trolls. It stayed civil surprisingly long.
« Last Edit: May 10, 2020, 09:57:41 am by Siwastaja »
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6940
  • Country: fi
    • My home page and email address
Re: How many people code in C these days, and if so, why?
« Reply #227 on: May 10, 2020, 10:15:27 am »
What's in a tool?

I've written a raytracer – or, to be precise, a mixed method raycaster – for rendering ball and ball-and-stick atomic models containing anything from just a few atoms, to hundreds of millions of atoms, for producing quality animation for events in simulated molecular systems.  You know, the kind of size and complexity that gets your Nvidia card apoplexy.  Because of the algorithmic complexity, I had to go back to the underlying math, ten years ago, to get things to work reliably.  As I was using an old desktop machine with just a couple of gigs of RAM at the time, I even had to use memory-mapped files for accessing the data (if you know what MAP_NORESERVE does, you'll probably understand how).  (That entire tale, from combining different rasterization methods to reduce the number of objects tested for each ray, to consideration of information density in visualization and weirdnesses in human perception and exploiting them for conveying information, and to producing publication-quality graphics via low-resolution pixel images underneath raycast-solved vector outlines, is a funky tale in an of itself: I learned a lot there.  Then again, I actually worked it all out, instead of using existing toolkits and padding myself on the back for how good a "programmer" I am.  I didn't do it because I knew how to do it, I did it to learn how to do it.)

I do that kind of low-level code-mongery all the time, and for that, C seems most suitable.  Raytracing has long since passed from the pure mathematics of descriptive geometry to emphasizing the features of human perception (and exploiting its limitations), so reproducing early simple examples by applying extremely powerful existing libraries is a good exercise, but nothing impressive.

Back to topic at hand.  Why C?

The reason you do not want to use C++ for low-level cross-language libraries, is the risk of incompatible dependencies between different versions of the C++ runtime.  In theory, the dynamic linkers should handle it without issies, but reality is imperfect.  The nasty situation occurs when application A written in some other language than C++ needs libraries B and C, both of which depend on C++, but are compiled against different versions of the C++ runtime.

A lot of microcontroller development now uses some subset of C++ (or even G++, the GNU C++ variant provided by GCC).  While standard C has explicitly defined the freestanding environment (used in kernels and microcontrollers, when the standard C library and associated services are not available), the subset of C++ used varies, and is rarely if ever documented explicitly.  They usually do not support exceptions, but other verboten C++ features vary a lot.

Is it still C++ if one is supposed to keep to a strictly undocumented subset of its features?  Not just avoiding the standard library, but core features of the language like exceptions?  At least for C it (the freestanding environment) is well documented; for C++, almost all of it is implementation defined, and varies from implementation to implementation.  Can you still call it C++, if you need to test for support of each feature separately at build time?

To me, it only matters when this kind of discussion raises its head.  Whenever you see someone ridiculing others for using a tool they themselves cannot wield efficiently, there is stupidity afoot.

Consider this:

You are on a walk along a rocky river during one summer, when you come across a guy, obviously not an outdoorsman, with pasty skin not seen enough sunlight, now slightly burning, banging flint with a rock, obviously trying to recreate the way stone-age humans made their flint axes thousands if not tens of thousands of years ago.
You smirk to yourself, and walk past without saying a word.

What you do not know, is that that guy is a double PHD, expert in atomic force microscopy and nanorheometry, and is spending their summer day in getting some real-world practice in knapping flint.  Working at the scale of individual atoms, those materials science devices need sharp-tipped probes, preferably single atoms wide at their tip, that can withstand the vibration and movement close to the materials being investigated; and even today, knapping flint -- robotically, of course, nowadays -- is the best, most repeatable way we have of producing such minuscule tips.

What to you was an idiot banging rocks together, was actually somebody who understands reality fundamentally better than you.

Why didn't you know this?  Because Dunning-Kruger; and because tools are tools, and there are some that bridge a stone age human and a leading materials scientist of 2020s.



While C really isn't that good of a language, we don't have anything better in its niche – low-level libraries with bindings to multiple languages, and so on.  Anything that has a significant runtime or significant standard library won't cut it.  It's just a tool most suitable for its particular kinds of nails.

So, the simple answer is "because there are still problems for which C is the best tool".

For right now, I like doing math crunchy stuff in C (i.e., low-level code), and the user interface in Python.  I like the idea of end-users being able to modify the user interface if needed.

I don't touch Perl due to old battle scars.  Not really Perl's fault, I just had to work with a code base that was full of copy-paste-modify-slightly almost duplicates, critical to my users... You know the type: instead of fixing existing bugs, the functions are copied, the copy fixed, and only (some) future users using the fixed version, some the older version.  (This was two decades ago now, and Perl has evolved a lot since then, so I really should take a look again.  It's just that those scars itch easily.)

For quite a few years, I wrote lots and lots of PHP code.  Usually, the most critical part was to ensure none of the admins with access to the servers enabled "magic quotes" or other PHP misfeatures that gave it its reputation..  You can write quite secure code even in PHP.

Fortran is still common in HPC, especially physics and chemistry simulations.  While newer tools tend to be written in C or C++, if you want to duplicate old published results, you need to use that same code, too.  Sometimes that is very important, if you want to know exactly why your results differ from previously published similar-but-not-exactly-the-same results: you add your new model details to old code, and use the old code to compare the results for both cases.

The thing that annoys me most about some programmers, is that so many of them write code in the first language they learned, in every language they purport to know.
This is nothing new.  There was a saying already decades ago, "one can write FORTRAN code in any programming language", that describes this well.

In my opinion, that's not "knowing" anything, it is just mechanical translation.  It is like claiming you understand something, because you can recite a mathematical formula that in some situations describes its behaviour.

You could even say that some of the above examples of C code fall into this category, because they show code that would cause anybody who is familiar with existing C codebases to raise their eyebrows.  It is like saying that English is a horribly bad language, because in it "Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo." is a well-formed valid sentence.

Every programming language has some core beauty, some idea, some paradigm, that makes it efficient and useful (according to some metric -- it is easier to just call it beauty) for some tasks.  It is not important or useful to be able to mechanically translate code from one language to others; the important and useful part is understanding that beauty, and integrating it into your toolkit.  And then, being able to choose the appropriate tool from your toolkit to whatever problem you have at hand.
« Last Edit: May 10, 2020, 10:20:23 am by Nominal Animal »
 
The following users thanked this post: Siwastaja, MK14, 0db

Offline jfiresto

  • Frequent Contributor
  • **
  • Posts: 876
  • Country: de
Re: How many people code in C these days, and if so, why?
« Reply #228 on: May 10, 2020, 10:18:05 am »
...
Python's typing is handy, just type some letters from the keyboard without thinking, and it guesses the intent, and does fairly good job on it: when you test the code, it likely does what you wanted....

I have noticed many keep associating C with strong typing. They keep using those last two words, but I am not sure they mean what they think they mean. Python, especially Python 3 which dropped some risky implicit conversions, is much more strongly typed then C. If Python code tries to call a non-executable object, it will fail with an exception

Code: [Select]
>>> func_addr = 0x0
>>> func_addr()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not callable

whereas the C equivalent will happily call the null pointer. The above object has no __call__ method and if you try to call it, Python will let you know that. If you do not handle the TypeError, it will let you know it good and hard.

I think the distinction, if I correctly understand the criticism, is that C and Python are statically and dynamically typed, respectively. With C, you discover the type issues that the language and compiler care about, very early in the product's life cycle – at compile time; with Python, you discover type issues later to possibly quite later – when you or the customer actually run the code.

EDIT: changed second use of "the issues" to "type issues", since Python's issues do not match C's.
« Last Edit: May 10, 2020, 10:24:03 am by jfiresto »
-John
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 28050
  • Country: nl
    • NCT Developments
Re: How many people code in C these days, and if so, why?
« Reply #229 on: May 10, 2020, 10:24:42 am »
As noted herein by others, this is another example of "The right tool for the job". To which I would add, "...while also considering the person DOING the job". C is an excellent choice when the author is competent. The less competent the user, the more hand-holding and safety nets and babysitting they need.
That is true up to some point. Even the most skilled masters make mistakes. I like to avoid using C if I can. At least C++ allows to circumvent the use of pointers and freeing of dynamically allocated memory can be concentrated in the destructor of a class. But languages like Lua and Python are much more solving-the-problem-at-hand centric and don't suffer from overflows leading to an oil-stain which can't be traced back to the source. In C / C++ I add range checking to each layer of the software. That is just tedious stuff which doesn't add anything to the function of the program.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: 0db

Online nctnico

  • Super Contributor
  • ***
  • Posts: 28050
  • Country: nl
    • NCT Developments
Re: How many people code in C these days, and if so, why?
« Reply #230 on: May 10, 2020, 10:45:57 am »
Have to side with Cerebus here. The argument was void (excuse the pun).

I showed in post #204 that the example program is perfectly valid C that compiles and runs without warning, entirely in contradiction to what Cerebus said.

It received no response whatsoever.

Apparently facts are unpalatable when they are contrary to people's emotional beliefs.
There was a clear error in the code though: boolean isn't a C type but bool is (since C99). It is possible that an older (?) compiler comes with headers which define boolean as a type but AFAIK that isn't the common standard.

https://en.wikibooks.org/wiki/C_Programming/stdbool.h

It also seems the storage size of bool varies between compilers.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline engrguy42

  • Frequent Contributor
  • **
  • Posts: 656
  • Country: us
Re: How many people code in C these days, and if so, why?
« Reply #231 on: May 10, 2020, 11:25:16 am »
I'm right, you're WRONG !! 

No, I'M right, YOU'RE wrong !!!

I'm smarter than you.

No I'M smarter than YOU!!

I know how to Google stuff real fast. I'm much smarter than you.

You're an idiot because you spelled it wrong.

No, I'm RIGHT. It depends on what the definition of "is" is.

Hold on, I need to "thank" everyone who's agreeing with me.

I like C, so anyone who disagrees is a poo-poo head.

Lalalalalala....I'm ignoring you....

 :-DD
- The best engineers know enough to realize they don't know nuthin'...
- Those who agree with you can do no wrong. Those who disagree can do no right.
- I'm always amazed at how many people "already knew that" after you explain it to them in detail...
 
The following users thanked this post: Siwastaja

Online coppice

  • Super Contributor
  • ***
  • Posts: 9521
  • Country: gb
Re: How many people code in C these days, and if so, why?
« Reply #232 on: May 10, 2020, 11:45:10 am »
It also seems the storage size of bool varies between compilers.
I've always found that weird. The generated code rarely seems to improve through the use of a bool where sizeof(bool) is bigger than 1.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6940
  • Country: fi
    • My home page and email address
Re: How many people code in C these days, and if so, why?
« Reply #233 on: May 10, 2020, 12:47:50 pm »
typedef enum { true, false, FILE_NOT_FOUND } boolean;

:phew:
 

Offline chriva

  • Regular Contributor
  • *
  • Posts: 102
  • Country: se
Re: How many people code in C these days, and if so, why?
« Reply #234 on: May 10, 2020, 12:51:51 pm »
A C junkie here :)

While I do code in other languages too, there's something with C (and C++) I just love.
Very little abstraction. You can do wild (and equally as dangerous) stuff like derefing a pointer as a function and jump to it, jump to yourself, use goto (I don't care what you say, they're perfect for very specific tasks), _MACROS_, function attributes, etc etc :)

About bool: It's also very much processor dependant. Some have true/false flags in hardware. Some have particular instructions that takes less size but only affect a portion of the used hardware register etc. 68k and several other processors has instructions like ST/Set true, clr where only a byte of the register is set and the opcode is particularly small compared to move and whatnot. :)
« Last Edit: May 10, 2020, 12:54:21 pm by chriva »
 

Offline Picuino

  • Super Contributor
  • ***
  • Posts: 1033
  • Country: es
    • Picuino web
Re: How many people code in C these days, and if so, why?
« Reply #235 on: May 10, 2020, 01:35:20 pm »
Many times there is no real option to choose the language to use.
With microcontrollers and IOT world, C language is the only serious option to choose.
In other areas there is no better solution neither than C.
Therefore in many cases choosing the C language is a solution without many really good or serious alternatives.

Of course this is not the case in the world of web creation, for making GUIs or many other examples.
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23096
  • Country: gb
Re: How many people code in C these days, and if so, why?
« Reply #236 on: May 10, 2020, 01:41:56 pm »
This just popped into my head. An old Unix koan from ESR. Noted for the C comment...



A Unix zealot, having heard that Master Foo was wise in the Great Way, came to him for instruction. Master Foo said to him:

“When the Patriarch Thompson invented Unix, he did not understand it. Then he gained in understanding, and no longer invented it.”

“When the Patriarch McIlroy invented the pipe, he knew that it would transform software, but did not know that it would transform mind.”

“When the Patriarch Ritchie invented C, he condemned programmers to a thousand hells of buffer overruns, heap corruption, and stale-pointer bugs.”

“Truly, the Patriarchs were blind and foolish!”

The zealot was greatly angered by the Master's words.

“These enlightened ones,” he protested, “gave us the Great Way of Unix. Surely, if we mock them we will lose merit and be reborn as beasts or MCSEs.”

“Is your code ever completely without stain and flaw?” demanded Master Foo.

“No,” admitted the zealot, “no man's is.”

“The wisdom of the Patriarchs” said Master Foo, “was that they knew they were fools.”

Upon hearing this, the zealot was enlightened.
 

Offline madires

  • Super Contributor
  • ***
  • Posts: 8175
  • Country: de
  • A qualified hobbyist ;)
Re: How many people code in C these days, and if so, why?
« Reply #237 on: May 10, 2020, 02:07:49 pm »
TIOBE Index for May 2020
May Headline: Programming language C is back in the number one spot
https://www.tiobe.com/tiobe-index/

My take on those silly programming language wars is that you should use what suits you best and what gets the job done. Of course, when you're working in a team or have to maintain some legacy software you don't have the luxury of choosing the language. I don't mind to learn another one. I've stopped counting a long time ago. >:D
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2267
  • Country: 00
 
The following users thanked this post: chriva

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15397
  • Country: fr
Re: How many people code in C these days, and if so, why?
« Reply #239 on: May 10, 2020, 02:18:27 pm »
typedef enum { true, false, FILE_NOT_FOUND } boolean;

:phew:

Uh huh. As was discussed in other threads, C enums are just loose collections of integer constants, and the language doesn't have any provision for type-checking enums (beyond the values being integers).
Just the way it is. Yes it sucks a little.

And yes C99 added a true boolean type (_Bool, or bool if you include stdbool.h) which is guaranteed to hold only 1 or 0 (unless probably you mess with it using pointers and casts).
I've never been really bothered with older C versions not having a true boolean type. All you had to know was that 0 was considered false as a condition, and anything else, true. That worked well enough. There was no point directly testing a "boolean" (I'd say rather a "condition") against a value anyway (something I have already seen from some developers - ugly!) This would make no sense. One way it could make sense would be if you used a bool value not as a condition but as an integer value in some calculation. Something I've seen, but I find this wrong in many ways, and obfuscating. It doesn't even make sense from a strict type point of view IMO.

But likewise, I've once seen someone write stuff like: 'if (someboolean == true)'. Seriously buddy? How much more fucked up can it get? Not only would that lead to bugs in pure C (at least before C99 and/or not using the 'bool' type), but it was stupidly redundant anyway. A condition is just a condition. 'if (someboolean)' is correct and perfectly understandable. The above could get as recursive as possible while retaining the same absurdity: 'if ((someboolean == true) == true)'... What's the difference?

Ahah. I guess you can never really get into someone else's tortuous mind anyway.

OTOH, I make a strict distinction between the above (manipulating values that you consider as conditions, or booleans) and using any other kind of values as conditions. For instance, for testing pointers against NULL, I don't like 'if (pointer)' much, and will favor 'if (pointer != NULL)'. Some may not see a difference. There is. 'pointer' is just a pointer, it's not meant to hold a condition. In C, there is no difference language-wise, but from a coding style POV, I find this inconsistent. To elaborate with this example and link it to the above, if OTOH you used an intermediate variable as a "boolean" holding the same condition, that could be:

pointernotnull = pointer != NULL;
if (pointernotnull ) ...

Hope I made my point clear.
(That was just a slightly off-topic rant/precision.)
« Last Edit: May 10, 2020, 02:34:02 pm by SiliconWizard »
 
The following users thanked this post: chriva

Online nctnico

  • Super Contributor
  • ***
  • Posts: 28050
  • Country: nl
    • NCT Developments
Re: How many people code in C these days, and if so, why?
« Reply #240 on: May 10, 2020, 02:25:20 pm »
typedef enum { true, false, FILE_NOT_FOUND } boolean;

:phew:

Uh huh. As was discussed in other threads, C enums are just loose collections of integer constants, and the language doesn't have any provision for type-checking enums (beyond the values being integers).
Just the way it is. Yes it sucks a little.

And yes C99 added a true boolean type (_Bool, or bool if you include stdbool.h) which is guaranteed to hold only 1 or 0 (unless probably you mess with it using pointers and casts).
I've never been really bothered with older C versions not having a true boolean type. All you had to know was that 0 was considered false as a condition, and anything else, true. That worked well enough. There was no point directly testing a "boolean" (I'd say rather a "condition") against a value anyway (something I have already seen from some developers - ugly!) This would make no sense. One way it could make sense would be if you used a bool value
I strongly disagree on this. IMHO a comparison should always show what is being compared; it will make the code unambiguous to someone not well versed in a language. This is especially true for C because only 0 is false and anything else is true. For that reason my API functions always return -1 (failure) or 1 (success).
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline engrguy42

  • Frequent Contributor
  • **
  • Posts: 656
  • Country: us
Re: How many people code in C these days, and if so, why?
« Reply #241 on: May 10, 2020, 02:44:44 pm »
More importantly, even though C# and .NET are an f***'d up disaster, I somehow managed to add CSV file logging to my data acquisition app. Less than an hour. Got lucky I guess.  :-+
- The best engineers know enough to realize they don't know nuthin'...
- Those who agree with you can do no wrong. Those who disagree can do no right.
- I'm always amazed at how many people "already knew that" after you explain it to them in detail...
 

Offline madires

  • Super Contributor
  • ***
  • Posts: 8175
  • Country: de
  • A qualified hobbyist ;)
Re: How many people code in C these days, and if so, why?
« Reply #242 on: May 10, 2020, 02:47:37 pm »
It also seems the storage size of bool varies between compilers.
I've always found that weird. The generated code rarely seems to improve through the use of a bool where sizeof(bool) is bigger than 1.

The developer of the compiler has chosen whatever the CPU processes with the least amount of clock cycles. If the CPU needs the same number of clock cycles for an 8 bit, 16 bit, 32 bit or 64 bit value then roll a dice or think about memory usage and management.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8822
  • Country: fi
Re: How many people code in C these days, and if so, why?
« Reply #243 on: May 10, 2020, 02:49:03 pm »
IMHO,

if(dog_exists) // makes sense to a normal human being
if(dog_exists == true) // sounds like a tax bureacraut wrote this
if(dog_does_not_exist == false) // argh!

If you find adding excess "== true" or "== false" tests for bools makes the code more readable, that's a sign that your variable naming sucks or the variable logic is upside-down.

Or, that you are just stuck in this practice often seen by novices. Even experienced people have their blind spots.
« Last Edit: May 10, 2020, 02:54:59 pm by Siwastaja »
 
The following users thanked this post: SiliconWizard

Online nctnico

  • Super Contributor
  • ***
  • Posts: 28050
  • Country: nl
    • NCT Developments
Re: How many people code in C these days, and if so, why?
« Reply #244 on: May 10, 2020, 02:57:34 pm »
IMHO,

bool dog_exists;

if(dog_exists) // makes sense to a normal human being
if(dog_exists == true) // sounds like a tax bureacraut wrote this
The problem is that in C 'if' can be used with any type. So in order to fully understand what 'if(dog_exists)' does exactly you need to look up what type dog_exists is first. If you write 'if(dog_exists == true)' then it is clear that dog_exists is a boolean immediately. That makes reading & modifying the code a whole lot easier. The easier code is to read & understand the easier it is to hand over to someone else (including a novice). I'm not a fan of elitist code styles which basically say 'screw you novice, spend another year in kindergarten'. Then you are wasting people's salary because they are not as productive as they can be even though they may not grasp every tiny detail of the C syntax.
« Last Edit: May 10, 2020, 03:01:39 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline chriva

  • Regular Contributor
  • *
  • Posts: 102
  • Country: se
Re: How many people code in C these days, and if so, why?
« Reply #245 on: May 10, 2020, 03:04:44 pm »
Finding new ways to abstract things that in effect are the same thing is making the code harder to read if anything.

 

Offline madires

  • Super Contributor
  • ***
  • Posts: 8175
  • Country: de
  • A qualified hobbyist ;)
Re: How many people code in C these days, and if so, why?
« Reply #246 on: May 10, 2020, 03:07:12 pm »
And yes C99 added a true boolean type (_Bool, or bool if you include stdbool.h) which is guaranteed to hold only 1 or 0 (unless probably you mess with it using pointers and casts).
I've never been really bothered with older C versions not having a true boolean type. All you had to know was that 0 was considered false as a condition, and anything else, true. That worked well enough. There was no point directly testing a "boolean" (I'd say rather a "condition") against a value anyway (something I have already seen from some developers - ugly!) This would make no sense. One way it could make sense would be if you used a bool value not as a condition but as an integer value in some calculation. Something I've seen, but I find this wrong in many ways, and obfuscating. It doesn't even make sense from a strict type point of view IMO.

The C way of using an unsigned integer as boolean variable is very similar to the assembler CPU commands. From a software developer's point of view of a clean and perfect language it seems bad and ugly, but when you consider assembler it's actually beautiful. You can use it as a boolean flag and a counter as the same time. More efficient than using two variables, one boolean flag and a counter.
 
The following users thanked this post: Siwastaja, chriva

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15397
  • Country: fr
Re: How many people code in C these days, and if so, why?
« Reply #247 on: May 10, 2020, 03:17:28 pm »
And yes C99 added a true boolean type (_Bool, or bool if you include stdbool.h) which is guaranteed to hold only 1 or 0 (unless probably you mess with it using pointers and casts).
I've never been really bothered with older C versions not having a true boolean type. All you had to know was that 0 was considered false as a condition, and anything else, true. That worked well enough. There was no point directly testing a "boolean" (I'd say rather a "condition") against a value anyway (something I have already seen from some developers - ugly!) This would make no sense. One way it could make sense would be if you used a bool value not as a condition but as an integer value in some calculation. Something I've seen, but I find this wrong in many ways, and obfuscating. It doesn't even make sense from a strict type point of view IMO.

The C way of using an unsigned integer as boolean variable is very similar to the assembler CPU commands. From a software developer's point of view of a clean and perfect language it seems bad and ugly, but when you consider assembler it's actually beautiful. You can use it as a boolean flag and a counter as the same time. More efficient than using two variables, one boolean flag and a counter.

Just a detail - it doesn't need to be unsigned. It's again just 0 or not 0. And sure the idea was to make efficient use of underlying CPUs.

But it's not particularly ugly. Some people may find it quirky, but that's largely questionable. In my eyes, "0" or "not 0" are 2 distinct states that are perfectly valid for holding a boolean value.
People insisting on it needing to strictly have only two different values (like 0 or 1) are just biased seeing a boolean as a binary digit. 0 or 1 have no particular meaning per se. All a boolean needs to hold IMHO are two different and exclusive states. The rest is mind wanking IMO. YMMV.
 
The following users thanked this post: Siwastaja, chriva

Online nctnico

  • Super Contributor
  • ***
  • Posts: 28050
  • Country: nl
    • NCT Developments
Re: How many people code in C these days, and if so, why?
« Reply #248 on: May 10, 2020, 03:28:14 pm »
Agreed. For all we know 'true' may be defined as 42  >:D
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline IDEngineer

  • Super Contributor
  • ***
  • Posts: 1941
  • Country: us
Re: How many people code in C these days, and if so, why?
« Reply #249 on: May 10, 2020, 03:43:30 pm »
With respect to the use of booleans in C....

I'm a huge proponent of the style "if (boolean)" or "if (!boolean)" for several reasons. First, IMHO it's concise and clearly conveys what is being evaluated. YMMV.

Second, long ago I was analyzing the Assembly language output from a compiler and found that it generated different code depending upon how if statements were written. If I wrote "if (variable)" or "if (!variable)", it generated ultra-tight code by clearing the Z flag, pulling the variable into a register, OR'ing the register with itself which (might) set the Z flag, and then testing the state of the Z flag. But if I wrote "if (variable == true)" the compiler actually performed a comparison with an immediate value equal to "true" (or whatever value was specified), generating signficantly more Assembly instructions for the same net result.

Having learned this, I also started testing non-boolean variables for zero with "if (!variable)" which yielded smaller, faster code as described above. This was especially nice (and low cost) when checking for null pointers.

I lived in this blissful state for a very long time. THEN... my code started failing in weird ways on some project. So I dug into the Assembly generated by THAT compiler, and to my horror discovered that it did not generate proper Assembly unless a value was specified for the comparison! That is, "if (boolean)" and "if (!boolean)" generated BROKEN CODE but "if (boolean == true)" and "if (boolean == false)" did not. The != versions also generated proper code. The compiler simply demanded two explicit values to compare. I could not believe it, but I was trapped by the authors of that compiler. Once I rewrote my code to always provide a value against which to compare, it started working perfectly.

This is a long winded way of saying that despite agreeing it looks terrible and should not be necessary, I now write "if (boolean == true)" even though strictly speaking it is not necessary. I do so because that source code will always work with every compiler I've ever encountered, whereas I know there's a team out there somewhere that wrote a compiler where that would silently (e.g. without reporting an error, nor even a warning) generate broken code without the immediate value. Supporting two values with a comparison operator between them is so fundamental to the language that we can safely presume it will always work, so for reliability I now write that way. And I urge the universe to inflict terrible harm on that compiler team every time I do so.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf