[SOLVED] C - why pointers?

rtmistler · 11-06-2014, 12:17 PM

Had a colleague who used to always comment that all of programming really boils down to read/modify/test/branch. And that's pretty much correct. The higher languages have methods which are very well tested and the compilers or interpreters further qualify things, check scope, and provide exception processing. In the end, that's just more assembly code and more complexities leading to the same intended result. Not saying that's bad, but I do feel it depends on the use you're applying it for and the OS environment (if any) under which you're running.

That's another thing which has been noted. The assembly instructions rely a great deal on addressing, because you have a finite amount of registers, and further, you desire efficiency in your operating code; therefore the compilers are designed to make use of existing data rather than alter a register every instruction.

szboardstretcher · 11-06-2014, 12:19 PM

Quote:

Originally Posted by rtmistler

all of programming really boils down to read/modify/test/branch

Interesting thought. Can you provide a basic code snippet related to this outline?

rtmistler · 11-06-2014, 12:26 PM

Quote:

Originally Posted by szboardstretcher

Interesting thought. Can you provide a basic code snippet related to this outline?

Original code:

Code:

#include <string.h>

void main(void)
{
    char a[8], b[8];

    memcpy(a, "18675309", 8);

    memcpy(b, a, 8);
}

Bold/Red highlights of a few examples, but there are plenty throughout:

Code:

GAS LISTING /tmp/ccpS2bjq.s 			page 1


   1              		.file	"main.c"
   2              		.text
   3              	.Ltext0:
   4              		.globl	main
   6              	main:
   7              	.LFB0:
   8              		.file 1 "main.c"
   1:main.c        **** #include <string.h>
   2:main.c        **** 
   3:main.c        **** void main(void)
   4:main.c        **** {
   9              		.loc 1 4 0
  10              		.cfi_startproc
  11 0000 55       		pushl	%ebp
  12              	.LCFI0:
  13              		.cfi_def_cfa_offset 8
  14              		.cfi_offset 5, -8
  15 0001 89E5     		movl	%esp, %ebp
  16              	.LCFI1:
  17              		.cfi_def_cfa_register 5
  18 0003 83E4F0   		andl	$-16, %esp
  19 0006 83EC20   		subl	$32, %esp
  20              		.loc 1 4 0
  21 0009 65A11400 		movl	%gs:20, %eax
  21      0000
  22 000f 8944241C 		movl	%eax, 28(%esp)
  23 0013 31C0     		xorl	%eax, %eax
   5:main.c        ****     char a[8], b[8];
   6:main.c        **** 
   7:main.c        ****     memcpy(a, "18675309", 8);
  24              		.loc 1 7 0
  25 0015 C744240C 		movl	$926300209, 12(%esp)
  25      31383637 
  26 001d C7442410 		movl	$959460149, 16(%esp)
  26      35333039 
   8:main.c        **** 
   9:main.c        ****     memcpy(b, a, 8);
  27              		.loc 1 9 0
  28 0025 8D44240C 		leal	12(%esp), %eax
  29 0029 8B5004   		movl	4(%eax), %edx
  30 002c 8B00     		movl	(%eax), %eax
  31 002e 89442414 		movl	%eax, 20(%esp)
  32 0032 89542418 		movl	%edx, 24(%esp)
  10:main.c        **** }
  33              		.loc 1 10 0
  34 0036 8B44241C 		movl	28(%esp), %eax
  35 003a 65330514 		xorl	%gs:20, %eax
  35      000000
  36 0041 7405     		je	.L2
  37 0043 E8FCFFFF 		call	__stack_chk_fail
  37      FF
  38              	.L2:
  39 0048 C9       		leave
  40              		.cfi_restore 5
  41              	.LCFI2:
  42              		.cfi_def_cfa 4, 4
  43 0049 C3       		ret
GAS LISTING /tmp/ccpS2bjq.s 			page 2


  44              		.cfi_endproc
  45              	.LFE0:
  47              	.Letext0:
GAS LISTING /tmp/ccpS2bjq.s 			page 3


DEFINED SYMBOLS
                            *ABS*:0000000000000000 main.c
     /tmp/ccpS2bjq.s:6      .text:0000000000000000 main

UNDEFINED SYMBOLS
__stack_chk_fail

metaschima · 11-06-2014, 12:28 PM

Quote:

Originally Posted by NevemTeve

High-level languages hide the pointers from you, but the pointers are still there.

Yeah, they hide them either completely or most of the functionality. With C you have all the power, and all the responsibility.

mina86 · 11-06-2014, 04:58 PM

If languages didn't try to hide pointers so much, no one would be confused about why int is passed by value but java.lang.Integer by reference. If one simply realises that “int foo;” declares an integer and “java.lang.Integer foo;” declares a pointer to java.lang.Integer instance, all confusion is gone. To Java defence they call it a reference, but still the “there are no pointers” mindset seems to create more confusion than it's worth. This is why I find tying concept of pointers to “low level” counter-productive.

Quote:

Originally Posted by szboardstretcher

Interesting thought. Can you provide a basic code snippet related to this outline?

For theory, read up on Turing machine.

metaschima · 11-06-2014, 05:08 PM

Quote:

Originally Posted by mina86

If languages didn't try to hide pointers so much, no one would be confused about why int is passed by value but java.lang.Integer by reference. If one simply realises that “int foo;” declares an integer and “java.lang.Integer foo;” declares a pointer to java.lang.Integer instance, all confusion is gone. To Java defence they call it a reference, but still the “there are no pointers” mindset seems to create more confusion than it's worth. This is why I find tying concept of pointers to “low level” counter-productive.

Well, that's a detail I did not know about, I'm not much into Java.

psionl0 · 11-06-2014, 11:37 PM

Quote:

Originally Posted by rtmistler

Obviously for the stack this is important. If you have a structure, array, or string which is large, you don't pass a copy of that structure through your call stack, you instead pass the address of it. This therefore reduces the stack size requirements.

This is not as big an issue as it was in the early days of C programming when stack space was usually limited. In fact, early versions of C did not permit the passing of structures and arrays as parameters; you had to use pointers instead.

Time is more the limiting factor now. It takes time to copy large chunks of data to the stack space and the use of pointers can save that time.

a4z · 11-07-2014, 02:09 AM

Quote:

Originally Posted by mina86

If languages didn't try to hide pointers so much, no one would be confused about why int is passed by value but java.lang.Integer by reference. If one simply realises that “int foo;” declares an integer and “java.lang.Integer foo;” declares a pointer to java.lang.Integer instance, all confusion is gone. To Java defence they call it a reference, but still the “there are no pointers” mindset seems to create more confusion than it's worth. This is why I find tying concept of pointers to “low level” counter-productive.

For theory, read up on Turing machine.

very true,
Sun has spent millions $ to convince every one that Java is the way to go and that students should not be irritated with low level stuff and they made a huge marketing camping using the absurdest arguments why people should not use C and C++.
the outcome of this can be seen today

sag47 · 11-07-2014, 03:22 AM

Pointers can also be used as a hack to return multiple data types or multiple values as a result of a void function.

rtmistler · 11-07-2014, 06:26 AM

Quote:

Originally Posted by psionl0

This is not as big an issue as it was in the early days of C programming when stack space was usually limited. In fact, early versions of C did not permit the passing of structures and arrays as parameters; you had to use pointers instead.

Time is more the limiting factor now. It takes time to copy large chunks of data to the stack space and the use of pointers can save that time.

Depends what you're programming on. An embedded microcontroller does not have unlimited resources.

sundialsvcs · 11-07-2014, 07:04 AM

And you've also got to bear in mind where these languages started from. It all started with binary switches; then it evolved to punched paper tape and cards, upon which binary instructions were punched by hand to fill the few-hundred bytes of memory that machines of that time contained. Time marched on, and the first "compilers" were written, thus proving to their detractors that machine instructions could be generated using ... machine instructions.

"C" was literally an extension of assembly, and it was the first tool used to write a complete operating system (Unix, pun intended), for a cast-off machine in a laboratory, at a time when MULTICS was getting all the dough, credibility and $attention$. (At the time, no one believed that an operating system could be written at all in a high-level language.)

Languages since that time have worked to make source-code easier to write: to push more of the responsibility, both for code generation and for error-detection, onto the compiler/interpreter. (And, in a parallel path occupied e.g. by LISP and Prolog, to make certain classes of problems easier to address.) "C" remains as "the language that most of those other systems were written in." It's a linchpin of the reason why Linux et al are transportable to so many different platforms.

Although you might not wish to write new code in "C," you could spend the rest of your career maintaining a portion of the vital code that has been written using it. (Such as, say, Linux ...)

johnsfine · 11-07-2014, 07:51 AM

Quote:

Originally Posted by sundialsvcs

"C" was literally an extension of assembly, and it was the first tool used to write a complete operating system (Unix, pun intended), for a cast-off machine in a laboratory, at a time when MULTICS was getting all the dough, credibility and $attention$. (At the time, no one believed that an operating system could be written at all in a high-level language.)

Your last phrase makes little sense in context. Most of ITS was written in B and the designers of MULTICS were quite familiar with ITS. B was lower level than C, but still quite a bit above assembler.

MULTICS was written in a higher level language than C and that was always its plan. It was funded and started long before UNIX (though arguably MULTICS didn't reach a "working" level until after UNIX). If no one believed an OS could be written in a high level language, why was MULTICS funded?