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

0 Members and 2 Guests are viewing this topic.

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 11535
  • Country: my
  • reassessing directives...
Re: "Stop Teaching C" - Kate Gregory
« Reply #75 on: November 01, 2016, 12:35:17 pm »
(It's a shame that strings in the C++ sense are so ... incompatible with deep embedded systems.  And that's a bit strange; they worked OK in BASIC on far less powerful computers, didn't they?   There would be so many fewer problems in the Arduino world if their String types actually worked well.)
Well.. nothing stops you from creating your own string type.
we dont need a new language. what we need is a unified data type and safe coding style education. but well, everybody like to make their own philosophy...
Nature: Evolution and the Illusion of Randomness (Stephen L. Talbott): Its now indisputable that... organisms “expertise” contextualizes its genome, and its nonsense to say that these powers are under the control of the genome being contextualized - Barbara McClintock
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #76 on: November 01, 2016, 12:43:27 pm »
Code: [Select]
ev-lang/gnat-gcc-4.6.4/image//usr
mkdir -p -- /var/tmp/portage/dev-lang/gnat-gcc-4.6.4/image//usr /var/tmp/portage/dev-lang/gnat-gcc-4.6.4/image//usr
/bin/sh: line 3: cd: host-i686-pc-linux-gnu/fixincludes: No such file or directory
Makefile:4750: recipe for target 'install-fixincludes' failed
make[1]: *** [install-fixincludes] Error 1
make[1]: Leaving directory '/var/tmp/portage/dev-lang/gnat-gcc-4.6.4/work/gcc-4.6.4'
Makefile:2689: recipe for target 'install' failed
make: *** [install] Error 2
 * ERROR: dev-lang/gnat-gcc-4.6.4::gentoo failed (install phase):
 *   emake failed
 *

may Saint Kate Gregory help me :palm: :palm: :palm: :palm:
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19279
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: "Stop Teaching C" - Kate Gregory
« Reply #77 on: November 01, 2016, 12:46:16 pm »
(It's a shame that strings in the C++ sense are so ... incompatible with deep embedded systems.  And that's a bit strange; they worked OK in BASIC on far less powerful computers, didn't they?   There would be so many fewer problems in the Arduino world if their String types actually worked well.)
Well.. nothing stops you from creating your own string type.

That's the problem: many people have done just that, badly and incompatibly.

The same is true for anything to do with time and dates.
« Last Edit: November 01, 2016, 12:53:14 pm by tggzzz »
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
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19279
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: "Stop Teaching C" - Kate Gregory
« Reply #78 on: November 01, 2016, 12:52:15 pm »
We're getting away from the point of the video....

For beginners on their way to learning C++, getting them to learn C first is going to make it harder to get into C++, as you've already taught them to think the wrong way.

If you want to teach an object-oriented language, then loading them up with archaic and inappropriate techniques is just making their journey harder and absolutely confusing, especially when the tendancy for thinking in object concepts is how they have been naturally processing the world up to this point.

Yes, that was the point of the video and I wouldn't quibble with it.

But if your objective is to teach an OOP language without loading them up with archaic and inappropriate techniques, then C++ is completely the wrong endpoint! Use a modern language!

I would agree - but what is the criteria that specifies the endpoint?  If it is an academic exercise to teach OOP, then you may be right (I'm not familiar enough with what's on offer to comment any further).

I've been using C since 1981, Smalltalk since 1986, C++ since 1988, Objective-C since 1988, and Java since 1996. Plus quite a few other domain-specific languages :) The more radically different languages you know, the less likely you are to try to insert a screw with a hammer.

Quote
However, if it is to skill up someone going into a C++ environment, then there's no need to look any further.

Skilling someone up sufficiently that they can be safe and productive in C++ requires much more than a short course. Hells teeth, there's ample evidence even the "designers" don't fully understand their creation!
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
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #79 on: November 01, 2016, 01:00:49 pm »
there's ample evidence even the "designers"
don't fully understand their creation!

and ... the explanation given by their project manager is
because they haven't  (properly) used AADL, ain't it ?  :-DD
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #80 on: November 01, 2016, 01:04:53 pm »
p.s.
just for my curiosity, do you/your team use Stood for your own designs?
if yes, is it really helpful?
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #81 on: November 01, 2016, 02:37:38 pm »
Kate Gregory's Blog looks very interesting  :-+
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #82 on: November 01, 2016, 03:05:49 pm »
Kate says Yes on Lambdas in C++
and she promotes the use,
but I haven't yet understood if
I really like this C++11 feature  :-//
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: "Stop Teaching C" - Kate Gregory
« Reply #83 on: November 01, 2016, 03:09:59 pm »
based on a lexer and parser that is so stupid
it needs semicolons to figure out where a line ends

I don't agree, the problem is not the semicolon at the end of the line
the problem is the C grammar itself which allows silly constructs
it goes deeper than that.

have you ever wondered why there is a need for .h files ?

The c compiler had to run on a machine with very little memory. this was a shared user machine and as students they were only allocated a small amount of resources....
They designed the compiler as single pass. simply because anything else didn't fit and was too complex. Same goes for that stack/heap construct.
all the c compilers compile for this 'virutal model and then shoehorn the output on the target architecture. this is not optimal. memory is not laid out that way on all machines.

Take a look at header files. In 2016 that is the most stupid thing ever (when the language was create it was not !). As a human ,i have to declare the functions in the header file ,and then write the same construct once again in the real code section. Why do i need to forward declare functions ? i don;t know what the final format of those functions will be ! i have not designed them yet ! and i need to fix stuff in different files every time i make a modification to the function i/o.

Why can't the compiler just go over the source code once, collect all the functions , and then start compiling ? There is not even a need for  includes. simply go look in other files in the directory and see if you can find it there first. descend into subdirectories automatically. if files reside on a central server then you can point to them if needed.

The reason is historical . disk i/o was non exisitent ( the machine had TAPE for crying out loud... so you could not just randomly access files... ) and multipass meant eating lots of ram at compile time.. ram the machine did not have !

so we are stuck anno 2016 with a language and compilation method that was built for a long dead architecture with very limited resources.

C should evolve. Any language should evolve. compilers must be made multipass. I want to do away with all the overhead as a human. the less keyboard pounding i need to do the better. any character i type is a potential source of mistake. (speelling erroooors )

Now people will pitch in : use a good code editor with autocompletion blablabla.. that is not solving the problem, it is just a workaround ...
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: 443
  • Country: gb
Re: "Stop Teaching C" - Kate Gregory
« Reply #84 on: November 01, 2016, 03:29:38 pm »
.h files have a purpose past that. You stick your contract with the library or program in it. Then you implement it inside the .c.

Private/internal stuff just has to be higher up the .c file. I do believe this is modular programming or whatever it was called.
« Last Edit: November 01, 2016, 03:31:34 pm by setq »
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #85 on: November 01, 2016, 03:34:16 pm »
Take a look at header files. In 2016 that is the most stupid thing ever

they are useful to describe interfaces
in ada and pascal you have to do something similar
due to the separation before interface and implementation

modular design
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 2145
  • Country: fi
  • Embedded SW/HW.
Re: "Stop Teaching C" - Kate Gregory
« Reply #86 on: November 01, 2016, 03:34:36 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.
 

Offline John Coloccia

  • Super Contributor
  • ***
  • Posts: 1208
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #87 on: November 01, 2016, 03:36:21 pm »
Kate says Yes on Lambdas in C++
and she promotes the use,
but I haven't yet understood if
I really like this C++11 feature  :-//

Like everything else in C++, if you use it right it's convenient and powerful. Sometimes you have to generate a value, and it's more complex than a simple expression but you don't want to clutter up your code with generating it where it's just going to be used once and passed into a function. Here, the lambda function is useful. It's like a block of statements that returns a value.

It's also convenient to be able to pass a code snippet as data. So you can do things like give a function this snippet of code and say, "here, run this on all of your elements." Sure, you can do it other ways, but this particular way is very convenient and flexible.

Lambdas have been around for a LONG time. They just happen to be new to C++. I suspect that some C++ programmers out there have already figured out ways to abuse the hell out of Lambdas, but I think they're generally good things to have around.
« Last Edit: November 01, 2016, 03:41:05 pm by John Coloccia »
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: "Stop Teaching C" - Kate Gregory
« Reply #88 on: November 01, 2016, 03:51:14 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.
you would only need an include statement if some stuff resides outside the project directory. then you can point to it. (now people will com up with the excuse : so a function deep in a subdirectory would still need to declare outside . no it wouldn't as compilation does not start at the low level. it starts with the main file which resides at the highest level. the compiler traverses the entire directory tree from the root point of compilation.

all headers and includes would become obsolete. no more misery with function prototypes that mismatch the actual functions. no more cleaning up missing dots and semicolons and other keyboarding mistakes that prevent the program from compiling. i want to focus on developing the actual code as opposed to fixing typing mistakes.

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....

The c language has many constructs and limitations that stem from the resource cramped machine it was developed on.  think about this whole stream.io thing. data is only a stream ... if it comes from an ff-ing tape ! who uses tape these days ?

It should evolve. ( and im not talking c++ c# evolution , those are supersets to create object oriented stuff.  i'm talking compiler intelligence and eliminating stuff that does not make sense anymore on modern machines.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline John Coloccia

  • Super Contributor
  • ***
  • Posts: 1208
  • Country: us
Re: "Stop Teaching C" - Kate Gregory
« Reply #89 on: November 01, 2016, 04:01:34 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.
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #90 on: November 01, 2016, 04:04:09 pm »
if the compiler traverses all files in a directory
it will find the libraries. whether those exist
as .c files or as .obj . doesn't matter

yes, in the theory
but it's problem when you don't provide sources

imagine you have a library with a lot of .obj
you need their public interfaces

and here we go: you need them


for my own made compiler, I am also using them
to automatically build the dependency tree

I have removed the "#include" meta statement
instead I am using "use yyyy.dep.*;"

which includes the output from the dependencies tree

yyyy is the filename of the module

e.g. lib_stdio_v1 -> lib_stdio_v1.{ body, interface, dep }

body: implementation
interface: prototypes, types, global shared variables, alias (constant)
dep: dependencies with other modules

 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #91 on: November 01, 2016, 04:12:53 pm »
Code: [Select]
ls /idp.do/mysrc/lib/

Code: [Select]
lib_basen2_v3.h
lib_basen2_v3.interface
lib_basen2_v3.o
lib_bit_set_v1.h
lib_bit_set_v1.interface
lib_bit_set_v1.o
lib_bitmap_v2.h
lib_bitmap_v2.interface
lib_bitmap_v2.o
lib_bitmap_v3.h
lib_bitmap_v3.interface
lib_bitmap_v3.o
lib_cal_stamp.h
lib_cal_stamp.interface
lib_cal_stamp.o
lib_debug_v1.h
lib_debug_v1.interface
lib_debug_v1.o
lib_endian.h
lib_endian.interface
lib_endian.o
lib_env_collector_mini_v1.h
lib_env_collector_mini_v1.interface
lib_env_collector_mini_v1.o
lib_env_disk_io_v1.h
lib_env_disk_io_v1.interface
lib_env_disk_io_v1.o
lib_env_pool_label_v1.h
lib_env_pool_label_v1.interface
lib_env_pool_label_v1.o
lib_env_pool_string_v1.h
lib_env_pool_string_v1.interface
lib_env_pool_string_v1.o
lib_env_shell_cmd_v1.h
lib_env_shell_cmd_v1.interface
lib_env_shell_cmd_v1.o
lib_env_toy_v1.h
lib_env_toy_v1.interface
lib_env_toy_v1.o
lib_env_wrapper_v1.h
lib_env_wrapper_v1.interface
lib_env_wrapper_v1.o
lib_fileIO_unix_v1.h
lib_fileIO_unix_v1.interface
lib_fileIO_unix_v1.o
lib_file_utils.h
lib_file_utils.interface
lib_file_utils.o
lib_file_utils_v2.h
lib_file_utils_v2.interface
lib_file_utils_v2.o
lib_filename_filter_v0.3.h
lib_filename_filter_v0.3.interface
lib_filename_filter_v0.3.o
lib_filename_utils_v8.h
lib_filename_utils_v8.interface
lib_filename_utils_v8.o
lib_fs_folder_level.h
lib_fs_folder_level.interface
lib_fs_folder_level.o
lib_fs_folder_level_v2.h
lib_fs_folder_level_v2.interface
lib_fs_folder_level_v2.o
lib_lexer_reserved_word_language_l1_show_v7b.h
lib_lexer_reserved_word_language_l1_show_v7b.interface
lib_lexer_reserved_word_language_l1_show_v7b.o
lib_lexer_reserved_word_language_l1_v7b.h
lib_lexer_reserved_word_language_l1_v7b.interface
lib_lexer_reserved_word_language_l1_v7b.o
lib_lexer_reserved_word_v7b.h
lib_lexer_reserved_word_v7b.interface
lib_lexer_reserved_word_v7b.o
lib_lexer_tokenize_v7b.h
lib_lexer_tokenize_v7b.interface
lib_lexer_tokenize_v7b.o
lib_lexer_v7b.h
lib_lexer_v7b.interface
lib_lexer_v7b.o
lib_linea_v2.h
lib_linea_v2.interface
lib_linea_v2.o
lib_list_handler_v1.h
lib_list_handler_v1.interface
lib_list_handler_v1.o
lib_mystring_v0.7.h
lib_mystring_v0.7.interface
lib_mystring_v0.7.o
lib_mystring_v2.h
lib_mystring_v2.interface
lib_mystring_v2.o
lib_net_udp_ip_v1.h
lib_net_udp_ip_v1.interface
lib_net_udp_ip_v1.o
lib_pico_shell_slush_addon_v4.h
lib_pico_shell_slush_addon_v4.interface
lib_pico_shell_slush_addon_v4.o
lib_pico_shell_slush_v4.h
lib_pico_shell_slush_v4.interface
lib_pico_shell_slush_v4.o
lib_pico_shell_toy_v4.h
lib_pico_shell_toy_v4.interface
lib_pico_shell_toy_v4.o
lib_progress_bar.h
lib_progress_bar.interface
lib_progress_bar.o
lib_queue_gp_v3.h
lib_queue_gp_v3.interface
lib_queue_gp_v3.o
lib_safestring_v2.h
lib_safestring_v2.interface
lib_safestring_v2.o
lib_serial2.o
lib_serial_unix_v3.h
lib_serial_unix_v3.interface
lib_serial_unix_v3.o
lib_serial_unix_v4.h
lib_serial_unix_v4.interface
lib_serial_unix_v4.o
lib_string_fuzzy_match_v1.h
lib_string_fuzzy_match_v1.interface
lib_string_fuzzy_match_v1.o
lib_tokener_fast_v8.h
lib_tokener_fast_v8.interface
lib_tokener_fast_v8.o
lib_tokener_fast_v8b.h
lib_tokener_fast_v8b.interface
lib_tokener_fast_v8b.o
lib_tokener_fussy_v8.h
lib_tokener_fussy_v8.interface
lib_tokener_fussy_v8.o
lib_tokener_language_show_v1.h
lib_tokener_language_show_v1.interface
lib_tokener_language_show_v1.o
lib_tokener_language_v1.h
lib_tokener_language_v1.interface
lib_tokener_language_v1.o
lib_tokener_v8.h
lib_tokener_v8.interface
lib_tokener_v8.o
lib_uart_unix_v5.h
lib_uart_unix_v5.interface
lib_uart_unix_v5.o
lib_udpip.h
lib_udpip.interface
lib_udpip.o
lib_unix_termio_kb_v2.h
lib_unix_termio_kb_v2.interface
lib_unix_termio_kb_v2.o
lib_unix_termio_kb_v4.h
lib_unix_termio_kb_v4.interface
lib_unix_termio_kb_v4.o
types.h

dependencies are automatically built using { .h, .interface }
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 11535
  • Country: my
  • reassessing directives...
Re: "Stop Teaching C" - Kate Gregory
« Reply #92 on: November 01, 2016, 04:23:01 pm »
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.
how do you suggest a wise thing to practice encapsulation or intellectual anonymousity of functions in a library/object/module? above all, how do you suggest another language that solves this problem but... maintain capabilities and freedom experiences to users similar to C/C++?

Nature: Evolution and the Illusion of Randomness (Stephen L. Talbott): Its now indisputable that... organisms “expertise” contextualizes its genome, and its nonsense to say that these powers are under the control of the genome being contextualized - Barbara McClintock
 

Offline legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #93 on: November 01, 2016, 04:24:05 pm »
who uses tape these days ?

bad example, dude, I use tapes  :D

LTO-2-6 Ultrium technology
DLD-1-4 technology

both available for SCSI (obsolete) and SAS(modern)
usually for Unix big-iron servers and workstations

basically you are talking about DAT@SCSI.narrow.SE
and their predecessors, but I get your point
and I agree :D
 

Offline AG6QR

  • Frequent Contributor
  • **
  • Posts: 857
  • Country: us
    • AG6QR Blog
Re: "Stop Teaching C" - Kate Gregory
« Reply #94 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 legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #95 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: 443
  • Country: gb
Re: "Stop Teaching C" - Kate Gregory
« Reply #96 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 legacyTopic starter

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: "Stop Teaching C" - Kate Gregory
« Reply #97 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: 8515
  • Country: us
    • SiliconValleyGarage
Re: "Stop Teaching C" - Kate Gregory
« Reply #98 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: 443
  • Country: gb
Re: "Stop Teaching C" - Kate Gregory
« Reply #99 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:

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf