Author Topic: "Stop Teaching C" - Kate Gregory  (Read 30014 times)

0 Members and 1 Guest are viewing this topic.

Offline AG6QR

  • Frequent Contributor
  • **
  • Posts: 812
  • Country: us
    • AG6QR Blog
Re: "Stop Teaching C" - Kate Gregory
« Reply #100 on: November 01, 2016, 04:24:50 pm »
In addition to providing the interface, the .h files make it possible to provide the libraries of the functions without providing the actual source code.
and why is that needed ?

if the compiler traverses all files in a directory ti will find the libraries. whether those exist as .c files or as .obj . doesn't matter.

In large projects, developed by large, distributed teams, there's often a need to control the distribution of function signatures.  I worked on a commercial product which included libraries distributed to customers.  It was divided into a number of components.  We had four levels of function distributions:

  • Public -- documented to our customers and available for them to call
  • Intracomponent -- sort of "internally public", meaning different components that we developed in our company could share Intracomponent functions, and they were somewhat documented internally among ourselves, but we didn't allow customers to call them.
  • Within a single component -- shared inside a single component only
  • Within a single source file

Why the need for the different levels of publishing and sharing functions?  It's a form of encapsulation.  By limiting the distribution of a component's internal functions, those internals could be freely changed as the software evolved, without having to worry that someone had already written software that relied on a particular function signature that, in retrospect, wasn't a good one.  It meant we could freely and safely put hidden internal things into functions without worrying that some customer would write software that called those functions.

We implemented this by having different header files in different directories, and sharing those directories appropriately.  Not all projects would need this particular set of levels of sharing, but the header file concept makes it easy to implement whatever level of sharing is appropriate for your project.


I do agree that, in general, it's bad to have something expressed twice when it can be expressed once.  Header files express a function's signature twice, once in the header file and once in the function definition.  Having the function signatures expressed only one place would be preferable.  But header files can express another thing about the function: They can express how widely you intend to share the function.  If you do away with header files, you would need to provide another mechanism to express this.
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4349
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #101 on: November 01, 2016, 04:38:36 pm »
I do agree that, in general
it's bad to have something expressed twice
when it can be expressed once. 
Header files express a function's signature twice,
once in the header file and once in the function definition. 

mmm, in my case you write the body
and the compiler will automatically build the interface

therefore you write boolean_t is_foo() { ... }
and it will fill  "boolean_t is_foo()" in the module.interface
which is included in module.h

it's saving a lot of troubles here, and it's damn productive
the downside of this approac is that if change the interface
e.g.   boolean_t is_foo( uint32_t magic ) you are breaking
the compatibility of your library, therefore I have implemented
a mechanism which refuses to accept the new commit
until you have turned it into a branch and changed the
module name or - at least - increased the revision

it's not a definitive solution, but it works  :-+
 

Offline setq

  • Frequent Contributor
  • **
  • Posts: 444
  • Country: gb
Re: "Stop Teaching C" - Kate Gregory
« Reply #102 on: November 01, 2016, 04:49:17 pm »
Have some more C++ buggery now I have a few minutes. Firstly, we'll compile a couple of hello worlds:

First the C version

Code: [Select]
#include <stdio.h>

void say_hello(char *to_whom) {
        printf("Hello %s", to_whom);
}

Now the C++ version

Code: [Select]
#include <iostream>

using namespace std;

void say_hello(string to_whom) {
        cout << "Hello " << to_whom << endl;
}

Compile them quickly into object files only...

Code: [Select]
[setq@shodan ~]$ g++ -c hellocpp.cpp
[setq@shodan ~]$ gcc -c hello.c

Now let's look at the symbol table in the ELF file generated by the C program:

Code: [Select]
[setq@shodan ~]$ readelf -s hello.o
Symbol table '.symtab' contains 11 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS hello.c
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    1
     3: 0000000000000000     0 SECTION LOCAL  DEFAULT    3
     4: 0000000000000000     0 SECTION LOCAL  DEFAULT    4
     5: 0000000000000000     0 SECTION LOCAL  DEFAULT    5
     6: 0000000000000000     0 SECTION LOCAL  DEFAULT    7
     7: 0000000000000000     0 SECTION LOCAL  DEFAULT    8
     8: 0000000000000000     0 SECTION LOCAL  DEFAULT    6
     9: 0000000000000000    36 FUNC    GLOBAL DEFAULT    1 say_hello
    10: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND printf


Yep that made sense. There's a FUNC in there called say_hello and it calls out to printf. Easy money.

Now for C++

Code: [Select]
[setq@shodan ~]$ readelf -s hellocpp.o
Symbol table '.symtab' contains 23 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS hellocpp.cpp
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    1
     3: 0000000000000000     0 SECTION LOCAL  DEFAULT    3
     4: 0000000000000000     0 SECTION LOCAL  DEFAULT    4
     5: 0000000000000000     1 OBJECT  LOCAL  DEFAULT    4 _ZStL8__ioinit
     6: 0000000000000000     0 SECTION LOCAL  DEFAULT    5
     7: 0000000000000039    61 FUNC    LOCAL  DEFAULT    1 _Z41__static_initializati
     8: 0000000000000076    21 FUNC    LOCAL  DEFAULT    1 _GLOBAL__sub_I__Z9say_hel
     9: 0000000000000000     0 SECTION LOCAL  DEFAULT    6
    10: 0000000000000000     0 SECTION LOCAL  DEFAULT    9
    11: 0000000000000000     0 SECTION LOCAL  DEFAULT   10
    12: 0000000000000000     0 SECTION LOCAL  DEFAULT    8
    13: 0000000000000000    57 FUNC    GLOBAL DEFAULT    1 _Z9say_helloSs
    14: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND _ZSt4cout
    15: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND _ZStlsISt11char_traitsIcE
    16: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND _ZStlsIcSt11char_traitsIc
    17: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND _ZSt4endlIcSt11char_trait
    18: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND _ZNSolsEPFRSoS_E
    19: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND _ZNSt8ios_base4InitC1Ev
    20: 0000000000000000     0 NOTYPE  GLOBAL HIDDEN   UND __dso_handle
    21: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND _ZNSt8ios_base4InitD1Ev
    22: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND __cxa_atexit

Wow that was a really clean abstraction. Not! Looks like Perl laid a turd in the middle of the symbol table. And all the other shit it has to bring in just to talk to a stream. And that's the tangle that C++ leaves you in all the time. Ugh kill me.

I'm off to go and write some PIC16 assembly now - that stuff is eye bleach programming bliss.
« Last Edit: November 01, 2016, 04:53:05 pm by setq »
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4349
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #103 on: November 01, 2016, 04:55:08 pm »
assembly now

it happens because in C++ you have
string_t, which is not just an array with '\0' at the end
it's true type, a struct, which implies methods, e.g. "<<"

a part of the machine code needs to be taken
to fetch out these details e.g. invoking the method
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 7242
  • Country: us
    • SiliconValleyGarage
Re: "Stop Teaching C" - Kate Gregory
« Reply #104 on: November 01, 2016, 05:04:40 pm »
who uses tape these days ?

bad example, dude, I use tapes  :D


but not as primary random access storage ! that would be fun compiling a project. waiting for the tape robot to find the tape where the file is stored , load it, fast forward / rewind to where it sits, read it , save the obj to another tape... people are now already complaining if a compile takes 5 seconds or longer ....

Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline setq

  • Frequent Contributor
  • **
  • Posts: 444
  • Country: gb
Re: "Stop Teaching C" - Kate Gregory
« Reply #105 on: November 01, 2016, 05:07:33 pm »
assembly now

it happens because in C++ you have
string_t, which is not just an array with '\0' at the end
it's true type, a struct, which implies methods, e.g. "<<"

a part of the machine code needs to be taken
to fetch out these details e.g. invoking the method

I know why. It just feels like ceremonial on the lines of:

 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 7242
  • Country: us
    • SiliconValleyGarage
Re: "Stop Teaching C" - Kate Gregory
« Reply #106 on: November 01, 2016, 05:15:55 pm »
As I mentioned previously C and C++ are very difficult to parse reliably. I think the .h files (or more generally forward declarations) makes the compiler's job a lot easier.
multipass compilation solves parsing problem.

pass 1 : go over source file and collect functions and subroutines. build a map in memory of their definition (what goes in and out) and attach the source or object. once all the files are loaded in ram then all source and object is loaded as well. at this point all routines available are known and also all routines that are being called are known. if a callee is missing : stop compilation as something is missing. if something is not called : remove it as it is unused and not necessary for the program. (this results in automatically stripping superfluous functions from libraries.)

pass 2 : compile all standalone functions ( functions that do not call others ) into machine language. create a callable and in-line variant for each.
pass 3 : compile functions that call others. direct calls become in-line. nested calls become true calls.
repeat pass 3 until top level of hierarchy is reached.
pass 4 : map final memory allocation for all function and assign hard addresses. (essentially linking)
pass5 : spit out binary.

pl/m compilers back in 1972 already could do that. it's 2016. don't you think it is time C started doing that too ?
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 2560
  • Country: it
Re: "Stop Teaching C" - Kate Gregory
« Reply #107 on: November 01, 2016, 05:33:09 pm »
same goes for the stupidity with typecasting. on some compilers an in is 8 bit , on other it is 16 bit , ... why on earth does that have to change ? remember the ariane rocket that blew up ? that was because the real hardware had an int as 16 bit while on the emulator it was treated as 32 bit.... the same code overflowed in the rocket ... because the idiots who build compilers think it is ok to have different definitions for the same type....
while i agree, fixed lenght types do exist (int8_t, uint32_t etc.)
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 1794
  • Country: fi
  • Embedded SW/HW.
Re: "Stop Teaching C" - Kate Gregory
« Reply #108 on: November 01, 2016, 05:39:17 pm »
In addition to providing the interface, the .h files make it possible to provide the libraries of the functions without providing the actual source code.
and why is that needed ?

if the compiler traverses all files in a directory ti will find the libraries. whether those exist as .c files or as .obj . doesn't matter.

my claim is : there is no need for includes and .h files. all the compiler has to do is look in the directory where the project is stored (and its subdirectories) and see if it can find the function, either in source or object. if it can't find it there : stop compilation.

How about the constants, type definitions, data structures etc. There is a lot more than just functions in programming.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 18031
  • Country: nl
    • NCT Developments
Re: "Stop Teaching C" - Kate Gregory
« Reply #109 on: November 01, 2016, 05:51:52 pm »
As I mentioned previously C and C++ are very difficult to parse reliably. I think the .h files (or more generally forward declarations) makes the compiler's job a lot easier.
multipass compilation solves parsing problem.

pass 1 : go over source file and collect functions and subroutines. build a map in memory of their definition (what goes in and out) and attach the source or object. once all the files are loaded in ram then all source and object is loaded as well. at this point all routines available are known and also all routines that are being called are known. if a callee is missing : stop compilation as something is missing. if something is not called : remove it as it is unused and not necessary for the program. (this results in automatically stripping superfluous functions from libraries.)

pl/m compilers back in 1972 already could do that. it's 2016. don't you think it is time C started doing that too ?
GCC can do that just fine for many years BUT you have to be carefull with interrupt routines which aren't called from anywhere else.
Besides that there is much more to compiling C than you seem to be aware of. The first step is collecting all the header files and evaluating the pre-processor macros by the pre-processor and put everything in one file with pure C code which is then compiled by the compiler into an object file. Compiling a C program consists of: pre-processing, compiling and linking. The pre-processing stages makes it easy to re-use code by using constants defined in one place and/or include/exclude parts of code depending on variables (which can be supplied on the command line).
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4349
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #110 on: November 01, 2016, 06:08:51 pm »
you have to be carefull with interrupt routines
which aren't called from anywhere else

in the theory the body of an isr should be at least loaded
therefore their names should compare inside an initializer

e.g.
Code: [Select]
void isr_init()
{
  ..
  isr_set(isr_machine_exception, 0x00000100);
  ..
}

it's not the only way to handle isr, I find it useful
 

Offline John Coloccia

  • Super Contributor
  • ***
  • Posts: 1199
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #111 on: November 01, 2016, 07:01:20 pm »
As I mentioned previously C and C++ are very difficult to parse reliably. I think the .h files (or more generally forward declarations) makes the compiler's job a lot easier.
multipass compilation solves parsing problem.

pass 1 : go over source file and collect functions and subroutines. build a map in memory of their definition (what goes in and out) and attach the source or object. once all the files are loaded in ram then all source and object is loaded as well. at this point all routines available are known and also all routines that are being called are known. if a callee is missing : stop compilation as something is missing. if something is not called : remove it as it is unused and not necessary for the program. (this results in automatically stripping superfluous functions from libraries.)

pass 2 : compile all standalone functions ( functions that do not call others ) into machine language. create a callable and in-line variant for each.
pass 3 : compile functions that call others. direct calls become in-line. nested calls become true calls.
repeat pass 3 until top level of hierarchy is reached.
pass 4 : map final memory allocation for all function and assign hard addresses. (essentially linking)
pass5 : spit out binary.

pl/m compilers back in 1972 already could do that. it's 2016. don't you think it is time C started doing that too ?

I'm not sure you're thinking this through clearly. Consider something like this:

a * b;

To do what you suggest would require looking through every tiny little bit of code to see just what the heck "a" is. Do you intend to multiply a*b, or are you declaring a pointer to something of type a? That's just one example.

I could keep going on this, but there's a reason C is the way it is, and why it hasn't really changed. More modern languages don't have ambiguities like this, or at least they're limited and easily addressed, so the compiler doesn't run into a brick wall. C is just not well suited for this sort of thing.
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 616
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: "Stop Teaching C" - Kate Gregory
« Reply #112 on: November 01, 2016, 10:18:21 pm »
my claim is : there is no need for includes and .h files.
Correct. Just put everything in a single source file - makes the compiler's job a lot easier!  ;)
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 9212
  • Country: my
  • reassessing directives...
Re: "Stop Teaching C" - Kate Gregory
« Reply #113 on: November 01, 2016, 10:50:25 pm »
same goes for the stupidity with typecasting. on some compilers an in is 8 bit , on other it is 16 bit , ... why on earth does that have to change ? remember the ariane rocket that blew up ? that was because the real hardware had an int as 16 bit while on the emulator it was treated as 32 bit.... the same code overflowed in the rocket ... because the idiots who build compilers think it is ok to have different definitions for the same type....
while i agree, fixed lenght types do exist (int8_t, uint32_t etc.)
the rocket programmer was not aware of that, so the compiler programmer is to be blamed.
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Offline John Coloccia

  • Super Contributor
  • ***
  • Posts: 1199
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #114 on: November 01, 2016, 11:22:59 pm »
Believe it or not, it's for machine independence. Blame the idiot programming team that depends on running the code in simulation to check for overflows and things like that. It's a failure in specification and could happen regardless of language.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 18031
  • Country: nl
    • NCT Developments
Re: "Stop Teaching C" - Kate Gregory
« Reply #115 on: November 01, 2016, 11:34:19 pm »
same goes for the stupidity with typecasting. on some compilers an in is 8 bit , on other it is 16 bit , ... why on earth does that have to change ? remember the ariane rocket that blew up ? that was because the real hardware had an int as 16 bit while on the emulator it was treated as 32 bit.... the same code overflowed in the rocket ... because the idiots who build compilers think it is ok to have different definitions for the same type....
while i agree, fixed lenght types do exist (int8_t, uint32_t etc.)
IMHO you should always use the fixed length types (inttypes.h) and not the typical C types (char, int, long, etc) because they are defined poorly. Also check the range of floating point types to make sure you don't run into trouble. See http://stackoverflow.com/questions/752309/ensuring-c-doubles-are-64-bits
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3078
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #116 on: November 02, 2016, 02:06:55 am »
Quote
remember the ariane rocket that blew up ? that was because the real hardware had an int as 16 bit while on the emulator it was treated as 32 bitthat was Ada.   "AdaTran", actually - badly converted Fortran.
https://vimeo.com/44792649#t=530s
Language used sounds like it was one of the least of their problems :-(
(Though I like the comment "If it had been written in C, it wouldn't have blown up.")
« Last Edit: November 02, 2016, 02:26:54 am by westfw »
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4349
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #117 on: November 02, 2016, 07:49:51 am »
my claim is : there is no need for includes and .h files.
Correct. Just put everything in a single source file
- makes the compiler's job a lot easier!  ;)

sarcasm?  :-DD
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4349
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #118 on: November 02, 2016, 07:58:56 am »
they are defined poorly

yep, a mess

e.g.
m68k (CISC)
a long is 32bit
a short is 16bit
a char is 8bit(2)
a word is 16bit
there is no half
a long long is 64bit

MIPS (RISC)
a long is 32bit
a short is 16bit(1)
a char is 8bit(2)
a word is 32bit <------
there is also half (word), which is 16bit
a long long is 64bit <-----


(1) but sometimes with PowerPC (RISC) is 32bit
I have seen sizeof(short)=2byte, sometimes =4byte
WTF  :wtf: :wtf: :wtf:


(2) some DSP by TI says that char is 16bit  :-// :-// :-//
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4349
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #119 on: November 02, 2016, 08:07:57 am »
word and half are not *C terms*
they come from CPU manuals
like a contribute to the confusion  :palm:

I believe "word" was 16bit with 68K
(which is a true 32bit machine)
because the 68000 bus was 16bit
while the R2000 bus was 32bit

therefore half (word) makes sense for MIPS

the problem is: the C language should not stay
so close to the hardware, especially if it aims
for being a portable language

it's just an example, it shows the wrong attitude
 

Online hamster_nz

  • Super Contributor
  • ***
  • Posts: 2137
  • Country: nz
Re: "Stop Teaching C" - Kate Gregory
« Reply #120 on: November 02, 2016, 08:20:00 am »
word and half are not *C terms*
they come from CPU manuals
like a contribute to the confusion  :palm:

I believe "word" was 16bit with 68K
(which is a true 32bit machine)
because the 68000 bus was 16bit
while the R2000 bus was 32bit

therefore half (word) makes sense for MIPS

the problem is: the C language should not stay
so close to the hardware, especially if it aims
for being a portable language

it's just an example, it shows the wrong attitude

It shows that the language doesn't fit your problem you are using it for.

It doesn't really show that the language has the wrong attitude...

Take for example early PC development, with 'near pointers' and 'far pointers' and 'huge pointers'. Much to C's credit it could actually be made to work with such painful system with only a few extra key words.

The problem isn't that the language wasn't portable, it is that the programmer was unaware of the assumptions they are working under.

 I am currently working on something to process audio files. It would be really easy for me to write a program that reads a WAV file on my PC, but fails on other h/w due to endian mismatch.

Do I say "Stupid language", or "Stupid hardware designer", or "Stupid me"?

I say "stupid me" - I should be doing it in something like MatLab anyway, but hey, I know C, I am lazy, and the problem looks like a nail to me. :)
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3078
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #121 on: November 02, 2016, 08:21:28 am »
Quote
m68k (CISC)
a long is 32bit
a short is 16bit
  :

x86 (CISC):
depends on compiler settings.  (actually, I'm pretty sure that's true of MIPS64 as well.  Probably ARM64 too; it's at least a gcc thing.)
I think you get your choice of "longs and ptrs are 32 bits", "longs are still 32bits bit pointers are 64", "longs are 64bits but pointers are still 32bits", and "longs and ptrs are both 64bits."
It's a bit shocking how much code breaks when sizeof (long*) != sizeof(long)...
« Last Edit: November 02, 2016, 08:23:22 am by westfw »
 

Offline John Coloccia

  • Super Contributor
  • ***
  • Posts: 1199
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #122 on: November 02, 2016, 08:28:02 am »
they are defined poorly

yep, a mess

e.g.
m68k (CISC)
a long is 32bit
a short is 16bit
a char is 8bit(2)
a word is 16bit
there is no half
a long long is 64bit

MIPS (RISC)
a long is 32bit
a short is 16bit(1)
a char is 8bit(2)
a word is 32bit <------
there is also half (word), which is 16bit
a long long is 64bit <-----


(1) but sometimes with PowerPC (RISC) is 32bit
I have seen sizeof(short)=2byte, sometimes =4byte
WTF  :wtf: :wtf: :wtf:


(2) some DSP by TI says that char is 16bit  :-// :-// :-//

The basic way it works is:

- int is USUALLY the word size of the machine, thought that's generally no longer true on 64 bit systems
- char is the smallest addressable unit, which is normally 8 bits, but there are a number of processors (usually DSPs) where it's larger. It's always 8 bits or more regardless, though

Beyond that, the types are defined like this:

- each type must hold some MINIMUM value. For example, a char must be able to hold at least +/-127
- each type must not be smaller than the one that came before. So for example, just looking at the minimums, it's conceivable that a short be 64 bits and an int 32 bits, but that's not allowed.

So anyhow, if it's not enough to know the minimums, then you need to use fixed width types. I agree...it's a mess.
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 1794
  • Country: fi
  • Embedded SW/HW.
Re: "Stop Teaching C" - Kate Gregory
« Reply #123 on: November 02, 2016, 08:33:15 am »
In C  the sizeof(char) == 1, but the char may be 8, 16, 24 bits or something else depending of the architecture. For example, in some DSPs a char is 16 bits or even 24 bits.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 10299
  • Country: gb
    • Having fun doing more, with less
Re: "Stop Teaching C" - Kate Gregory
« Reply #124 on: November 02, 2016, 08:40:51 am »
It shows that the language doesn't fit your problem you are using it for.

That's a valid observation, but it raises two important questions:
  • why do people (plural) use the "wrong" language for the problem
  • what is the domain for which there are no better languages
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf