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

«‹›10 »

Vanadium: Jan 8, 2005

Professor Science posted:

GUI Libraies
GTK

Fixed that. It is a nice wrapper that looks pretty C++ish and comes with a more comfortable signal/slots API than plain Gtk.

# ¿ Feb 16, 2008 18:48

Adbot: ADBOT LOVES YOU

# ¿ Apr 19, 2024 14:11

Vanadium: Jan 8, 2005

You are going to have to post some more code. Could you try reducing it to a testcase?

# ¿ Feb 22, 2008 22:53

Vanadium: Jan 8, 2005

Sure, just create all the observers on the stack or in an STL container.

Edit: Oops, I got that wrong. Nevermind what it said here before.

Vanadium fucked around with this message at 05:17 on Feb 25, 2008

# ¿ Feb 25, 2008 05:13

Vanadium: Jan 8, 2005

You seem to be missing std:: in front of bitset.

# ¿ Mar 9, 2008 04:10

Vanadium: Jan 8, 2005

JoeNotCharles posted:

A char is not an object.

Yes, it is.

# ¿ Mar 19, 2008 20:52

Vanadium: Jan 8, 2005

Internet research reveals that std::iterator is not supposed to be used as a base class for iterators. The entire point of the whole generic programming thing is that you do not need to derive from stupid classes just to make functions work on your types. std::iterators provide some typedefs to help meeting the iterator requirements I guess.

The definition given in the standard is

code:

namespace std {
  template<class Category, class T, class Distance = ptrdiff_t,
           class Pointer = T*, class Reference = T&>
  struct iterator {
        typedef T         value_type;
        typedef Distance difference_type;
        typedef Pointer   pointer;
        typedef Reference reference;
        typedef Category iterator_category;
  };
}

# ¿ Mar 24, 2008 00:10

Vanadium: Jan 8, 2005

I am pretty sure that fflushing input streams does not do anything.

# ¿ Apr 11, 2008 16:54

Vanadium: Jan 8, 2005

Ugg boots posted:

From the man page:

code:

Flushing  an  input  stream  discards any buffered input and
adjusts the file pointer such that the next input  operation
accesses  the  byte  after  the  last one read.

It does not say that in my manpage. Are you sure you are not missing some "conforming to" part?

# ¿ Apr 11, 2008 19:26

Vanadium: Jan 8, 2005

No, current buffer contents have nothing to do with the size of the underlying file.

# ¿ Apr 22, 2008 22:14

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

Vanadium: Jan 8, 2005

This totally would not have happened if you were actually using C++ properly

# ¿ May 2, 2008 16:15

Vanadium: Jan 8, 2005

HB posted:

When using all except the last, make sure the struct's real name is different from the one created by the typedef.

Why?

# ¿ May 3, 2008 02:33

Vanadium: Jan 8, 2005

From the boostcon thread:

The Red Baron posted:

To keep this post slightly more on-topic, how long should we expect to have to wait before C++0x is incorporated in most major compilers, assuming that they actually manage to get the standard out next year? For GCC I'm sure it won't be long at all, but it'd suck if we had to wait an entire Visual Studio cycle before the vcpp compiler got upgraded

The gcc guys list a bunch of features they already implement at http://gcc.gnu.org/gcc-4.3/cxx0x_status.html, and Herb Sutter has alluded that MSVC already implements a bunch of stuff as well. To be honest, I expect MSVC to have a "complete" implementation sooner than gcc.

# ¿ May 3, 2008 12:18

Vanadium: Jan 8, 2005

I do not think the language guarantees absence of padding in any case, with or without inheritance.

# ¿ May 5, 2008 23:09

Vanadium: Jan 8, 2005

Or you could just use boost::add_pointer<int>::type foo, bar; to avoid any confusion or ambiguity.

# ¿ May 15, 2008 00:07

Vanadium: Jan 8, 2005

TheSleeper posted:

Is using T *tPtr no good?

Not if T is a reference. I do not think I ever ran into that case, though.

# ¿ May 15, 2008 08:27

Vanadium: Jan 8, 2005

That sure will go over well in a data structures/algorithms class.

# ¿ May 21, 2008 17:01

Vanadium: Jan 8, 2005

cliffy posted:

If you were doing software development in the real world, then Ping's answer would be correct 99.999...9 % of the time. The biggest boon to productivity is access to libraries that have been thoroughly used, bug-tested/fixed, and tons of space/time efficiency tricks that you never would have thought of or taken forever to get right.

All the hay-we-are-using-c++-in-the-industry seem to hate the STL anyway and roll their own non-generic containers :iiam:

Also I think if you are posting on SA about how to implement your own container you are probably not doing software development in the real world.

# ¿ May 21, 2008 20:03

Vanadium: Jan 8, 2005

They look like those ANSI escapes used to get colored text on terminals. :shobon:

# ¿ May 27, 2008 21:41

Vanadium: Jan 8, 2005

ehnus posted:

Why can't I do something like
cout <<< fill('0') << width(8) << hex << 0xc0ffee << endl;
instead?

Because they are called setfill and setw respectively.

quote:

Why do I manually have to remember and reset the fill and width parameters for the next field I want to output?

No argument there, you have to do it with printf too.

Personally I find a set of member functions or iostream manipulators to define formatting much more intuitive than a formatting "DSL" that is interpreted by *printf at runtime. We all hate DSLs, no?

iostreams are also probably more flexible than having to generate format strings at runtime, if you want more dynamic formatted output, and of course printf cannot be used to print user-defined types.

Is there any existing alternative to iostreams that could be incorporated into the next standard?

# ¿ May 30, 2008 08:23

Vanadium: Jan 8, 2005

Insurrectum posted:

Like this? I assume not, because it doesn't compile.

code:

void linkrooms(Room *room, Room *room2, char d) {
    switch (d) {
        case 'n':
            room.setnorthroom(&room2);
            room2.setsouthroom(&room);
            break;

You need to dereference the pointer to get the object it is pointing to.
(*room).setnorthroom(&room2); or, more concise, room->setnorthroom(&room2);.

A basic book or tutorial on C(++) should cover all this so you can get on with the actual program.

# ¿ Jun 4, 2008 08:24

Vanadium: Jan 8, 2005

Smackbilly posted:

Tbe biggest advantage is that enums are typesafe, so you will not need that extra "assert" statement to check that the parameter is in the valid range. If you have:

room->link(0, Direction(14));

# ¿ Jun 5, 2008 12:47

Vanadium: Jan 8, 2005

Also you cannot have a static const NUMDIRECTIONS field in C.

# ¿ Jun 6, 2008 14:28

Vanadium: Jan 8, 2005

It is not browser specific, the forums do the substitution. You can tell by looking at the source. :ssh:

# ¿ Jun 25, 2008 17:28

Vanadium: Jan 8, 2005

Fun, I get a pi symbol if I use the View Selection Source button, but a &pi if I use the regular View Source one. Blaming a javascript substitution :argh:

Vanadium fucked around with this message at 21:08 on Jun 25, 2008

# ¿ Jun 25, 2008 21:05

Vanadium: Jan 8, 2005

Yeah. The syntax is what you would expect.

# ¿ Jul 1, 2008 23:24

Vanadium: Jan 8, 2005

You need to #include <string> to use std::string.

# ¿ Jul 2, 2008 14:21

Vanadium: Jan 8, 2005

floWenOl posted:

01:52 <@floWenoL> something like 'if you're calling out to C++ _from perl_ to parse log files you don't know perl as well as you think you do'

I like C++ and all but perhaps you should stick to perl for your text processing needs.

# ¿ Jul 3, 2008 00:53

Vanadium: Jan 8, 2005

floWenoL posted:

Unless someone overrode operator& for vectors somewhere before.

Just use boost::addressof!!

# ¿ Jul 21, 2008 20:44

Vanadium: Jan 8, 2005

Entheogen posted:

OK, so STL overloaded & operator for vectors to copy them?

No, but if floWenoL did, the STL code might not work anymore.

# ¿ Jul 22, 2008 00:19

Vanadium: Jan 8, 2005

(This is becaue floWenoL hates the STL and likes to break it)

# ¿ Jul 22, 2008 03:39

Vanadium: Jan 8, 2005

Sabotaged posted:

If I declare a regular std::string foo, it would automatically allocate itself on the heap I'm assuming? Does it use reference counting or something to determine when to automatically delete itself?

What about string's c_str? Where is this memory? I assume there are no guarantees using this memory outside the immediate scope of the string?

The string object is on the stack. Then it goes and allocates a bunch of memory on the heap for the string data. This memory will be deallocated when the string object itself goes out of scope. This is achieved by the string object's destructor.

The c_str() memory is on the heap, too. There are indeed no guarantees about using that memory outside the immediate scope of the string. You are not even guaranteed that it is usable if you edit the string after calling c_str(), I think.

# ¿ Jul 22, 2008 04:27

Vanadium: Jan 8, 2005

It's the C++ thread, not the your-C++-compiler thread. :mad:

# ¿ Jul 22, 2008 18:02

Vanadium: Jan 8, 2005

litghost posted:

Fair, but the realities of C++ mean that you will encounter bugs that are "against" the spec, but practically can exist. Putting you head in the ground and saying that they are impossible does not change the fact they can exist.

I just get a bit annoyed, for some reason, when some people blame C++ if their compiles do not detect the mistakes in their code.

Now, for something, completely different, what is up with enum foo { a = 1, b = 2 }; foo f = a; f |= b; not being legal? Am I supposed to roll my own "flags" class?

# ¿ Jul 22, 2008 22:35

Vanadium: Jan 8, 2005

You are obviously doing it wrong because every C++ compiler, especially g++ used in Dev-C++, supports strings as struct members.

You will want to get a better book.

# ¿ Jul 23, 2008 23:12

Vanadium: Jan 8, 2005

Avenging Dentist posted:

Does anyone here know if anything has happened lately with the extensible literals proposal for C++0x? (I'm looking at you, TTS.) I feel like I'm the only one looking forward to it, just because it would allow the following:
code:
tuple<T0,T1,T2,T3,T4> tup;

// Old way:
tup.at<1> = T1("woop woop");
// New way:
tup[1c] = T1("woop woop");

Would that not be about making operator[] a constexpr thing?

# ¿ Jul 25, 2008 21:53

Vanadium: Jan 8, 2005

Gtk is a GUI toolkit thing with buttons and menus and and dropdown boxes and poo poo, SDL is a 2D graphics thing where you just draw stuff on the screen on your own. They do not really have the same purpose.

# ¿ Jul 30, 2008 14:42

Vanadium: Jan 8, 2005

Senso posted:

OK I get it now. I don't have anything clear but I want to try my hands at a roguelike-style game, in ASCII. In that case, I'm wondering if using a GtkLayout or GtkDrawingArea to display a bunch of separate characters moving independently would work or if SDL (or say, ncurses for pure console mode) would be better for that.

If you want to do the main game display "roguelike" and have a bunch of regular menus (like, say, an inventory list or whatever), you could probably well use Gtk for that. But if you want a fullblown roguelike, just go with ncurses.

# ¿ Jul 30, 2008 16:46

Adbot: ADBOT LOVES YOU

# ¿ Apr 19, 2024 14:11

Vanadium: Jan 8, 2005

Perhaps to make it clear you are talking about the project and not the namespace/class/function [template].

vvvv < :mad:

Vanadium fucked around with this message at 23:32 on Aug 2, 2008

# ¿ Aug 2, 2008 22:38

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

«‹›10 »

Professor Science posted:

more falafel please posted:

JoeNotCharles posted:

code:

Ugg boots posted:

code:

code:

HB posted:

The Red Baron posted:

TheSleeper posted:

cliffy posted:

ehnus posted:

quote:

Insurrectum posted:

code:

Smackbilly posted:

floWenOl posted:

floWenoL posted:

Entheogen posted:

Sabotaged posted:

litghost posted:

Avenging Dentist posted:

code:

Senso posted: