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 »

Papes: Apr 13, 2010; There's always something at the bottom of the bag.

shrughes posted:

Half? Should cut it down a bit more than that.

Also you're outputting all the factors (or all the ones up to sqrt(n)) when you said you're only supposed to output the prime ones.

Yeah, late night. Meant to type 'over' instead of 'nearly'. Guess that's a pretty good indication I should go to bed.

Also, no it doesn't. Output for 100 is simply 2 and 5.

# ? Sep 10, 2012 06:28

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 20:57

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

Papes posted:

Yeah, late night. Meant to type 'over' instead of 'nearly'. Guess that's a pretty good indication I should go to bed.

Also, no it doesn't. Output for 100 is simply 2 and 5.

Okay, it outputs 2 if that's a factor, and then it outputs all the odd factors. Try 81 or 225.

# ? Sep 10, 2012 09:13

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Papes posted:

Trying to optimize this factoring program and am getting absolutely nowhere, so I've come for help .

What this program is supposed to do is find all prime factors of any number you input, and for extra credit it must work with 64 bit integers. I currently am using the following :
code:
long long minDivisor(long long n)
{
    if (n % 2 == 0)  // checks to see if n is even
     {
        cout << "2 ";
        return 2;
     }
   else
     {
        for (int factor = 3; factor <= n/2; factor += 2)
          {
             if(n % factor == 0)
              {
                 cout  <<  factor << " ";
                 return factor;

              }
           }
           cout << n << " ";
           return n;
       }
}

int main()
{
   long long x = 0;
   long long y;
   cout << "Enter an integer " << endl;
   cin >> x;
   while(x != 1)
     {
        y = minDivisor(x);
        x = x / y;
     }
}
While this works just fine, it is incredibly slow with actual 64 bit integers. Anyone have any ideas on how to make this faster? The only thing I can think of is to throw the first 1000 or so primes in an array and have those checked first, but I don't think that would make too much of a difference.

Google is your friend.

The quickest way of doing this is to do Miller-Rabin and Pollard's rho algorithm.

Use Miller-Rabin to figure out whether or not the number is composite - Pollard's rho algorithm does not work if the number is prime, so you need to run a prime detection algorithm before you factor a 64-bit integer.

After that, use trial division for like the first 1000 primes, then clean up with the Rho detection algorithm.

# ? Sep 10, 2012 14:16

seiken: Feb 7, 2005; hah ha ha

hieronymus posted:

Google is your friend.

The quickest way of doing this is to do Miller-Rabin and Pollard's rho algorithm.

Use Miller-Rabin to figure out whether or not the number is composite - Pollard's rho algorithm does not work if the number is prime, so you need to run a prime detection algorithm before you factor a 64-bit integer.

After that, use trial division for like the first 1000 primes, then clean up with the Rho detection algorithm.

I get the feeling this is for an assignment for a fairly beginner programming class or something of that sort so while your advice is certainly mathematically sound, it's probably overkill and/or not necessarily helpful in this case. The object probably really is just to demonstrate understanding of loops and such, only do these real-world algorithms if you wanna be a superstar!

seiken fucked around with this message at 17:37 on Sep 10, 2012

# ? Sep 10, 2012 16:41

Papes: Apr 13, 2010; There's always something at the bottom of the bag.

shrughes posted:

Okay, it outputs 2 if that's a factor, and then it outputs all the odd factors. Try 81 or 225.

81: 3
225: 3 and 5

What is making you believe that it outputs non prime numbers? I've tested it many times and I've never gotten a nonprime number. Granted it can output duplicates, as the actual output for 225 was 3, 3, 5, 5. I've just been ignoring the duplicates for now as getting rid of them is outside the scope of this assignment. I'll probably fix it for fun when I have free time.

hieronymus posted:

Google is your friend.

The quickest way of doing this is to do Miller-Rabin and Pollard's rho algorithm.

Use Miller-Rabin to figure out whether or not the number is composite - Pollard's rho algorithm does not work if the number is prime, so you need to run a prime detection algorithm before you factor a 64-bit integer.

After that, use trial division for like the first 1000 primes, then clean up with the Rho detection algorithm.

Really appreciate that, I'll look into it later. But as our fellow friend said, it's a bit overkill for this particular assignment.

Papes fucked around with this message at 17:35 on Sep 10, 2012

# ? Sep 10, 2012 17:29

Senso: Nov 4, 2005; Always working

I've recently started learning C++ by myself, after 10 years of Python/PHP/etc. I'm reading the free Thinking in C++ and trying to port a Python project to C++ as I go along. I'm now messing with inheritance and have been battling this specific problem for about 4 hours, without making any progress. I feel like a retard and I now realize why I stuck with Python all these years.

No matter what I do, I get the generic linker error:
main.o In function `main':
main.cpp 34 undefined reference to `Living::move(int, int, int)'

I'm sure it's a stupid mistake, but I just cannot understand why the linker cannot find Living::move(), when it's clearly defined and declared. I've seen many examples do pretty much the same thing as i do, but usually examples on the web are all in the same file for simplification.

Is it caused by spreading my classes in different files/headers and I'm not linking them properly or in the right order? This is something that confuses me a bit, coming from "simple" languages.

main.cpp:

code:

#include "include/game.hpp"
int main()
{
	Living derp;
	derp.x = 5;
	derp.y = 5;
	...
	derp.move(0, 1, 0);
}

include/living.hpp:

code:

#include "game.hpp"
class Living: public Thing {
public:
    Living();
    virtual ~Living();
    void move(int dir_x, int dir_y, int dir_z);
};

living.cpp:

code:

using namespace std;

Living::Living() {}

Living::~Living() {}

void Living::move(int dir_x, int dir_y, int dir_z) {
  x += dir_x;
  y += dir_y;
  z += dir_z;
}

include/thing.hpp:

code:

#include "game.hpp"

class Thing {
public:
    int x;
    int y;
    int z;
	Thing();
    virtual ~Thing();
	void move_to(int n_x, int n_y, int n_z);
};

thing.cpp:

code:

using namespace std;

Thing::Thing() {}

Thing::~Thing() {}

void Thing::move_to(int n_x, int n_y, int n_z) {
  x = n_z;
  y = n_y;
  z = n_z;
}

Notes:
- If I call derp.move_to() it works fine, so the Living instance clearly inherits it from the Thing class.
- I use Code::Blocks with GCC on Windows, if it matters.
- All my headers are wrapped in #ifndef/#define, I just didn't include it here for clarity.

Senso fucked around with this message at 08:47 on Sep 11, 2012

# ? Sep 11, 2012 08:45

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!

Senso posted:

No matter what I do, I get the generic linker error:
main.o In function `main':
main.cpp 34 undefined reference to `Living::move(int, int, int)'

I'm sure it's a stupid mistake, but I just cannot understand why the linker cannot find Living::move(), when it's clearly defined and declared. I've seen many examples do pretty much the same thing as i do, but usually examples on the web are all in the same file for simplification.

Is it caused by spreading my classes in different files/headers and I'm not linking them properly or in the right order? This is something that confuses me a bit, coming from "simple" languages.

I'm not familiar with your particular tools, so I'll make a couple of guesses.

First guess: are you sure it's a linker error and not a compiler error? Your quoted code for main.cpp doesn't #include "living.hpp" (unless that was included within game.hpp, which we can't see).

Second guess: if it is a linker error, are you sure all the cpp files are included in the compile and link? Does your IDE show the command-lines it's executing? You'd need living.obj or living.o to exist and be included in the linking command line.

# ? Sep 11, 2012 08:59

Senso: Nov 4, 2005; Always working

roomforthetuna posted:

I'm not familiar with your particular tools, so I'll make a couple of guesses.

First guess: are you sure it's a linker error and not a compiler error? Your quoted code for main.cpp doesn't #include "living.hpp" (unless that was included within game.hpp, which we can't see).

Second guess: if it is a linker error, are you sure all the cpp files are included in the compile and link? Does your IDE show the command-lines it's executing? You'd need living.obj or living.o to exist and be included in the linking command line.

Yes, game.hpp contains:
#include "thing.hpp"
#include "living.hpp"
#include "map.hpp"

Here's the full build log:
Compiling: main.cpp
Compiling: map.cpp
Compiling: thing.cpp
Compiling: game.cpp
Linking console executable: bin\Debug\derp.exe
obj\Debug\main.o: In function `main':
E:/derp/main.cpp:34: undefined reference to `Living::move(int, int, int)'

In obj/Debug, I have game.o, main.o, map.o, thing.o so it looks like they were compiled fine. Code::Blocks does not seem to show the full command line used though...

EDIT: Huh, I don't have a living.o though, it looks like it was skipped. I feel like my stupid mistake is there, but I'm including living.hpp properly it seems.

EDIT: Yes, huh. It looks like CB somehow removed living.cpp from the project so it was not included in the compiling/linking. What a waste of time, ugh. I spent all this time trying to debug a weird IDE behavior. I should code with Notepad++...

Senso fucked around with this message at 09:13 on Sep 11, 2012

# ? Sep 11, 2012 09:04

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!

Senso posted:

In obj/Debug, I have game.o, main.o, map.o, thing.o so it looks like they were compiled fine. Code::Blocks does not seem to show the full command line used though...

What about living.o?

Edit: Yeah, including the hpp has nothing to do with compiling the cpp. You have to add the cpp to the project somewhere in the IDE or Makefile or whatever Blocks uses to define the project.

# ? Sep 11, 2012 09:08

nielsm: Jun 1, 2009

Senso posted:

Yes, game.hpp contains:
#include "thing.hpp"
#include "living.hpp"
#include "map.hpp"

Here's the full build log:
Compiling: main.cpp
Compiling: map.cpp
Compiling: thing.cpp
Compiling: game.cpp
Linking console executable: bin\Debug\derp.exe
obj\Debug\main.o: In function `main':
E:/derp/main.cpp:34: undefined reference to `Living::move(int, int, int)'

In obj/Debug, I have game.o, main.o, map.o, thing.o so it looks like they were compiled fine. Code::Blocks does not seem to show the full command line used though...

Note that it never says compiling living.cpp, your project is set up wrong somehow. I'm not familiar with Code::Blocks so I can't tell you what to do, unfortunately.

# ? Sep 11, 2012 09:08

Senso: Nov 4, 2005; Always working

4 hours chasing a typo, re-reading all the inheritance tutorials, only to find a stupid Code::Blocks error. I guess it's perfectly normal for experienced C/C++ programmers, you develop an eye for spotting config/makefile errors like that early. I'm too used to just launching "python mainfile.py" and if there's an error it tells me clearly why and where.

Oh well, at least I can move on now! :pseudo:

# ? Sep 11, 2012 09:18

Jamus: Feb 10, 2007

Sorry if this has already been answered on page 76 or something!

I'm wondering about the difference between putting stuff on the stack or the heap. I know the general recommendation is that large amounts of data go on the heap (as stack space has a limit), but I was under the impression that nearly all data containers ended up storing their stuff on the heap, so that in reality, a 100mb list stored on the stack only has a few pointers actually stored in the stack, the rest is on the heap.

This is relevant because a QT textbook I'm going through (G++ GUI Programming with QT) is always throwing its objects on the heap (and then not deleting them because the program is "trivial"), whereas my natural inclination is to put everything on the stack and trust that the library writers have been sensible within their own libraries. The internet seems to be all "Do whatever feels best" about the issue, but I really want to know the "right way". Can anybody help, or at least give me something to read that's a little deeper than basic definitions?

Edit: I know about the rare cases where an object needs to be referenced by several classes and such, but I rarely actually run into them, most of the time I find I can avoid it by writing the code a little more elegantly.

Jamus fucked around with this message at 10:46 on Sep 11, 2012

# ? Sep 11, 2012 10:43

nielsm: Jun 1, 2009

Jamus posted:

I'm wondering about the difference between putting stuff on the stack or the heap.

Will you be using the object after the function creating it returns? If "yes" or "not sure", then make a free-store allocation. "Auto" allocations (as C++ calls what almost always turns out to be stack allocations) are really only for short-lived things.

If you need something to outlive the function that creates it you will either need to allocate it on the free store/heap and return a pointer (better, a suitable smart pointer) to it somehow, or you will have to return the object itself which can very well start to involve copying of large amounts of data if you aren't careful. And of course, stack space is much more limited than the heap.

# ? Sep 11, 2012 11:07

Vanadium: Jan 8, 2005

Jamus posted:

I was under the impression that nearly all data containers ended up storing their stuff on the heap, so that in reality, a 100mb list stored on the stack only has a few pointers actually stored in the stack, the rest is on the heap.

This is relevant because a QT textbook I'm going through (G++ GUI Programming with QT) is always throwing its objects on the heap (and then not deleting them because the program is "trivial"), whereas my natural inclination is to put everything on the stack and trust that the library writers have been sensible within their own libraries.

You have it about right!!

If you put an object on the stack, it's necessarily fixed size so even a lovely library will have to allocate their additional memory needs on the heap. (There is stuff like std::array<> where it's just a struct with an array in there, but it's gonna be fairly obvious because you have to specify the size in the template arguments.)

There'd be the argument for putting poo poo on the heap so you can pass it by pointer without worrying about it going out of scope rather than copying it around, but you'll be worrying about just when to delete it anyway.

# ? Sep 11, 2012 11:49

That Turkey Story: Mar 30, 2003

I recommend always defaulting to the stack for objects unless you have a very specific reason to directly use the heap. If the object's lifetime has a clear scope, there is usually little reason to dynamically allocate, but if you do decide that it is a good idea, perhaps because it is a very large object, use something like std::unique_ptr. Remember that if you are using a dynamic container, as you already pointed out, it will generally be using the heap internally anyway.

Don't just start explicitly putting things on the heap for no reason. C++ excels with value semantics, especially C++11. That along with move-elision makes things a lot more efficient than what programmers often assume. Unless you are doing a lot of recursion, you're probably not going to have to deal with stack overflows. Also keep in mind that if you really want to, there are often ways to increase the size of your program's stack.

Jamus posted:

This is relevant because a QT textbook I'm going through (G++ GUI Programming with QT) is always throwing its objects on the heap (and then not deleting them because the program is "trivial"), whereas my natural inclination is to put everything on the stack and trust that the library writers have been sensible within their own libraries.

Do not look to QT for good programming practices.

Jamus posted:

Edit: I know about the rare cases where an object needs to be referenced by several classes and such, but I rarely actually run into them, most of the time I find I can avoid it by writing the code a little more elegantly.

It's good that you realize this already. A lot of programmers don't understand this. You should strive for simple, clear life-times of objects and types with very strict invariants. The less context a given programmer has to know in order to understand a given piece of code, the easier it's going to be to reason about. Also keep in mind that even when many objects do reference the same object, that doesn't necessarily mean that that object needs to have shared ownership or that it needs to be dynamically allocated at all. All too often I see people just always using dynamic memory allocation and always putting everything in shared_ptrs. That only leaves you with a complicated program with lifetimes of objects that are extremely difficult to understand.

# ? Sep 11, 2012 17:27

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

I've come to consider shared ownership a pretty strong code smell. It's not inherently terrible, but my experience has been that refactoring code to eliminate it nearly always results in cleaner and easier to understand code.

# ? Sep 11, 2012 17:44

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

I'm trying to write an asynchronous logging class and can't decide on when to write the logs to the file.

Right now, I'm thinking of storing all the logs in a vector and then sort them by their timestamps.

The problem is when should I write the logs to a file? If I wait for N logs before writing to disk, I might miss a log entry or one might be written to the log out of sequence if we already reached N logs in the vector.

I was thinking of maybe using a timer of some sort but I'm not sure if that would be any better.

I would appreciate any ideas, thanks.

Acer Pilot fucked around with this message at 00:55 on Sep 12, 2012

# ? Sep 12, 2012 00:49

b0lt: Apr 29, 2005

KNITS MY FEEDS posted:

I'm trying to write an asynchronous logging class and can't decide on when to write the logs to the file.

Right now, I'm thinking of storing all the logs in a vector and then sort them by their timestamps.

The problem is when should I write the logs to a file? If I wait for N logs before writing to disk, I might miss a log entry or one might be written to the log out of sequence if we already reached N logs in the vector.

I was thinking of maybe using a timer of some sort but I'm not sure if that would be any better.

I would appreciate any ideas, thanks.

Use a concurrent queue and have a thread that pulls stuff off of it and writes it immediately.

# ? Sep 12, 2012 01:06

seiken: Feb 7, 2005; hah ha ha

Ok so I'm sure I must have encountered this issue before but I'm not sure if there's a usual way to deal with it:

code:

class Foo { ... };

std::set< Foo* > some_foos;

bool is_there_a_foo( const Foo* foo )
{
    return some_foos.find( foo ) != some_foos.end();
}

const Foo* is clearly a reasonable type for the argument to is_there_a_foo - std::set doesn't know its template argument is a pointer type so it's not even going to dereference foo it let alone modify the pointed-to stuff. But find takes a const (Foo*)& which is not at all the same thing so this won't compile without a const_cast. This seems pretty basic so what's the done thing here?

seiken fucked around with this message at 01:18 on Sep 12, 2012

# ? Sep 12, 2012 01:12

ZombieApostate: Mar 13, 2011; Sorry, I didn't read your post.

I'm too busy replying to what I wish you said

Is there a reason you have to have Foo*'s in the set, or can you have just Foo's? Otherwise I think you can write a replacement comparison function so that it looks at the ~~pointer instead of the address of the pointer like it is trying to do~~ (derp) contents of the pointer instead of the pointer itself. I think the std containers are more designed to store instances than pointers. Or I could be totally miss-remembering this, I'm kind of sleep deprived right now.

ZombieApostate fucked around with this message at 02:27 on Sep 12, 2012

# ? Sep 12, 2012 02:21

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

b0lt posted:

Use a concurrent queue and have a thread that pulls stuff off of it and writes it immediately.

I just ended up using log4cxx. Anyone know of any issues with this library?

# ? Sep 12, 2012 04:07

seiken: Feb 7, 2005; hah ha ha

ZombieApostate posted:

Is there a reason you have to have Foo*'s in the set, or can you have just Foo's? Otherwise I think you can write a replacement comparison function so that it looks at the ~~pointer instead of the address of the pointer like it is trying to do~~ (derp) contents of the pointer instead of the pointer itself. I think the std containers are more designed to store instances than pointers. Or I could be totally miss-remembering this, I'm kind of sleep deprived right now.

Storing pointers in containers is a perfectly reasonable thing to do and a custom comparator has nothing to do with the argument types of the functions I'm afraid. My question is about how to be const-correct in a relatively simple situation without needing a const_cast

# ? Sep 12, 2012 10:22

Spek: Jun 15, 2012; Bagel!

Jamus posted:

This is relevant because a QT textbook I'm going through (G++ GUI Programming with QT) is always throwing its objects on the heap (and then not deleting them because the program is "trivial"), whereas my natural inclination is to put everything on the stack and trust that the library writers have been sensible within their own libraries. The internet seems to be all "Do whatever feels best" about the issue, but I really want to know the "right way". Can anybody help, or at least give me something to read that's a little deeper than basic definitions?

You rarely if ever want to put anything that ultimately inherits QObject(which is most of Qt's classes) on the stack or delete it directly because if a signal/event is being processed for that object when you delete it or when it goes out of scope you'll likely crash. Since QObjects automatically delete their children when you delete them as long as you make sure everything you create has a parent Qt will make sure you aren't leaking any memory. When you do need to delete a QObject manually call object.deleteLater(); on it rather than delete object; that'll delete the object in a way that's safe for Qt. The tutorials I learnt Qt from failed to mention all this and it was a bitch to debug the crashes that came of it.

Of course if you never connect() a signal to the object than it shouldn't matter and creating it on the stack should be fine. But better safe than sorry and always instantiating QObjects on the heap for consistency's sake is a good idea. In my opinion anyway.

# ? Sep 12, 2012 11:07

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

seiken posted:

Storing pointers in containers is a perfectly reasonable thing to do and a custom comparator has nothing to do with the argument types of the functions I'm afraid. My question is about how to be const-correct in a relatively simple situation without needing a const_cast

You just need a const_cast. All of the internal machinery in std::set wants to pass around values of the key type, not values of types to which the key type is convertible. One reason why is that that's all the comparator is known to support � you may have given your set a comparator that takes const Foo*s, but an arbitrary std::set of Foo*s is allowed to have a comparator that just takes Foo*s.

It comes down to philosophy. What types should you be able to pass to find()? There are two ways to answer that: intrinsic and extrinsic. There's only one type which you should intrinsically be able to pass to find(), and that's the set's actual key type, because the comparator promises to work with that. But extrinsically, you should be able to pass anything which can sensibly work with the comparator you've provided. The extrinsic answer is generally the more flexible and accepting answer, but it requires type-checking and rebuilding basically the set's entire search machinery with an arbitrary new type � i.e., in C++, it requires templating everything to hell and back. That in turn means inferior error messages, build times, generated code size, etc.

# ? Sep 12, 2012 11:43

seiken: Feb 7, 2005; hah ha ha

rjmccall posted:

You just need a const_cast. All of the internal machinery in std::set wants to pass around values of the key type, not values of types to which the key type is convertible. One reason why is that that's all the comparator is known to support � you may have given your set a comparator that takes const Foo*s, but an arbitrary std::set of Foo*s is allowed to have a comparator that just takes Foo*s.

It comes down to philosophy. What types should you be able to pass to find()? There are two ways to answer that: intrinsic and extrinsic. There's only one type which you should intrinsically be able to pass to find(), and that's the set's actual key type, because the comparator promises to work with that. But extrinsically, you should be able to pass anything which can sensibly work with the comparator you've provided. The extrinsic answer is generally the more flexible and accepting answer, but it requires type-checking and rebuilding basically the set's entire search machinery with an arbitrary new type � i.e., in C++, it requires templating everything to hell and back. That in turn means inferior error messages, build times, generated code size, etc.

Thanks, great answer, just wanted to make sure I wasn't missing something obvious & better (const_cast is what I've been doing so far)

# ? Sep 12, 2012 12:20

Sagacity: May 2, 2003; Hopefully my epitaph will be funnier than my custom title.

That Turkey Story posted:

Do not look to QT for good programming practices.

Is it still worth looking at QT for doing cross-platform GUI programming in C++? Or are there simpler alternatives (I've briefly looked at Juce a few years ago which seemed decent at the time) you'd recommend?

# ? Sep 12, 2012 13:01

Cat Plus Plus: Apr 8, 2011

Sagacity posted:

Is it still worth looking at QT for doing cross-platform GUI programming in C++?

Yes. There's also wxWidgets and GTK+, but they're not better.

# ? Sep 12, 2012 18:37

That Turkey Story: Mar 30, 2003

PiotrLegnica posted:

Yes. There's also wxWidgets and GTK+, but they're not better.

Pretty much this. GUI programming is just an unfortunately sad state of affairs in C++.

# ? Sep 12, 2012 18:44

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

gtkmm is quite nice. Do you have any issues with it?

# ? Sep 12, 2012 18:53

That Turkey Story: Mar 30, 2003

Suspicious Dish posted:

gtkmm is quite nice. Do you have any issues with it?

I haven't used it but it actually looks pretty good.

# ? Sep 12, 2012 19:19

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

gtkmm is nicer (and more idiomatic C++) in its interface than Qt is, but at their core any C++ bindings to GTK or any updates to the interface of Qt cannon do more than paper over the fact that both widget toolkits are clusterfucks

# ? Sep 12, 2012 19:32

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

Otto Skorzeny posted:

gtkmm is nicer (and more idiomatic C++) in its interface than Qt is, but at their core any C++ bindings to GTK or any updates to the interface of Qt cannon do more than paper over the fact that both widget toolkits are clusterfucks

I work on GTK+, so I'd be welcome to hear any suggestions or comments you have.

# ? Sep 12, 2012 19:42

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

1) Detonate GObject

2) THemes blow goat dick, fix them

_{I'm sorry these aren't very constructive it's been a long day}

# ? Sep 12, 2012 20:20

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

Otto Skorzeny posted:

1) Detonate GObject

No. I'd hate to get in a C/C++ discussion, and I understand GObject sucks in some parts (properties), but overall I really like GObject. What do you dislike about it?

Otto Skorzeny posted:

2) THemes blow goat dick, fix them

We are. Themes are now CSS (limited, but we're adding more every day, and believe me we'll never use CSS for layout).

Otto Skorzeny posted:

_{I'm sorry these aren't very constructive it's been a long day}

I understand.

# ? Sep 12, 2012 20:34

Cat Plus Plus: Apr 8, 2011

My problems with GTK+ usually revolve around Windows support being not-so-stellar. Maybe that improved, though it seems there are no official 3.x builds.

Either way never use wxWidgets.

# ? Sep 12, 2012 21:29

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

If I'm getting a "no overloaded function takes X arguments" error, and no other errors, and there's a function template that takes X arguments, is SFINAE probably suppressing the actual cause of my problem? (This is in Visual Studio.)

# ? Sep 12, 2012 21:50

Cat Plus Plus: Apr 8, 2011

GrumpyDoctor posted:

If I'm getting a "no overloaded function takes X arguments" error, and no other errors, and there's a function template that takes X arguments, is SFINAE probably suppressing the actual cause of my problem? (This is in Visual Studio.)

Could be. Can you post a minimised example code?

# ? Sep 12, 2012 21:52

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

I can try. This is one of those delightful problems where pulling a simple reproduction out of the code is at least as much work as just working around the original problem.

# ? Sep 12, 2012 22:00

That Turkey Story: Mar 30, 2003

GrumpyDoctor posted:

If I'm getting a "no overloaded function takes X arguments" error, and no other errors, and there's a function template that takes X arguments, is SFINAE probably suppressing the actual cause of my problem? (This is in Visual Studio.)

It's been a while, but I think it will tell you if substitution failed. You could always test it by purposely writing a template where substitution fails and try to call it, then see what the error message says. I.E.

code:

template< class T >
typename T::some_dumb_name_that_wont_be_there foo( T );

int main()
{
  foo( 4 );
}

I wouldn't be surprised if it's not visible (maybe the declaration isn't visible even though it might look like you included it I.E. because of some kind of circular inclusion problem), but again, I'm not that familiar with modern vc++ error messages.

# ? Sep 12, 2012 22:09

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 20:57

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

PiotrLegnica posted:

My problems with GTK+ usually revolve around Windows support being not-so-stellar. Maybe that improved, though it seems there are no official 3.x builds.

Either way never use wxWidgets.

Windows support is improved, and Alex worked on it a ton. There's no official builds, yeah, which is a thing we're working on, believe it or not. We're first creating nightly build infrastructure (Colin is working on this), and then we'll have Windows builds.

# ? Sep 12, 2012 23:38

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

«‹›641 »