C/C++ Programming Questions Not Worth Their Own Thread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread

«‹›640 »

Acer Pilot: Feb 17, 2007; put the 'the' in therapist

Suspicious Dish posted:

You do know what SQL is, right?

Yes, I'm doing it to group multiple indexes into a hash rather than doing a large set of subqueries.. We're using a WHERE IN and need a way to look up multiple indexes for a large set of values in a single query.

# ? May 20, 2012 03:50

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 20:14

shrughes: Oct 11, 2008; (call/cc call/cc)

Concatenate the three values with semicolons in between. Make sure the floating point value is serialized consistently.

# ? May 20, 2012 04:20

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Haywood Japwnme posted:

Yes, I'm doing it to group multiple indexes into a hash rather than doing a large set of subqueries.

And you thought you needed a hash? A cryptographic hash, even? This is an example of the XY problem in action, here. The database will hash values for you. You don't need to. Create a single easily generated value, and use that.

# ? May 20, 2012 04:41

Acer Pilot: Feb 17, 2007; put the 'the' in therapist

Suspicious Dish posted:

And you thought you needed a hash? A cryptographic hash, even? This is an example of the XY problem in action, here. The database will hash values for you. You don't need to. Create a single easily generated value, and use that.

Ahh, ok. Thanks everyone.

# ? May 20, 2012 04:53

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

I mean, just to be clear, you do need to set up an index on the column.

Ideally, you wouldn't need a separate column that concatenates three others; you should be able to just set up a compound index or configure those rows as a compound key, which has the same effect but doesn't bloat your rows. But you need to grok your database a bit better to understand that, and doing the concatenated column works well enough.

# ? May 20, 2012 06:57

Max Facetime: Apr 18, 2009

Also don't use floats or doubles when handling or storing monetary values. Might be too late for you, but just putting it out there.

# ? May 23, 2012 11:01

Dawncloack: Nov 26, 2007; ECKS DEE!; Nap Ghost

Final edit: Sorry for having erased it, I'll put it up again for others to see and hopefully learn

I'm a beginner programmer and I have a problem.
I've written this little function. The point of it is to create a counter useful for combinatorial mathematics. I want to sum the values of 7 variables, then advance one of the variables by one step, then sum it again. And since 100 and 010 is exactly the same to my purposes, I'd thought I'd save time time by this small function.

code:

void AlgoPermu (short *a)
    {
    int i = 0;
    for (i=0 ; i<7; i++)
        {
        if (*a > 7)
            {
            AlgoPermu *(a+1); <----- Here is the problem
            }
    *(a+1) = *a + 1;
        }
    }

The problem is that I keep getting the same error

knapalgo.h|11|error: invalid operands to binary * (have 'void (*)(short int *)' and 'short int *')|

Which bothers me a lot, since I managed to make it work some days ago. I might have changed a small detail or two from the moment I made it work, though. I shouldn't have tried to organize my files drunk that night.

When I try to express the recursive function call in a different way, just to try (taking out the asterisc, putting it inside the parenthesis, which, as far as I know, shouldn't work, but eh), it compiles but then produces an error.

What am I doing wrong?

Also, feel free to make fun of my ignorance.

VVVV Crap. Sorry, Tuna. Nielsm: I allocated memory and I have prevented the loop from running forever with a do/while. And yeah, except through recursion, it only modifies two elements. And I did what you told me to. Thanks to both.

Dawncloack fucked around with this message at 18:16 on May 27, 2012

# ? May 27, 2012 17:35

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Edit: fine, I'll delete my response too then. Hopefully you don't edit a question back in now so that my removal of a response doesn't make sense either!

roomforthetuna fucked around with this message at 17:57 on May 27, 2012

# ? May 27, 2012 17:52

nielsm: Jun 1, 2009

^^^

You probably mean one of the following:

C code:

AlgoPermu(*(a+1));
AlgoPermu((*a)+1);
AlgoPermu(a+1);

There must always be parentheses around the complete parameter list to a function call.
The two first won't compile either, though. The function takes a pointer to a short and assumes there are 7 short values from that location. The two first would pass a short value to the function, and not a pointer to a short.

But how much memory is there actually at the location a points to? As it is, this function could recurse potentially infinitely and try to access still further data, there is no protection against running over the end of the array.

Every iteration of the loop also does the same. Checks the value of the first element of the array, possibly recurses, then changes the second element of the array passed in to the value of the first element incremented by one. You never do anything with other elements than the first two of the array, except through recursion.

# ? May 27, 2012 17:59

Harold Ramis Drugs: Dec 6, 2010; by Y Kant Ozma Post

I'm having some trouble getting a method to delete a singly-linked list in c, and I also can't figure out how to debug a method like this that is included in a header file and compiled together using a makefile.

The header file for my liked list looks like this:

code:

#ifndef LINKLIST_H
#define LINKLIST_H

typedef char DATA;

typedef struct node{
  DATA data;
  struct node *next;  
} node;

void addFirst(int item);
void printList();
void clearList();

#endif

and the clearList method looks like this:

code:

#include <stdio.h>
#include <stdlib.h>
#include "linklist.h"

extern node *head;

void clearList(){
  node *curr = head;
  if(curr->next){
    clearList(curr->next);
    free(curr->next);
  }
  free(curr);

}//end clearList

I didn't include the methods for addFirst and printList, because those don't seem to be problematic at all. I'm getting a segmentation fault, and when I run GDB it seems like it's the result of a never-ending recursion loop.

Secondly, I'm not sure how to debug this all for memory leaks. I am compiling this file along with a header, other methods, and a tester file using a makefile. Is there a way to run the compiled makefile through valgrind, or do I have to rewrite it to account for potential memory leaks? Here's the code for the makefile just in case:

code:

all:	        addFirst.o clearList.o linked_list_test.o printList.o
			gcc -g -pedantic -o link_list_test addFirst.o clearList.o linked_list_test.o printList.o
addFirst.o:	addFirst.c linklist.h
				gcc -g -pedantic -c addFirst.c
clearList.o:	clearList.c linklist.h
				gcc -g -pedantic -c clearList.c
linked_list_test.o:	linked_list_test.c linklist.h
				gcc -g -pedantic -c linked_list_test.c
printList.o:	printList.c linklist.h
				gcc -g -pedantic -c printList.c
clean:
	rm link_list_test addFirst.o clearList.o linked_list_test.o printList.o

# ? May 29, 2012 00:01

nielsm: Jun 1, 2009

Harold Ramis Drugs posted:

the clearList method looks like this:
code:
#include <stdio.h>
#include <stdlib.h>
#include "linklist.h"

extern node *head;

void clearList(){
  node *curr = head;
  if(curr->next){
    clearList(curr->next);
    free(curr->next);
  }
  free(curr);

}//end clearList
it seems like it's the result of a never-ending recursion loop.

You declare the function as taking zero parameters. (Or rather, declare it as taking unknown parameters, assuming this is C and not C++.) You never use any parameters in it, it always works on the global head of list.
You then call it with one parameter, expecting it to work on that.

# ? May 29, 2012 00:06

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Harold Ramis Drugs posted:

code:

#include <stdio.h>
#include <stdlib.h>
#include "linklist.h"

extern node *head;

void clearList(){
  node *curr = head;
  if(curr->next){
    clearList(curr->next);
    free(curr->next);
  }
  free(curr);

}//end clearList

That never should have compiled. You're trying to pass a parameter to a method that doesn't take one. Add -Wall -Werror to your command line flags. For extra ensurance:

C code:

void clearList(void) {

Anyway, after you fix the method so that it takes a parameter instead of assuming that the head is always correct (which you never update), you're freeing each node twice, which will result in glibc spewing a double free error. It won't be a segfault though.

As for testing, you need to compile with debug info (-g -O3), and then just running memcheck on the compiled program should be enough.

# ? May 29, 2012 00:07

Harold Ramis Drugs: Dec 6, 2010; by Y Kant Ozma Post

Ok, I've decided against doing this recursively. Now I'm stuck with this method giving me a memory leak or a seg fault (fixing one seems to guarantee the other). Here's the clearList method:

code:

#include <stdio.h>
#include <stdlib.h>
#include "linklist.h"

extern node *head;

void clearList()
{
  node *curr = head;
  
  while(curr)
  {
  free(curr);
  curr = curr->next;
  }
  
  head = NULL;
  free(head);
  free(curr->next);
}

From debugging it, the seg fault happens on that last line of code "free(curr->next)". When I delete that line however, I can detect a memory leak using valgrind that's as many blocks long as the linked list itself. Here's the code for the original structure, from a header file:

code:

#ifndef LINKLIST_H
#define LINKLIST_H

typedef char DATA;

typedef struct node{
    DATA d;
    struct node *next;
} node;

void printList();
void addOrdered(int newb);
void addFirst(int newb);
void clearList();
void removeItem(int newb);

#endif

# ? May 29, 2012 02:22

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

Try thinking through the problem instead of just going on what valgrind tells you.

Firstly, you have a use-after-free problem here:

C code:

free(curr);
curr = curr->next;

Secondly, what do you expect this to do?:

C code:

head = NULL;
free(head);

# ? May 29, 2012 02:34

Harold Ramis Drugs: Dec 6, 2010; by Y Kant Ozma Post

To be frank, I'm honestly not sure why that code above fixes the memory leaks. I was experimenting for a while earlier with code that followed this general pattern:

code:

void clearList()
{
  node *curr = head, *temp;
  
  while(curr->next)
  {
  temp = curr->next;
  free(curr);
  curr = temp;
  }
  free(curr);
  free(head);
  free(temp);
}

This seems like it should work, but there is a memory leak for each item on the linked list with this code. I'm really at a loss as to why the code from my previous post fixes the memory leaks, but the above code does not.

Edit: I'll GDB it to make sure, but it seems like curr and temp should both be the last node on the list, and head should be the original list's head

Harold Ramis Drugs fucked around with this message at 02:53 on May 29, 2012

# ? May 29, 2012 02:39

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Walk through the code in your head. Near the end, what are the values of curr, head, and temp?

# ? May 29, 2012 02:49

Harold Ramis Drugs: Dec 6, 2010; by Y Kant Ozma Post

I checked it with gdb. Before the last 3 free statements are executed:

curr == last number on list
temp == last number on list
head == a number that wasn't on the original list

After the free statements are executed:

curr == a number that wasn't on the original list (different from above)
temp == same as curr
head == a number that wasn't on the original list (different from original and above)

This might be a related problem, but when I try printing the list after running clearList, it's full of numbers that weren't on the original list.

# ? May 29, 2012 03:13

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

Now, which of those are things that have already been freed when you go to call free on them?

# ? May 29, 2012 03:15

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Harold Ramis Drugs posted:

I checked it with gdb.

gdb is not your head. Try again.

# ? May 29, 2012 03:27

tractor fanatic: Sep 9, 2005; Pillbug

Harold Ramis Drugs posted:

This might be a related problem, but when I try printing the list after running clearList, it's full of numbers that weren't on the original list.

Umm, what do you think clearList and free are supposed to be doing?

# ? May 29, 2012 03:39

Harold Ramis Drugs: Dec 6, 2010; by Y Kant Ozma Post

I was debugging it and checking the values line by line, and I'm not sure if the free calls are working correctly. I coppied the following over from gdb:

code:

14	  free(curr);
(gdb) print *curr
$2 = {d = 10 '\n', next = 0x804b088}
(gdb) next
15	  curr = temp;
(gdb) print *curr
$3 = {d = 96 '`', next = 0x804b088}

I don't know why it prints the value of curr as 96 in the last line. It shouldn't be able to access that number if it's been freed. This leads me to believe that I might not be freeing the node pointers correctly with just the free statement. Could this be due to an error in my header file, or during the original allocation of memory for each node? I use the following code for each:

Header File

code:

#ifndef LINKLIST_H
#define LINKLIST_H

typedef char DATA;

typedef struct node{
    DATA d;
    struct node *next;
} node;

void printList();
void addOrdered(int newb);
void addFirst(int newb);
void clearList();
void removeItem(int newb);

#endif

and I allocate memory for nodes using:

code:

curr = malloc(sizeof(node));

Should I be freeing the char and the node pointer with each node before I free the node itself?

# ? May 29, 2012 03:39

pseudorandom name: May 6, 2007

The pointer still points to the same block of memory after you pass it to free(), and there's an extremely good chance that the allocator won't touch that memory block at all when you free it.

This means that the contents of that memory can still be accessed through that pointer and will appear to be valid until the allocator reuses that chunk of memory for another call to malloc() or unmaps that page entirely.

pseudorandom name fucked around with this message at 04:01 on May 29, 2012

# ? May 29, 2012 03:58

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Harold Ramis Drugs posted:

I don't know why it prints the value of curr as 96 in the last line. It shouldn't be able to access that number if it's been freed. This leads me to believe that I might not be freeing the node pointers correctly with just the free statement. Could this be due to an error in my header file, or during the original allocation of memory for each node? I use the following code for each:

You haven't freed it yet. It's now the next element in the linked list. Seriously, stop fiddling around with gdb and go over it in your head. Use pencil and paper if necessary. Draw some diagrams:

pre:

        ,---------.   ,---------.   ,---------.
head ---> node    |   | node    |   | node    |
        | data  1 |   | data  2 |   | data  3 |
        | next -------> next -------> next -------> NULL
        `---------'   `---------'   `---------'

Now walk over it on paper, executing each statement. Record what you think it should do. Post your observations here.

# ? May 29, 2012 04:07

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

Seriously, pen-and-paper are your best friend when working out this sort of thing. Computers are stupidly, idiotically dumb, they'll do exactly what you tell them to even when it doesn't make sense and they don't even tell you that you're asking for something meaningless.

Go over it on paper and then you'll be able to see exactly where your code is doing something not quite right.

# ? May 29, 2012 04:12

Harold Ramis Drugs: Dec 6, 2010; by Y Kant Ozma Post

Suspicious Dish posted:

You haven't freed it yet.

As far as I can possibly tell, I have. All the outside sources I've checked lead me to believe that if you use free() on a structure, it frees all the data within the structure.

Suspicious Dish posted:

It's now the next element in the linked list.

The free() statement happens in the code before the pointer advances to the next element, shown here:

code:

void clearList()
{
  node *curr = head, *temp;
  
  while(curr->next)
  {
  temp = curr->next; //saves a pointer to the next element
  free(curr); //should be freeing all data associated with the current node
  curr = temp; //advances to next element
  }
  free(curr);
}

I can write data structures for java in my sleep. Linked Lists are some of my favorite programs to write. The only thing I can think of that's screwing this up is that I just don't understand the syntax of the free() statement, or that I'm not properly freeing the pointer to the next node.

Suspicious Dish posted:

You freed curr, advanced it to the next list node, and then printed it. It hasn't been freed yet.

The next value in the list is not 96, so I know something fishy is happening here.

Harold Ramis Drugs fucked around with this message at 05:23 on May 29, 2012

# ? May 29, 2012 05:14

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Harold Ramis Drugs posted:

I was debugging it and checking the values line by line, and I'm not sure if the free calls are working correctly. I coppied the following over from gdb:
code:
14	  free(curr);
(gdb) print *curr
$2 = {d = 10 '\n', next = 0x804b088}
(gdb) next
15	  curr = temp;
(gdb) print *curr
$3 = {d = 96 '`', next = 0x804b088}
I don't know why it prints the value of curr as 96 in the last line.

You freed curr, advanced it to the next list node, and then printed it. It hasn't been freed yet.

# ? May 29, 2012 05:17

Harold Ramis Drugs: Dec 6, 2010; by Y Kant Ozma Post

Eureka, I think I found something that works:

code:

extern node *head;

void clearList()
{
  node *curr = head, *temp;
  
  while(curr)
  {
    temp = curr->next;
    free(curr);
    curr = temp;
  }
  head = NULL;
}

There's no memory leaks, and it doesn't print crazy values when I try to print a cleared list. Literally, the only addition was that last line of code where I set the head to null, and that seems to fix all my problems. Thanks for helping, I'll probably be stuck again soon.

# ? May 29, 2012 05:58

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

free() returns memory to the heap manager so that it can reuse that memory the next time you malloc something. It doesn't (necessarily) release that memory to the operating system.

Remember that pointers in C are not like references in Java. There's no runtime that checks every pointer access to make sure it makes sense. If you deference a bogus pointer, anything can happen. It might segfault. It might not! It doesn't matter whether it does or not, because you shouldn't be doing that in the first place.

# ? May 29, 2012 05:58

Dawncloack: Nov 26, 2007; ECKS DEE!; Nap Ghost

Hi! I am back with more silly C doubts

code:

void CombiFunc(short *a)
{
*a = *a + 1;
if (*a > 6)
    {
    CombiFunc(a + 1);
    *a = *(a+1);
    }
}

This function is fed to an array of 7 short integers. The function is called for by an do...while that stops as soon as the last number of the array changes from 0.

This is what I want it to do
000000
100000
200000
...
600000
110000

It's for combinatorial maths, so, for me, 100 and 010 is the same, I want the function to do 110 to save on processing time.

I have several problems.

1. It works... kinda. The function does this:
it reaches 600000
And then goes to 200000.
200000
300000
...
600000
then
300000.

After the next cycle, it goes back to 400000 etcetc.

And only when it reaches 600000 for the sixth time, it jumps to 110000.

How can I have it not do that? I've examined the code thousands of times and I'm out of ideas.

2. If at the start of the function I write void "CombiFunc(short **a)" (note the double asterisk) the function does exactly what I want it to... but each step is 2 and not one. I guess that's because of the length in bytes of a short int? I know nothing of double asterisks, so feel free to enlighten me. Or to tell me that it's long to explain, I don't expect easy or quick answers

3. It used to work right, then started working wrong, and I'm sure I didn't change anything.

Are compilers/code/CodeBlocks so temperamental, or (and I think this is the right answer) am I not respecting some convention or practice?

Thanks

# ? Jun 1, 2012 13:51

nielsm: Jun 1, 2009

Let me just be sure, if you instead of having 7 digits going from 0 to 6 instead had 3 digits going from 0 to 2, the complete set of combinations you want would be this, right?

000
001
002
011
012
022
111
112
122
222

The way I wrote this series has a very simple pattern: A digit never has a lower value than any digit preceding it.

I think you're trying to be too smart writing that function for your own good, try doing something simpler where you don't do all the pointer maths, recursing on partial arrays and all that.
I'm cooking something, but my brain isn't functioning completely at this moment.

(Edit: What I mean to suggest is, when you're recursively generating a sequence of combinations, you're in effect traversing a tree of combinations. You seem to be attempting to traverse it breadth-first, but depth-first traversal is more natural for recursive generation.)

Edit 2: This program seems to work for me:

C++ code:

#include <stdio.h>

typedef void (*ConsumerFunc)(int*);

void SampleConsumer(int *a)
{
  printf("%d %d %d %d %d %d %d\n", a[0], a[1], a[2], a[3], a[4], a[5], a[6]);
}


static void GeneratorHelper(ConsumerFunc callback, int *a, int pos, int maxval)
{
  int i;

  if (pos >= 7)
  {
    /* on the leaves of the recursion tree, call the consumer */
    callback(a);
  }
  else
  {
    /* otherwise produce combinations */
    for (i = maxval; i < 7; ++i)
    {
      a[pos] = i;
      GeneratorHelper(callback, a, pos+1, i);
    }
  }
}

void GenerateCombinations(ConsumerFunc callback)
{
  int array[7] = {0};
  GeneratorHelper(callback, array, 0, 0);
}


int main()
{
  GenerateCombinations(SampleConsumer);
}

Notes:
- I'm using the int type instead of short, there isn't any reason to use short here, the amount of memory saved is trivial. (Besides, for saving memory, the char type would be more meaningful, since the range 0..6 still fits in that.)
- This uses a callback design so you can feed the output of the combinator into different functions.

nielsm fucked around with this message at 18:39 on Jun 1, 2012

# ? Jun 1, 2012 18:17

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

If I had to guess, I'd say that your printing function is just wrong; what you're describing is consistent with somehow striding over your array in four-byte chunks, but only printing out a two-byte chunk, in a way that happens to work with your machine endianness. That's not normally an easy mistake to make, but I'm going to guess that you're being "cleverer" than the average beginning programmer.

But the function you've posted looks fine.

And yes, moving to short**s means that incrementing the value actually increases it by sizeof(short) and means that your printing function actually strides over the array correctly. It does technically mean that incrementing it from zero is undefined behavior, as is printing it with the wrong format.

# ? Jun 1, 2012 18:41

Paul MaudDib: May 3, 2006; TEAM NVIDIA:
FORUM POLICE

C question:

I'm making a simple root/linked-list setup. The idea is that I have an array of roots for input, and the program moves the members of the list to an output root as determined by the code. However, I am also using pointers to the array, so that I can simply swap the input/output pointers for multiple iterations of the algorithm. The actual roots are stored in roots_a[num_roots] and roots_b[num_roots].

First question: According to cdecl, the pointers are instantiated like this. This seems backwards, that looks like an array of pointers to roots, what I want is a pointer to an array of roots.

root (*input_roots[num_roots];
root (*output_roots)[num_roots];

Next problem, what is the correct way to access the members via the pointer? Common sense would suggest this is the correct way to do that:

linknode *next_node = (*input_roots)[i].start;

Where i is an iterator, and .start is a *linknode. I would mentally parse this as "dereference a pointer to an array, index from there, access the pointer-member".

However, I suspect I'm doing it wrong, and this is beyond my understanding of cdecl syntax to explain. The reason I suspect that I'm doing it wrong is my debug code shows the proper number of members on the roots before an iteration, and immediately after they've all disappeared. I use the same insert algorithm, except that the initial setup code directly accesses root arrays, skipping the pointer

Paul MaudDib fucked around with this message at 04:58 on Jun 2, 2012

# ? Jun 2, 2012 04:54

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Paul MaudDib posted:

C question:

I'm making a simple root/linked-list setup. The idea is that I have an array of roots for input, and the program moves the members of the list to an output root as determined by the code. However, I am also using pointers to the array, so that I can simply swap the input/output pointers for multiple iterations of the algorithm. The actual roots are stored in roots_a[num_roots] and roots_b[num_roots].

First question: According to cdecl, the pointers are instantiated like this. This seems backwards, that looks like an array of pointers to roots, what I want is a pointer to an array of roots.

root **input_roots;

Pointers are arrays.

Paul MaudDib posted:

Next problem, what is the correct way to access the members via the pointer? Common sense would suggest this is the correct way to do that:

linknode *next_node = (*input_roots)[i].start;

Where i is an iterator

A what? Is this C, or C++? Do you mean an index? If so, that looks fine, assuming the start field is a linknode *.

Anyway, your explanation is a bit strange. Pasting some basic code that shows the problem would help a ton.

# ? Jun 2, 2012 05:26

floWenoL: Oct 23, 2002

Suspicious Dish posted:

root **input_roots;

Pointers are arrays.

No, they're not.

# ? Jun 2, 2012 06:36

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

floWenoL posted:

No, they're not.

I was in the contemplating writing a footnote that said yes, I know the differences, but for a type declaration, and for Paul MaudDib's purposes, char *foo[] is the same as char **foo.

I decided against it because I thought there weren't going to be any pedants about this.

# ? Jun 2, 2012 06:40

Qwertycoatl: Dec 31, 2008

Paul MaudDib posted:

First question: According to cdecl, the pointers are instantiated like this. This seems backwards, that looks like an array of pointers to roots, what I want is a pointer to an array of roots.

root (*input_roots[num_roots];
root (*output_roots)[num_roots];

Next problem, what is the correct way to access the members via the pointer? Common sense would suggest this is the correct way to do that:

linknode *next_node = (*input_roots)[i].start;

Notice that the syntax to access a member via a pointer is very similar to the syntax to declare the pointer in the first place. That's how you work out what declarations for complicated types look like.

# ? Jun 2, 2012 12:39

raminasi: Jan 25, 2005; a last drink with no ice

Suspicious Dish posted:

I was in the contemplating writing a footnote that said yes, I know the differences, but for a type declaration, and for Paul MaudDib's purposes, char *foo[] is the same as char **foo.

I decided against it because I thought there weren't going to be any pedants about this.

You clearly don't follow this thread very closely.

# ? Jun 2, 2012 20:20

IratelyBlank: Dec 2, 2004; The only easy day was yesterday

I'm really comfortable with C# and I'm looking to learn C++, but I'm not really sure where to start. I went through a university page for an intro to C++ course and it was all the usual basic things, arrays and pointers and if/for/etc. but that isn't really what I'm looking for.

I'm looking for something that will highlight the differences between the languages, for example the equivalents of List<T>, Dictionary<TKey, T>, Tuples, even things as simple as array.Length to get the length of an array or how to use something like DirectoryInfo/FileInfo to get the list of contents in a directory. Essentially anything that is aimed towards someone learning C++ coming from a C# mindset would be helpful.

# ? Jun 2, 2012 21:20

nielsm: Jun 1, 2009

IratelyBlank posted:

I'm really comfortable with C# and I'm looking to learn C++, but I'm not really sure where to start. I went through a university page for an intro to C++ course and it was all the usual basic things, arrays and pointers and if/for/etc. but that isn't really what I'm looking for.

I'm looking for something that will highlight the differences between the languages, for example the equivalents of List<T>, Dictionary<TKey, T>, Tuples, even things as simple as array.Length to get the length of an array or how to use something like DirectoryInfo/FileInfo to get the list of contents in a directory. Essentially anything that is aimed towards someone learning C++ coming from a C# mindset would be helpful.

I've seen lots of recommendations for the book Accelerated C++. It should cover the language and the STL (standard template library) which will answer most of your questions.

It (probably) won't cover much system-specific stuff, such as listing a directory. How you do that depends on what OS you're going to be running on. E.g. on Windows you'd use the FindFirstFile family of functions, while on Unix-like systems you'd use something like glob or readdir. Or maybe you want to use some cross-platform library that gives you a different interface for it altogether.

# ? Jun 2, 2012 21:46

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 20:14

tractor fanatic: Sep 9, 2005; Pillbug

Do I get some kind of guarantee in C++ that

code:

struct Struct{
    Element e;
};

sizeof(Struct) == sizeof(Element)

as long as Struct doesn't have any kind of virtuals?

# ? Jun 3, 2012 03:25

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread

«‹›640 »