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 »

ShoulderDaemon: Oct 9, 2003; support goon fund; Taco Defender

You don't need a library. You don't need to worry about storing it in memory. If all your image is is a sequence of drawn black lines, just produce trivial PostScript output.

In your code, start off the program by outputting "%!PS" to some file so you're valid PostScript, then "72 1400 div dup scale" so you're in 1400 DPI instead of 72 DPI.

For every line from (x1,y1)->(x2,y2), output "newpath x1 y1 moveto x2 y2 lineto stroke".

At the end, output "showpage".

That's it, you're done, you've produced a PostScript file that contains your image. Save it with a .ps extension and give it to the printer.

Edit: 1400, not 1440 DPI.

ShoulderDaemon fucked around with this message at 20:18 on Apr 28, 2008

# ? Apr 28, 2008 20:13

Adbot: ADBOT LOVES YOU

# ? May 18, 2024 02:59

Land Mime: Jul 13, 2007; Love never blows up and gets killed

The_Carp posted:

make input1.txt

Just use make -f filename

# ? Apr 28, 2008 20:21

Viper2026: Dec 15, 2004; I got iRaped by Steve Jobs and all I got was this custom title.

I'm having some trouble with a doubly linked list in C++. For some reason, I keep getting errors like:

code:

LinkedSet.h:155: warning: converting to non-pointer type 'double' from NULL
LinkedSet.h:163: error: assignment of data-member 'LinkedSet<double>::head' in read-only structure
LinkedSet.h:168: error: assignment of data-member 'LinkedSet<double>::tail' in read-only structure
LinkedSet.h:174: error: assignment of data-member 'LinkedSet<double>::tail' in read-only structure
LinkedSet.h:179: error: assignment of data-member 'LinkedSet<double>::head' in read-only structure
LinkedSet.h:186: error: assignment of data-member 'LinkedSet<double>::node_count' in read-only structure

I'm not so worried about the conversion warning, but the read-only ones have me stumped.

Here is the relevant code from my LinkedSet.h file:

code:

template <typename T>
class LinkedSet: public SetADT<T> {
 
   private:
      class DNode{
         public:
            DNode *next;
            DNode    *prev;
            T      data;
      };
 
      int node_count;
 
      DNode *head, *tail;
 
   public:
      //prototypes and stuff below here

and the lines generating the problems:

code:

template <typename T>
T LinkedSet<T>::remove(T element) const{
   if(head == NULL) //empty list
      return NULL;
 
   DNode *temp = head;
   while(temp != NULL){
      if(temp->data == element){
         if(temp == head){
            //pop_front();
            DNode *temp2 = head;
            head = head->next;//
            delete temp2;
            if(head != NULL)
               head->prev = NULL;
            else
               tail = NULL;//
 
         }
         else if(temp == tail){
            //pop_back();
            DNode *temp2 = tail;
            tail = tail->prev;//
            delete temp2;
            if(tail != NULL)
               tail->next = NULL;
            else
               head = NULL;//
         }
         else{ //in the middle somewhere
            temp->prev->next = temp->next;
            temp->next->prev = temp->prev;
            delete temp;
         }
         node_count = node_count - 1;  //***I also get an assignment error here if i try to do
         return element;               //node_count--;, but the way it is implemented now compiles
      }
      temp = temp->next;
   }
   return NULL;
}

For the life of me, I don't see what the problem could be, unless it's something I need to do differently since this class is a template class and inherits SetADT as you can see in the top.

Do I need to include "template <typename T>" and all that stuff for the subclass node, since the class linkedset is a template class?

Viper2026 fucked around with this message at 23:35 on Apr 28, 2008

# ? Apr 28, 2008 23:19

Colonel Taint: Mar 14, 2004

I could be wrong, but I don't think your remove function should be declared/defined as const.

# ? Apr 28, 2008 23:43

more falafel please: Feb 26, 2005; forums poster

SintaxError posted:

I could be wrong, but I don't think your remove function should be declared/defined as const.

Yes, although the node_count = node_count - 1; shouldn't compile like this anyway. But yeah, remove shouldn't be const.

# ? Apr 28, 2008 23:53

Viper2026: Dec 15, 2004; I got iRaped by Steve Jobs and all I got was this custom title.

Ah thanks very much, it got rid of the assignment errors

Remove is also defined as a virtual in my SetADT.h so I also had to remove virtual from my linkedset.h, I hope that doesn't screw anything up.

And am I correct in assuming the conversion from double to NULL warning aren't much to worry about?

# ? Apr 28, 2008 23:59

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

It is an issue. I'm assuming the "converting NULL to double" error occurs at return NULL; in your code. That's bad because NULL isn't a valid value for non-pointer, non-integral types. It's performing an implicit conversion from a pointer (integer) type to the type of the elements in your list. Think about what would happen if there is no such conversion...

# ? Apr 29, 2008 00:37

more falafel please: Feb 26, 2005; forums poster

Avenging Dentist posted:

It is an issue. I'm assuming the "converting NULL to double" error occurs at return NULL; in your code. That's bad because NULL isn't a valid value for non-pointer, non-integral types. It's performing an implicit conversion from a pointer (integer) type to the type of the elements in your list. Think about what would happen if there is no such conversion...

If you can change the signature of the function, I would return a bool instead of a T. There is no generic "bad" value for all types in C++. However, since your function already takes the element to remove, the caller already knows what element will be removed, and returning it is redundant. I would return true if the element was found and removed, and false otherwise.

# ? Apr 29, 2008 01:09

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

That's true. Honestly, I just skimmed over the code. :shobon:

# ? Apr 29, 2008 01:58

ruden: Dec 2, 2006

ShoulderDaemon posted:

You don't need a library. You don't need to worry about storing it in memory. If all your image is is a sequence of drawn black lines, just produce trivial PostScript output.

In your code, start off the program by outputting "%!PS" to some file so you're valid PostScript, then "72 1400 div dup scale" so you're in 1400 DPI instead of 72 DPI.

For every line from (x1,y1)->(x2,y2), output "newpath x1 y1 moveto x2 y2 lineto stroke".

At the end, output "showpage".

That's it, you're done, you've produced a PostScript file that contains your image. Save it with a .ps extension and give it to the printer.

Edit: 1400, not 1440 DPI.

Ok, I made the PS file of the image. This is the situation as it stands:

a) small images are made perfectly, the numbers work out and everything and the image is perfect
b) the large image does not display correctly at all, it's cut short on the top and bottom, presumably because I'm doing something on the order of "newpath 10 10 moveto 33600 336000 lineto stroke" and the numbers are just too big to display correctly in a PS viewer
c) the file is not readable in any Adobe reader, it says it is corrupted and unreadable, but various PS readers like GSView etc, can read it fine. If I hand this PS file to the printer, and they can't read it, I'm out of luck, do I need some kind of special header for Adobe to read it?

Thanks.

# ? Apr 29, 2008 04:33

Scaevolus: Apr 16, 2007

ruden posted:

Ok, I made the PS file of the image. This is the situation as it stands:

a) small images are made perfectly, the numbers work out and everything and the image is perfect
b) the large image does not display correctly at all, it's cut short on the top and bottom, presumably because I'm doing something on the order of "newpath 10 10 moveto 33600 336000 lineto stroke" and the numbers are just too big to display correctly in a PS viewer
c) the file is not readable in any Adobe reader, it says it is corrupted and unreadable, but various PS readers like GSView etc, can read it fine. If I hand this PS file to the printer, and they can't read it, I'm out of luck, do I need some kind of special header for Adobe to read it?

Thanks.

Look up line-drawing algorithms. You could initialize a 12GB raw image file with zeros, then draw lines by doing file seeks and writes. It wouldn't be pretty, and it might take a very long time, but with good filesystem caching it might be manageable.

# ? Apr 29, 2008 04:53

haveblue: Aug 15, 2005; Toilet Rascal

Filling in a 12GB range with unpredictable writes of single bytes? When did he say this project had to be finished by?

(And don't forget to throw in a targa header before you start writing pixels.)

# ? Apr 29, 2008 04:56

JoeNotCharles: Mar 3, 2005; Yet beyond each tree there are only more trees.

Scaevolus posted:

Look up line-drawing algorithms. You could initialize a 12GB raw image file with zeros, then draw lines by doing file seeks and writes. It wouldn't be pretty, and it might take a very long time, but with good filesystem caching it might be manageable.

That's the worst idea I've ever heard. The man is doing VECTOR GRAPHICS.

# ? Apr 29, 2008 04:58

Scaevolus: Apr 16, 2007

Assuming each single byte write takes 1/10,000 of a second, and other processing time is negligible, it would only take a week, if 50% of the pixels are filled.

This is the sacrifice one must make for 1400 DPI.

# ? Apr 29, 2008 05:14

Donald Duck: Apr 2, 2007

Is there any good C IDEs for Linux? All I ever hear about is Visual Studio. At the moment I've been using Emacs for it but I was wondering if there was anything else

# ? Apr 29, 2008 05:33

ruden: Dec 2, 2006

That sounds like a lot more work/processing power than I have time for. This PS file is all made and seems to be coded perfectly. I just need to know how to make it display such a large file. Manipulating 0s and 1s for a week sounds like an awful waste of time.

# ? Apr 29, 2008 05:46

ShoulderDaemon: Oct 9, 2003; support goon fund; Taco Defender

ruden posted:

Ok, I made the PS file of the image.

Adobe is choking because your document isn't DSC compliant and Adobe doesn't actually produce raw PostScript interpreters. GhostScript isn't inferring the correct bounding box because GhostScript is a really amazingly bad PostScript interpreter. Real printers typically know what size of paper they are using instead of having to infer it from the document being printed, and they also tend to not care about the metadata that lets them do fancy tricks like print pages out of order, but software does.

The solution is to add the DSC headers.

I think making your output look something like this should be enough:

code:

%!PS-Adobe-3.0
%%BoundingBox: 0 0 1728 17280
%%DocumentMedia: banner 1728 17280 0 () ()
%%Pages: 1
%%EndComments
%%Page: banner 1

72 1400 div dup scale
0 setlinewidth

newpath 10 10 moveto 33600 336000 lineto stroke

showpage

%%EOF

Note that you'll probably have a hell of a time getting software to display this no matter what; they have to create a multi-gigabyte raster to render to, and most software renderers are just going to choke and display a blank page at this size. If you want to test it, either make a much smaller test banner to be printed by the same printer at presumably a low enough cost that it's not a problem, or just ask the people who own the printer to verify your document. If the printer is actually a plotter, that's really easy: just ask them to do a print with no ink, and watch the pen to verify that it's drawing the correct lines. If it's not a plotter, they should either have the specialized software that can simulate a large job without crashing, or they can do something like an interrupted run where they feed it a much smaller page and verify that it's at least drawing the very end of the banner correctly.

# ? Apr 29, 2008 05:57

ruden: Dec 2, 2006

Is that the correct dimensions for the 336020x33620 banner? I'm not too familiar with the PS headers, so I basically copied and pasted it into my Perl file. If I need to change something I would appreciate it, I don't want to mess something up from having wrong dimensions.

# ? Apr 29, 2008 06:07

ShoulderDaemon: Oct 9, 2003; support goon fund; Taco Defender

ruden posted:

Is that the correct dimensions for the 336020x33620 banner? I'm not too familiar with the PS headers, so I basically copied and pasted it into my Perl file. If I need to change something I would appreciate it, I don't want to mess something up from having wrong dimensions.

PostScript uses 72DPI in calculating dimensions, and doesn't really have a concept of a pixel - You specified 20 ft by 2 ft at one point, so I just did 72 * 12 * 2 by 72 * 12 * 20. If you want those exact "pixel" counts at 1400 DPI, you'll want 72 * 3620 / 1400 and 72 * 336020 / 1400, which aren't round numbers (and BoundingBox is constrained to integer values). I'd probably round up, and go with 1730 and 17282. Whoever setup the printer should be able to tell you exactly what bounding box is most appropriate.

# ? Apr 29, 2008 06:17

ruden: Dec 2, 2006

Great, thanks a lot for the help. The file is looking like it's theoretically perfect now. I'll have to talk to the printers and see what they need changed to make it print fine.

# ? Apr 29, 2008 06:21

ColdPie: Jun 9, 2006

Donald Duck posted:

Is there any good C IDEs for Linux? All I ever hear about is Visual Studio. At the moment I've been using Emacs for it but I was wondering if there was anything else

Check out this thread in SH/SC, it should answer your question.

# ? Apr 29, 2008 14:54

Donald Duck: Apr 2, 2007

C question:

I was doing all the simple exercises in the K&R book to catch back up on it and I can't seem to fix this problem. I have a feeling its something stupid I've overlooked thats causing this:

code:

  1 #include <stdio.h>
  2       
  3 main() {
  4     int chars[257];
  5     int c, i;
  6     char ch;
  7     for(i = 0; i < 257; i++) 
  8         chars[i] = 0;
  9     while((c = getchar()) != EOF) { 
 10         ++chars[c];
 11     }
 12 
 13     for(i = 0; i < 257; i++) {
 14         int j = 0;
 15         ch = (char) i; 
 16         printf("%d %s ", i, ch);
 17         for (j = 0; j < chars[i]; j++)
 18               printf("*");
 19         printf("\n");
 20         }
 21 }
 22 
 23

Sorry about the line numbers, they copied over from vim.

The program is suppose to take an input, then print out how often each char occured, as a histogram.

This worked fine when I just had the line begin with the int value of a char, but when I convert them to chars, the program crashes with a segmentation fault

Output is:
0 (null)
Segmentation fault.

So it is printing the first char out correctly.

Donald Duck fucked around with this message at 04:25 on Apr 30, 2008

# ? Apr 30, 2008 04:20

haveblue: Aug 15, 2005; Toilet Rascal

%s expects a char*, not just a char.

(Next time, please try to give more information about the crash, at least the line number.)

# ? Apr 30, 2008 04:25

Donald Duck: Apr 2, 2007

HB posted:

%s expects a char*, not just a char.

(Next time, please try to give more information about the crash, at least the line number.)

Segmentation faults don't give line numbers... And I was just editing the result in as you printed that, sorry.
Thanks, knew it was something like that.

# ? Apr 30, 2008 04:26

Viper2026: Dec 15, 2004; I got iRaped by Steve Jobs and all I got was this custom title.

For some reason, the cout statements in this portion of my code are not printing anything:

code:

        ifstream infile2("doc3", ios::in);
	LinkedSet<char> *stack2 = new LinkedSet<char>();
	
	while(!infile2.eof()){
		infile2 >> in_char;
		if(in_char == '0')
			stack2->pop_front();
		else if(in_char == '1'){
			infile2 >> in_char;
			stack2->push_front(in_char);
			cout << ":";
		}
	}

I've declared "using namespace std;" at the top and I have couts working elsewhere, but they refuse to print anything here.

EDIT: for some reason using " : " instead of just ":" makes it work...

Viper2026 fucked around with this message at 04:35 on Apr 30, 2008

# ? Apr 30, 2008 04:30

csammis: Aug 26, 2003; Mental Institution

Viper2026 posted:

For some reason, the cout statements in this portion of my code are not printing anything:
code:
        ifstream infile2("doc3", ios::in);
	LinkedSet<char> *stack2 = new LinkedSet<char>();
	
	while(!infile2.eof()){
		infile2 >> in_char;
		if(in_char == '0')
			stack2->pop_front();
		else if(in_char == '1'){
			infile2 >> in_char;
			stack2->push_front(in_char);
			cout << ":";
		}
	}
I've declared "using namespace std;" at the top and I have couts working elsewhere, but they refuse to print anything here.

EDIT: for some reason using " : " instead of just ":" makes it work...

Depending on the platform and the stream settings, cout won't flush (print its buffer) until it encounters whitespace. Now changing that or manually flushing it, that I don't remember :downs:

# ? Apr 30, 2008 04:44

Allie: Jan 17, 2004

Donald Duck posted:

Segmentation faults don't give line numbers... And I was just editing the result in as you printed that, sorry.
Thanks, knew it was something like that.

If you're using gcc, you can use the -g switch which includes debugging info. If you run the program in gdb, or load a core dump from a debug build in gdb, it'll tell you the line numbers, and it'll even print snippets of the code if it can read the file from the path you compiled it from.

I believe MSVC has a similar feature you can use if you compile a debug build and run the application through the IDE.

# ? Apr 30, 2008 04:48

KaeseEs: Feb 23, 2007; by Fragmaster

csammis posted:

Depending on the platform and the stream settings, cout won't flush (print its buffer) until it encounters whitespace. Now changing that or manually flushing it, that I don't remember

If it's an option, replace cout with cerr while debugging (STDERR is unbuffered). Otherwise, look up setbuf(3).

# ? Apr 30, 2008 08:41

Standish: May 21, 2001

Milde posted:

If you're using gcc, you can use the -g switch which includes debugging info. If you run the program in gdb, or load a core dump from a debug build in gdb, it'll tell you the line numbers, and it'll even print snippets of the code if it can read the file from the path you compiled it from.

Or you skip the whole segfault->gdb->stack trace process and just compile with "-Wall -Werror" and it will warn you at compile time:

code:

 warning: format argument is not a pointer (arg 2)

In general, you should always have your compiler's options for "full warnings" and "warnings as errors" turned on.

# ? Apr 30, 2008 11:20

more falafel please: Feb 26, 2005; forums poster

KaeseEs posted:

If it's an option, replace cout with cerr while debugging (STDERR is unbuffered). Otherwise, look up setbuf(3).

Sending std::flush or std::endl (flush with newline) to an output stream will also flush its buffer.

# ? Apr 30, 2008 17:36

Deep 13: Sep 6, 2007; "Let's think the unthinkable, let's do the undoable, let's WORK OUT"

I'm working on a final project in a C++ class. I'm coding a simulator that outputs the status each timestep (basically a text grid with different characters representing different states). I want to make the program pause half a second between each iteration so that you can see its progress. The lab document says to use the method below, but all it is is a for (int i = 0; i < 1000000000; i++) {} loop that spins CPU cycles incrementing a number. This is obviously less than ideal.

code:

double time;
double pause = 0.5;

...

//Pauses for 0.5 seconds
time = clock()+pause*CLOCKS_PER_SEC;
while (clock()<time){};

We're compiling with g++, and haven't covered any libraries besides the basic <iostream>, <cmath>, <cstdlib>, etc. Do I need some special OS-dependent library to do this, or is there a simpler way?

# ? Apr 30, 2008 21:27

JoeNotCharles: Mar 3, 2005; Yet beyond each tree there are only more trees.

That's definitely better than "i < 10000000" because it's checking against an actual time instead of just an arbitrary counter, so it works the same no matter how fast your processor's running. The counter method is completely broken; this is just unoptimal.

What you want is "sleep" (I think it might be _sleep in Visual C++, nut that shouldn't matter to you). Problem is it only takes whole seconds, so the lowest you can do is "sleep(1);" to sleep for 1 second. If that's ok, this is the easiest.

If that's not good enough, you can use "nanosleep" (which I think is Unix-only), which takes a duration measured in nanoseconds but it's a bit more complicated because you need to fill in a structure instead of just passing an int. Google should be able to tell you how to use it.

# ? Apr 30, 2008 21:35

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

There's also usleep, which takes microseconds. All of these should be in unistd.h

# ? Apr 30, 2008 21:46

JoeNotCharles: Mar 3, 2005; Yet beyond each tree there are only more trees.

Avenging Dentist posted:

There's also usleep, which takes microseconds. All of these should be in unistd.h

usleep isn't available everywhere, though - nanosleep and sleep are the most portable. Probably doesn't matter in this case, but it's a good idea to get in the habit of using nanosleep.

# ? Apr 30, 2008 22:10

TheSleeper: Feb 20, 2003

If you're working in windows, you can use Sleep(milliseconds); which is part of the Windows API.

# ? Apr 30, 2008 22:36

Booya @ Circus: Dec 19, 2006; by Fistgrrl

Milde posted:

If you're using gcc, you can use the -g switch which includes debugging info. If you run the program in gdb, or load a core dump from a debug build in gdb, it'll tell you the line numbers, and it'll even print snippets of the code if it can read the file from the path you compiled it from.

I believe MSVC has a similar feature you can use if you compile a debug build and run the application through the IDE.

if you don't want to take the time to learn how to use gdb, running the program in valgrind (with debugging info) will get you very fast results.

# ? May 1, 2008 05:39

vanjalolz: Oct 31, 2006; Ha Ha Ha HaHa Ha

I'm having trouble with a 3 way fork and pipes application.
Program 1 has to fork 2 programs, then pipe things through them like so:

1 -> 2 -> 3 -> 1

That way 1 gets the output of 3, and writes into 2. 2 Will write to 3.

With my code: http://pastebin.org/33187
I'm having problems aroung line 58, where the 2nd program runs and complains about a bad file descriptor. I can't figure out what I've done wrong, as far as i can see i have done everything right.

# ? May 1, 2008 07:31

elevatordeadline: Jan 29, 2008

I hope someone can tell me what I'm doing wrong, because apparently codepad can't.

Here's what's supposed to happen, and what codepad says does happen.

code:

Node at 0x804F438 says 10.000000x^100 and points to 0x0.

When I compile and run the same code, though, well.

code:

:< g++ -o a.exe a.cpp

:< a.exe
Node at 0x324C8 says -0.000000x^16386 and points to 0x64.

So what am I missing?

# ? May 1, 2008 11:29

vanjalolz: Oct 31, 2006; Ha Ha Ha HaHa Ha

elevatordeadline posted:

code:
Node at 0x324C8 says -0.000000x^16386 and points to 0x64.
So what am I missing?

If it makes you feel any better:

code:

~$ ./a.out
Node at 0x804A008 says 10.000000x^100 and points to 0x0.

So uhh, whats up with your compiler?

code:

typedef struct Node { ldouble coeff; ulong power; Node* next; } Node;

I don't like the look of that, you're defining a struct Node then you're typedef'ing over it. You're using g++ so you dont need the type def anyway, change it to

code:

struct Node { ldouble coeff; ulong power; Node* next; }

Are you on a 64 bit system? I think the proper way to printf pointers is %p.

vanjalolz fucked around with this message at 12:42 on May 1, 2008

# ? May 1, 2008 12:22

Adbot: ADBOT LOVES YOU

# ? May 18, 2024 02:59

Vanadium: Jan 8, 2005

It says

code:

foo.cpp:16: error: cast from �Node*� to �uint� loses precision
foo.cpp:16: error: cast from �Node*� to �uint� loses precision

for me

# ? May 1, 2008 12:49

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

«‹›640 »