Go Down

Topic: Legitimate uses for pointers? (Read 14143 times) previous topic - next topic

econjack

Quote
I guess I still don't understand the benefit of using global variables and modifyColor(red, green, blue) over calling modifyColor three times, ...


Then you probably don't see the benefit of encapsulation. Suppose you define those colors as globals and, like I once worked on, you had a program with over 800,000 lines of source code. Suddenly, one of your globals go haywire. With globally-defined data, it's a lot more difficult to know where to start the degbugging process than if you had defined them with function scope and passed pointers to them when they need to be changed by a function call.

tylernt


Quote
I guess I still don't understand the benefit of using global variables and modifyColor(red, green, blue) over calling modifyColor three times, ...


Suddenly, one of your globals go haywire.
I think I meant to say, I think it's better to call modifyColor three times than to call it once with three arguments. I worded it poorly, sorry.

GoForSmoke

It'd probably be better to put the colors in an array in the first place and use an enum to name the indexes.

Just remember that there -are- pointers and when you're ready you will see the sense.

1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

cypherrage


...like I once worked on, you had a program with over 800,000 lines of source code...


Can you please elaborate on this?  I have a hard time picturing someone or even a group of people writing an 800k line piece of code. I'm not doubting you, I'm just curious what this was for.

AWOL

I think maybe that's a dual use of the word "program" - by some measures, taking "program" as meaning a program of work, 800klocs is quite a small project, compared to, say, even the OS in the phone in your pocket.

econjack

Quote
I have a hard time picturing someone or even a group of people writing an 800k line piece of code.


It was a statistics package, with everything from simple descriptive statistics to principal components analysis, and nonparametric tests, too. It was written at a time before relational databases were widely used so it also had its own data management subsystem.

GoForSmoke

800k lines might be counting a lot of library code by simply looking at the compiler output line count.

OTOH, some people just like to write (and copy-paste-modify) huge amounts of lines of "elegant" code instead of generalizing, consolidating and integrating data with code.

Program = code + data. Spend much time debugging and see how often the bug is in the data when there isn't enough error recognition in the routines.

1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

TanHadron

I love using pointers.  Back in the day, before C++, you had to use pointers sometimes because they were the only way to get some things done.  In fact, I think a lot of the enhancements in C++ and C# and such are an attempt to be able to do things without pointers.  What IS pass by reference, if not passing the pointer and using the address instead of the value whenever it is referenced?  It's really using a pointer, but now the compiler does it for you so you don't have to call it using a pointer.

But there are times when it's smaller, faster, and more elegant to use pointers.

So here's an example.  In C, here's the first way they taught us to do an insert into a linked list:

Code: [Select]

struct Node
{
  struct Node *link;
  int index;
};

struct Node *header = NIL;

void insertNode(struct Node *thisNode)
{
  struct Node *walker;
  struct Node *lastWalker;

  if (header == NIL || header->index > thisNode->index)
  {
    thisNode->link = header;
    header = thisNode;
  }
  else
  {
    for (walker = header; walker != NIL; walker = walker->link)
    {
      if (walker->index > thisNode->index)
      {
        thisNode->link = walker;
        lastWalker->link = walker;
        break;
      }
      lastWalker = walker;
    }
    if (walker == NIL)
    {
      thisNode->link = walker;
      lastWalker->link = thisNode;
    }
  }
}


Most of the code is special cases.  Empty list,  first in the list, last in the list.

Here's how you can do it with pointer pointers:
Code: [Select]

void insertNode(struct Node *thisNode)
{
  struct Node **walker;

  for (walker = &header;; walker = &(walker->link))
  {
      if ((*walker) == NIL || (*walker)->index > thisNode->index)
      {
        thisNode->link = *walker;
        *walker = thisNode;
        break;
      }
  }
}


The special cases take care of themselves.

The other thing I really like about pointers is the inherent ability to change data types.  I really got frustrated with C# when I was writing a program to read data in from a file.  The data was read into a byte array.  Then I wanted to use the data as two-byte words.  In C, all I have to do is typecast the array as an array of words, and I'm good to go.  In C#, I couldn't figure out a way to do that.  I had to declare another array of two byte words, and the compiler copied the data to the new array for me.  It was spectacularly easy, and I guess that is why we use C#.  And there was no way it was going to let me mess up and use the wrong data type.  But it was also spectacularly big and spectacularly slow.  Nobody much cares about big slow programs any more.

Unless you're programming microcontrollers.

Yeah.  I love pointers.

radman

'C', with its structures and pointers, enabled you to program in a way that was not a million miles from Object Oriented Programming before languages based on objects became available.

PeterH



...like I once worked on, you had a program with over 800,000 lines of source code...


Can you please elaborate on this?  I have a hard time picturing someone or even a group of people writing an 800k line piece of code. I'm not doubting you, I'm just curious what this was for.


800K lines is not particularly big in commercial software terms. Of course it's not one file of 800K lines - a project that size will comprise thousands of much smaller files.

GoForSmoke


'C', with its structures and pointers, enabled you to program in a way that was not a million miles from Object Oriented Programming before languages based on objects became available.


I was doing OOP on a VIC-20 with Forth79 in 1983. Find a copy of "Starting Forth" or write Forth using builds-does (or create-does in some versions).

What is the language from around 1985 that has "tuples"? What little I had read about that seemed to have encapsulation at least.

1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

cypherrage



'C', with its structures and pointers, enabled you to program in a way that was not a million miles from Object Oriented Programming before languages based on objects became available.


I was doing OOP on a VIC-20 with Forth79 in 1983. Find a copy of "Starting Forth" or write Forth using builds-does (or create-does in some versions).

What is the language from around 1985 that has "tuples"? What little I had read about that seemed to have encapsulation at least.




I would think Python, but I don't think Python was around until the 90's.


radman

Quote
What is the language from around 1985 that has "tuples"?

Smalltalk was Object Oriented, had "tuples" and come into use around 1985.

That was a good while after 'C' though.
I still have a pre 1980 copy of Kernigan and Ritchie describing 'C', it is well thumbed and held together by sellotape browned and cracking with age.
'C' was well ahead of its time and very versatile.

Go Up