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

«‹›641 »

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

Karl Sharks posted:

Well, it's not the 'right' way, but we haven't gotten into LU-decomposition, really. We did a single problem, but it felt like we probably did a sort of babby's first for that. We don't really use inverse much anymore, mostly (reduced) row echelon form because

Thanks for the help though, everyone.

If you can get away with it, try Python. Numpy has built in matrix types and has library functions for multiplication, inversion, and pseudo-inversion (also things like gaussian generation, etc). Numpy ties down into C so it's pretty fast. I realize that doesn't help you much if you need C/C++ specifically, but Python was more or less built for this poo poo.

# ? Nov 9, 2012 17:57

Adbot: ADBOT LOVES YOU

# ? Jun 8, 2024 12:35

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

Optimus Prime Ribs posted:

Yeah basically, though it's only XInput and not DirectInput.
Using XInput is pretty tedious and ugly (especially getting the angle of the analog sticks), so I want to make it... well, not that.

Why are you provide your own event loop and wrapper, then, instead of just a few utility functions?

# ? Nov 9, 2012 21:19

Optimus Prime Ribs: Jul 25, 2007

Rottbott posted:

I find it pretty simple and straightforward. I've wrapped it, but only for writing cross-platform. To get the analogue stick angle you just call one function to get the controller state and do some trig with the X/Y vector...

To each their own I suppose.
I just want to take all the XInputGetState calls and subsequent code that ends up looking like this:

C++ code:

ZeroMemory(&state, sizeof XINPUT_STATE);
if (XInputGetState(0, &state) == ERROR_SUCCESS)
{
    if (state.Gamepad.wButtons & XINPUT_GAMEPAD_A) {
        /* Pressed "A" on controller 1 */
    }

    if (state.Gamepad.wButtons & XINPUT_GAMEPAD_B) {
        /* Pressed "B" on controller 1 */
    }

    if (state.Gamepad.wButtons & XINPUT_GAMEPAD_X) {
        /* Pressed "X" on controller 1 */
    }

    if (state.Gamepad.wButtons & XINPUT_GAMEPAD_Y) {
        /* Pressed "Y" on controller 1 */
    }
}

And replace it with a few function calls that will handle it all for you.

Suspicious Dish posted:

Why are you provide your own event loop and wrapper, then, instead of just a few utility functions?

For the XInput states to stay up to date a loop is required either way, as the XInputGetState function needs to be continuously called, so I figured doing this would provide the best functionality:

C++ code:

int main()
{
    x360::Event event;

    while (true)
    {
        x360::InputUpdate();
        while (x360::GetEvent(&event))
        {
            switch (event.type)
            {
            case X360_PRESS:
                printf("Pressed the '%s' button\n", x360::ButtonIdToString(event.button));
            break;
            }
        }
    }

    return 0;
}

(That's my current working prototype)

My thought process for doing it like that is that it allows adding new events as they are required to be rather trivial (such as releasing a button, or pressing a certain combination of buttons).
As well it only requires calling two functions to get any kind of input from the controller.

Are you saying it would be better to just write a bunch of functions like this?

C++ code:

bool IsButtonPressed(WORD buttons, int buttonToCheck)
{
    return buttons & buttonToCheck;
}

short AnalogAngleLX(short thumbLX)
{
    if (thumbLX < XINPUT_GAMEPAD_LEFT_THUMB_DEADZONE && thumbLX > -XINPUT_GAMEPAD_LEFT_THUMB_DEADZONE) {
        return 0;
    } else {
        return thumbLX;
    }
}

And let the person using it handle the connecting/disconnecting of the controller and calling of the XInputGetState function?

# ? Nov 9, 2012 23:15

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

Hm, so that means that you'll get dead input frames either way.

# ? Nov 10, 2012 02:08

Rottbott: Jul 27, 2006; DMC

That 'before' code looks fine to me. There's no reason all those separate if () checks couldn't be done with a loop if that's what you're doing.

If you are going to wrap it, you might as well go all the way and do auto-repeat, half axes, relative positions and so on. Also, it would be worth not naming it 'x360' and abstracting it enough so that the same interface could be used on other platforms with a different implementation - e.g. DirectInput or whatever heathen thing they use on Macs.

Personally I don't like the event stuff for input over a simple system to query controls - if the user actually manages to press a button for less than 16 milliseconds they probably won't mind if you ignore it anyway, and it might even be preferable.

# ? Nov 10, 2012 16:45

spooky wizard: May 8, 2007

I'm still just beginning coding, so apologies if this question is really basic! I'm working with classes on a library reference practice program, which I have a grasp on, my problem is in trying to get lines from a file and send them to the class. For example the lines are:

C8394 Kundera Milan The Unbearable Lightness of Being novel available
C1934 Heidegger Martin Being and Time philosophy unavailable

So the first thing to get is the call #, Author Last, first, title, genre, availability, which are all parts of the class. Normally I'd just getline
And I'm not sure how to send each line to the class and break it up, or if I can just do what I've done here:

code:

#include "library.h"

using namespace std;
#define MAXBOOKS 10000

int main()
{
        library booklist[MAXBOOKS];
        ifstream fin;
        string filename1, filename2;
        int length = 0;
        string names;
	string array[6];

        cout << "Enter the name of the library holdings file: ";
        cin  >> filename1;
        fin.open(filename1.c_str());

        if ( fin.fail() ) {
        cerr << "Could not open file " << filename1 << " for reading.\n";
        exit(1);
        }


        while ( length < MAXBOOKS && !fin.eof() )
        {
                for(int i = 0; i <= 6; i++)
                {
                        getline(fin, names, '\t');
                        array[i] = names + ' ';  //This array doesn't do anything,
						   just testing that I'm storing
 	                                           it. Class goes here.     	                              
                }

                for (int j = 0; j <= 6; j++)
                {
                        cout << array[j];
                }
                length++;
        }

I just put this together to see that I was actually getting everything into something correctly. I was thinking of modifying the first for loop to have getline(fin, names, '\t') then sending it to the class, but then I'd have to make six class functions. I've tried looking this up online, and the answer is probably really obvious.

Is there a way to get the line as a whole, break it up into six parts by TAB, then send it to the array of classes? I'm honestly beyond confused about the whole thing, but it seems like a really simple concept.

spooky wizard fucked around with this message at 12:45 on Nov 12, 2012

# ? Nov 12, 2012 12:40

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

Just pull out all six entries into a bunch of variables and pass them to your constructor?

# ? Nov 12, 2012 13:57

spooky wizard: May 8, 2007

Yeah, thanks. I think just presenting the question helped me realize how simple it was. I need a programming partner to just talk things out with or something :downs:

I don't think I even need a for loop.

# ? Nov 12, 2012 14:25

Dodoman: Feb 26, 2009; A moment of laxity
A lifetime of regret; Lipstick Apathy

Hey guys need some help figuring out why I get a weird bug in my code.

code:

#include <stdio.h>

void getInput()
{
    int kelvin;
    char menu;
    char offer;


        do
        {
            printf("Please enter the temperature of the water in Kelvin centigrade: ");
            scanf("%d%*c", &kelvin);

            printf("\n1)Press 'a' to convert to celsius\n");
            printf("2)Press 'b' to convert to fahrenheit\n");
            printf("Please choose an option:  ");
            scanf("%c%*c", &menu);

            switch(menu)
            {
                case 'a':
                case 'A':
                    convCalc(kelvin, 'a');
                    dispState(kelvin);
                break;
                case 'b':
                case 'B':
                    convCalc(kelvin, 'b');
                    dispState(kelvin);
                break;
                default:
                    printf("You have entered an invalid option");
            }

            printf("\nDo you wish to continue? Press Y to continue or N to quit: ");
            scanf("%c%*c", &offer);

        }while (!(offer == 'n' || offer == 'N'));

    return;
}

void convCalc(int kelvin, char option)
{
    int celsius = 0;
    float fahrenheit = 0.0;
    celsius = (kelvin - 273);
	fahrenheit = ((9 * (float)celsius / 5) + 32);
    if (option == 'a')
        {
            printf("\nThe temperature is %d degrees celsius.", celsius);
        }
        else
            {
                printf("\nThe temperature is %.2f degrees fahrenheit.", fahrenheit);
            }

	return;
}

void dispState(int kelvin)
{
    int celsius = (kelvin - 273);
    if (celsius <= 0)
        {
            printf("\nThe water is in the solid state.\n");
        }
        else if (celsius >= 1 || celsius <= 99)
            {
                printf("\nThe water is in the liquid state.\n");
            }
            else
                {
                    printf("\nThe water is in the gaseous state.\n");
                }

    return;
}


int main()
{
    getInput();
    dispState(0);

    return 0;
}

When I enter n/N the program quits like it's supposed to, but it prints

quote:

The water is in the solid state.

just before it ends. Any idea why?

# ? Nov 12, 2012 17:26

Vanadium: Jan 8, 2005

Because it says dispState(0) in main.

# ? Nov 12, 2012 17:28

Dodoman: Feb 26, 2009; A moment of laxity
A lifetime of regret; Lipstick Apathy

drat it. So simple :suicide:

.

Edit: Yep that fixed it. Thanks a lot

Dodoman fucked around with this message at 18:53 on Nov 12, 2012

# ? Nov 12, 2012 17:33

awesmoe: Nov 30, 2005; Pillbug

RoryGilmore posted:

Yeah, thanks. I think just presenting the question helped me realize how simple it was. I need a programming partner to just talk things out with or something I don't think I even need a for loop.

Remember this lesson, and learn it well, and when you get a job the old guys will think you're god's gift because you'll only ask them sensible questions.
http://en.wikipedia.org/wiki/Rubber_duck_debugging

# ? Nov 12, 2012 23:30

HipsLikeCinderella: Nov 8, 2006

I'm very confused about both typedef and the syntax of function pointers. Bare with me as I try to lay out the context.

I have a structure foo, with a function pointer member:

code:

struct foo { void (* tp_func_t) (void * args); };

I have a typedef:

code:

typedef void * (* tp_func_t) (void * data);

I have a function header with one parameter being a function pointer (I think?):

code:

struct foo * send(...,  tp_func_t function_pointer_arg);

And within the above function, I am trying to assign a 'struct foo's function pointer member to the one passed in as a parameter:

code:

     struct foo *structure = (struct foo*) malloc(sizeof(struct foo));
		structure->tp_func_t = function_pointer_arg;

All I get is an incompatible pointer assignment which I don't know how to interpret. The typedef and syntax are confusing me further. Could anyone explain this or point me in the right direction?

# ? Nov 14, 2012 23:34

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

1) One returns a void, and one returns a void *.

2) Don't name your fields the same as the types. That's rude.

3) That's bad syntax. You should be doing:

code:

struct foo { tp_func_t func; }

# ? Nov 14, 2012 23:41

pseudorandom name: May 6, 2007

And you shouldn't be naming your types with the _t suffix, that entire namespace is reserved by the standard.

# ? Nov 15, 2012 05:21

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

Says what? I've certainly seen libraries that have the _t suffix.

# ? Nov 15, 2012 05:28

pseudorandom name: May 6, 2007

Yes; they're broken.

# ? Nov 15, 2012 05:49

b0lt: Apr 29, 2005

pseudorandom name posted:

And you shouldn't be naming your types with the _t suffix, that entire namespace is reserved by the standard.

To be specific, it's reserved by POSIX.

# ? Nov 15, 2012 05:56

pseudorandom name: May 6, 2007

Is it POSIX? I could've sworn it was C.

# ? Nov 15, 2012 05:59

taqueso: Mar 8, 2004

Ya, it is POSIX.

# ? Nov 15, 2012 06:15

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

If it's POSIX, I think it's a misreading of the spec:

quote:

The prefixes posix_, POSIX_, and _POSIX_ are reserved for use by IEEE Std 1003.1-2001 and other POSIX standards. Implementations may add symbols to the headers shown in the following table, provided the identifiers for those symbols either:

Begin with the corresponding reserved prefixes in the table, or

Have one of the corresponding complete names in the table, or

End in the string indicated as a reserved suffix in the table and do not use the reserved prefixes posix_, POSIX_, or _POSIX_, as long as the reserved suffix is in that part of the name considered significant by the implementation.

And "_t", of course, is reserved in the table below. What it's trying to say is that any implementation that wants to extend the POSIX spec must use the suffix "_t", not that the suffix "_t" is reserved for POSIX and POSIX alone.

# ? Nov 15, 2012 07:02

pseudorandom name: May 6, 2007

The entire point of that section is that if an implementation of POSIX (or a future version of POSIX) uses identifiers ending with _t that conflict with an application's identifier, the application is at fault.

# ? Nov 15, 2012 07:38

That Turkey Story: Mar 30, 2003

Yeah, _t is fine in C and C++. The things C++ reserves for the implementation are identifiers starting with underscore followed by a capital letter, any identifier with two adjacent underscores, and any identifier in the global namespace that starts with underscore.

# ? Nov 15, 2012 08:57

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

The correct thing to do is to name your type whatever the hell makes sense to you, preferably something evocative of its actual purpose and application, and then be prepared to change it in the extraordinarily unlikely event that someone comes along and adds a type to POSIX named that exact same thing. Also, if this is C++ you should be declaring everything non-local in namespaces anyway.

But seriously, code that you're not willing to rename a type in is code that you should have thrown away already.

# ? Nov 15, 2012 10:07

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

rjmccall posted:

But seriously, code that you're not willing to rename a type in is code that you should have thrown away already.

Public libraries and API breaks mean that I can't simply rename "cairo_t" for POSIX compliance in the unlikely future.

# ? Nov 15, 2012 14:56

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

Suspicious Dish posted:

Public libraries and API breaks mean that I can't simply rename "cairo_t" for POSIX compliance in the unlikely future.

If you're designing a library with binary stability requirements, sure, you have to be more circumspect. Of course, if it's a C library then type names aren't part of your binary interface, and if it's a C++ library then all of your public declarations should be namespaced. But designing the interface to a library with binary stability requirements is never something you should do casually.

# ? Nov 15, 2012 18:44

Volte: Oct 4, 2004; woosh woosh

rjmccall posted:

If you're designing a library with binary stability requirements, sure, you have to be more circumspect. Of course, if it's a C library then type names aren't part of your binary interface, and if it's a C++ library then all of your public declarations should be namespaced. But designing the interface to a library with binary stability requirements is never something you should do casually.

Are you seriously suggesting that if cairo_t changes its name that it's reasonable to expect every single developer of a Cairo app that has ever existed to change every instance of it in their own code? If you make a change that causes ten thousand other people do have to perform emergency maintenance work then you probably made a lovely decision.

# ? Nov 15, 2012 20:23

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!

Volte posted:

Are you seriously suggesting that if cairo_t changes its name that it's reasonable to expect every single developer of a Cairo app that has ever existed to change every instance of it in their own code? If you make a change that causes ten thousand other people do have to perform emergency maintenance work then you probably made a lovely decision.

A workaround would be to change it, deprecate the old name in documentation and such, but have something in the main header like

code:

#ifdef BACK_COMPATIBILITY
typedef whatevernewname cairo_t;
#endif

(or a #ifndef to avoid any changes to client codebases.)

But it seems pretty silly of a change to bother making just to avoid the remote possibility that at some point in the future POSIX might want to define a type named cairo_t.

# ? Nov 15, 2012 21:34

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

Volte posted:

Are you seriously suggesting that if cairo_t changes its name that it's reasonable to expect every single developer of a Cairo app that has ever existed to change every instance of it in their own code? If you make a change that causes ten thousand other people do have to perform emergency maintenance work then you probably made a lovely decision.

What exactly requires emergency maintenance here? Is it typical for Cairo apps to get spontaneously recompiled and deployed against a new version?

It is reasonable for Cairo to expect that a type name like cairo_t is not actually going to conflict with POSIX. If it suddenly does, then okay, Cairo needs to provide workarounds for affected users, and they need to have a plan to fix their poo poo, and that plan is necessarily going to require some amount of long-term effort from their users.

I'm not suggesting that Cairo should rename core types in a point update just to gently caress with their users, and if Cairo supports a stable binary interface across versions then they obviously have to maintain that. But yes, it is reasonable for Cairo to change its interfaces with a major version bump if it sees a real benefit to doing so, and it is reasonable to them to expect their users to plan for it.

# ? Nov 15, 2012 22:50

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

rjmccall posted:

What exactly requires emergency maintenance here? Is it typical for Cairo apps to get spontaneously recompiled and deployed against a new version?

Yes. It's a core graphics library of Linux; if they broke ABI, a lot of old applications would start crashing.

# ? Nov 16, 2012 00:38

bomblol: Jul 17, 2009; my first crapatar

I'm trying to use a map as a parameter as a function, which, through reading some old stackexchange posts, I've found to be

code:

int readFile(map<int, string>&)

Which compiles... but I have no idea how I'm supposed to internet with the map within the function since it isn't given a name.

# ? Nov 16, 2012 01:24

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

bomblol posted:

I'm trying to use a map as a parameter as a function, which, through reading some old stackexchange posts, I've found to be
code:
int readFile(map<int, string>&)
Which compiles... but I have no idea how I'm supposed to internet with the map within the function since it isn't given a name.

You're right, there's no way to do anything with it without a name. Fortunately, adding one is easy:

C++ code:

int readFile(map<int, string> &derp)

However your question implies some kind of larger misunderstanding. What's the bigger problem you're trying to solve, and did you try some things that failed before you found the stackexchange posts?

# ? Nov 16, 2012 01:34

bomblol: Jul 17, 2009; my first crapatar

GrumpyDoctor posted:

You're right, there's no way to do anything with it without a name. Fortunately, adding one is easy:
C++ code:
int readFile(map<int, string> &derp)
However your question implies some kind of larger misunderstanding. What's the bigger problem you're trying to solve, and did you try some things that failed before you found the stackexchange posts?

I'm attempting to do an assignment for a class and the easiest way to do it is to use map. Most of what I'm doing with it is encapsulated in a function, but I also needed to use it for another function, which is why I wanted to reference it in the function rather than have it created in the function.
I'm new to programming so I have trouble describing what exactly I'm trying to do, but I got it working now. I feel really dumb about not realizing I can just add the name like any other parameter.

# ? Nov 16, 2012 01:44

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Suspicious Dish posted:

Yes. It's a core graphics library of Linux; if they broke ABI, a lot of old applications would start crashing.

Type names aren't part of the ABI with C.

# ? Nov 16, 2012 02:51

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

Plorkyeran posted:

Type names aren't part of the ABI with C.

Not strictly, but I'm sure they'll break debugging information like DWARF.

# ? Nov 16, 2012 03:15

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

Suspicious Dish posted:

Yes. It's a core graphics library of Linux; if they broke ABI, a lot of old applications would start crashing.

Great! Then you have nothing to worry about, because POSIX isn't going to add a type name that breaks tons of source code on Linux, and Linux would never accept it if they did. Also, this is why they put "cairo" in every single one of their type names.

My original point was that there is no reason to specifically avoid the _t suffix just because POSIX "reserved" it. It is possible that following my advice could lead to portability problems. So can using stricmp. The general rule continues to be this: do what works best for you in your private code, but be more careful when committing to an API.

# ? Nov 16, 2012 03:58

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

Yeah, you should avoid using _t because your system or a new standard might want to use it. I recommend using _u for "user-defined" types that you create. (My boss still refuses to believe I was joking when I said this in the work IRC channel.)

Now that our product has been released, people have asked us for OS X support. So I have started working on an OS X port. Our type uuid_t has to be renamed because that's already defined in Darwin. So I actually renamed it to uuid_u. I don't know what it'll end up being by the time the port finishes, but really we should have never used _t for everything in the first place.

# ? Nov 16, 2012 10:12

Vanadium: Jan 8, 2005

Just port your code to use the native uuid_t type, clearly that'll make it faster too somehow! :twisted:

# ? Nov 16, 2012 12:59

Paolomania: Apr 26, 2006

Or perhaps you could shockingly use three more characters and call it foo_type. Be careful though: three extra characters is one step away from FooProxyAdapterFactoryWrapper.

# ? Nov 16, 2012 14:25

Adbot: ADBOT LOVES YOU

# ? Jun 8, 2024 12:35

pseudorandom name: May 6, 2007

Suspicious Dish posted:

Not strictly, but I'm sure they'll break debugging information like DWARF.

But that isn't part of the ABI either.

# ? Nov 17, 2012 06:30

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

«‹›641 »