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

«‹›4 »

OddObserver: Apr 3, 2009

Zakalwe posted:

Wrong question. You're trying to compile x86 asm for an ARM CPU. Not going to happen.

These 2 look portable to C, albeit I am not sure about the idiv --- it's a 64-bit over 32-bit division, isn't it?

# ¿ May 8, 2009 18:51

Adbot: ADBOT LOVES YOU

# ¿ May 2, 2024 21:38

OddObserver: Apr 3, 2009

rjmccall posted:

(added punctuation to clarify how I'm parsing your sentence)

In pretty much every standard environment, yes, the built-in operator new and operator delete are implemented using malloc and free.

Not quite. delete also performs pointer adjustment in the multiple-inheritance case --- trying to delete a 2nd sub-object works (well, at least if there is a vtable..), while free'ing it will crash/corrupt the heap.

# ¿ Sep 25, 2009 01:41

OddObserver: Apr 3, 2009

The Red Baron posted:

What I'm doing is trying to create a babby Python JIT from scratch (i.e. no CPython involved at all) just for the fun of it, so my current approach is stolen from Unladen Swallow. Since all python function invocations have to return a valid object unless an exception is thrown, I just do an explicit is-null check after every single object/function invocation that may throw and do the rvalue+local var unwind if it's true. It's not very pretty at all since it adds a ton of branching but i suppose regular C++ exceptions might be too slow in the end anyway since python uses exceptions for normal control flow (ugh)

Almost sounds like the classical approach of a stack of handler addresses would be
the most appropriate here. How much cleanup do you need to do, anyway?

# ¿ Oct 26, 2009 03:40

OddObserver: Apr 3, 2009

Contero posted:

Is there a sign function? i.e. sign(-2.3) -> -1

I've always just done val/abs(val), but this is a little gross / bad if val == 0.

There is a signbit(). Seems like C99 if I am reading this right:
http://www.opengroup.org/onlinepubs/000095399/functions/signbit.html

... Note that I am sure of what it does for negative 0. Maybe that's negative, and positive 0 is positive?

# ¿ Oct 31, 2009 23:05

OddObserver: Apr 3, 2009

Using reference for trees would also be rather annoying, considering you can't just set them to null...

# ¿ Dec 10, 2009 00:13

OddObserver: Apr 3, 2009

RussianManiac posted:

It is a super class that has virtual methods in it, yes, but also has a member variable.

A virtual superclass isn't the same thing as a superclass with virtual member functions.

Edit, to be at least somewhat helpful: When doing inheritance, besides just saying
Foo: public Bar, you can also say Foo: public virtual Bar. You need the 'virtual'
to put things to be a diamond, and not to have 2 copies instead. I'll leave the details to you
or more helpful posters.

# ¿ Dec 24, 2009 00:57

OddObserver: Apr 3, 2009

It's probably a better idea to rename your own 'div' function and its uses rather than messing with the system ones. On ELF systems (e.g. Linux, FreeBSD, etc.), your implementation may end up overriding global 'div' symbol even when it's called from within the standard libraries internally, causing stuff to blow up in weird ways, unless you're ultra careful.

# ¿ Dec 28, 2009 19:05

OddObserver: Apr 3, 2009

functional posted:

I'm statically compiling in a separate malloc which does weird things with dynamically linked functions like strdup that call their own malloc from the library. I know that I can do invasive things like changing LD_PRELOAD to cause strdup to use a different malloc. Is there anything less invasive I can do to cause strdup to rely on my statically linked malloc? Currently I'm just using my own implementation of strdup. In the future I imagine I will encounter situations where I won't be able to use that method.

ELF? It should do it by default, actually, unless you played with visibility (and unless strdup calls a symbol other than malloc). Which is why it's so dangerous to
mess with these.

# ¿ Feb 13, 2010 18:21

OddObserver: Apr 3, 2009

functional posted:

I don't understand your post. I am working on a UNIX-compatible system and compiling with gcc. The call free(strdup(str)) always fails contrary to the manual specification. Since I have implemented my own malloc and free this indicates to me that strdup is calling some other malloc. Can you explain what you mean?

What system in particular?

I mean that normally ELF symbols are global, so there is only a single malloc symbol for the whole program unless you specially try to avoid it. That means that if strdup calls malloc it should call your malloc --- but it might also be calling some sort of __system_malloc or whatever (or the inside-libc calls might be optimized to go directly to the default malloc implementation). There in lies the danger since you could potentially end up with library calling a mixture of the two heap managers.

At any rate, on my Linux machine

code:

void* malloc() {
    abort();
}

int main() {
    strdup("foo");
}

end ups calling my malloc w/o any extra effort.

# ¿ Feb 13, 2010 23:10

OddObserver: Apr 3, 2009

Anunnaki posted:

This is getting really frustrating.

The compiler is crashing. I'd suggest checking for updates, as well as running a memory test and making sure your machine isn't overheating.

Edit: also, independent of that, if you have decent broadband you could just grab binaries for Qt-on-mingw -- no need to build the library yourself:
http://qt.nokia.com/downloads/sdk-windows-cpp

OddObserver fucked around with this message at 07:14 on Feb 16, 2010

# ¿ Feb 16, 2010 07:11

OddObserver: Apr 3, 2009

Erk, why not jut "return new Car;" ?

# ¿ Feb 28, 2010 05:40

OddObserver: Apr 3, 2009

Genpei Turtle posted:

Is it possible for the same variable to occupy two different locations in memory and if so how would that sort of situation come about?
I ask because I've been trying to troubleshoot a program that's been displaying some bizarre behavior by outputting a variable and its address every iteration of a loop it's supposed to be changing. While reading the output I noticed the address seemed to be in two places--once at address 0x3D27C4 and then again at 0x3D2584. Which instance got changed during the loop appeared to be more or less a crapshoot. If it makes any difference this particular variable is a data member of a derived class. (which is also present in the parent class) It's just a plain old int, nothing fancy like a pointer or an object or anything else.

Sounds like it's two different objects.

# ¿ Mar 18, 2010 18:28

OddObserver: Apr 3, 2009

LockeNess Monster posted:

For syntax highlighting, code folding and code formatting? Also I occasionally use refactoring tool in Eclipse.

Meh, I should probably pick up Visual Studio, but right now all of my C++ development needs are satisfied by using Eclipse in Ubuntu running in my VMWare.

You don't need an IDE for the first 2, and real men don't write code that needs reformatting ;-). But why not use Eclipse on Windows too, if you like it?

# ¿ Mar 19, 2010 02:54

OddObserver: Apr 3, 2009

Contero posted:

Has anyone ever dealt with changing layouts in Qt? I want to change between two different layouts, and they aren't as simple as swapping vertical alignment with horizontal alignment. I have nested layouts with spacers and two widgets I don't want to destroy every time the layout changes. I have pointers to these widgets, but I haven't been able to reparent them successfully.

I'd have thought this would be a standard feature for Qt but I've gone through the documentation and searched the mailing lists and can't seem to find a good answer or one that isn't as painful as having to reconstruct all of my widgets every time I want something to change position. Please tell me I'm just missing something obvious.

QWidget::setLayout says to delete the previous layout (on the container, that is) to be able to set the new one. QLayout::addChildWidget can also move things around layouts, but whines doing that (and is documented as such). Looking around the code suggests that should work.

# ¿ Mar 30, 2010 14:15

OddObserver: Apr 3, 2009

Contero posted:

Well deleting a layout deletes all of its children, in this case my widgets that I don't want deleted.

Did you test that, or are just assuming? I was concerned about the same thing, and glance through destructors... didn't seem like it was actually destroying them.

quote:

I've tried to reparent them to a temporary widget then add them again but I don't think it worked. Maybe I was doing things in the wrong order.

I could probably make some sort of smart pointer wrapper around QWidget, but it seems like a bit of a hack to do something that should be in Qt by default.

Well, moving them to the new layout (adding it to them) may work, but will likely spam the terminal with warnings. I am quite surprised but what you're doing, though, hard to picture what it'd be good for --- all scenarios I can think of can probably be handled by just using a QStackedWidget or something.

# ¿ Mar 30, 2010 19:56

OddObserver: Apr 3, 2009

Comma confusing a macro, perhaps?

# ¿ Apr 5, 2010 05:16

OddObserver: Apr 3, 2009

LockeNess Monster posted:

How do i get around the problem of using functions that take arguments by reference when I pass some intermediate result to them?

something like...
code:
void foo(string & a)
{...}

....
string z ="whateva";
foo( whateva + "lolz" );
In the form I gave there, it won't compile.

It will work if foo takes a reference to a const (e.g. const string&).

(And g++ is surprisingly helpful with its error message on your example:

code:

/tmp/tc.cpp:9: error: invalid initialization of non-const reference of type �std::string&� from a temporary of type �std::basic_string<char, std::char_traits<char>, std::allocator<char> >�

# ¿ Apr 10, 2010 04:50

OddObserver: Apr 3, 2009

Avenging Dentist posted:

Where's the ugly part? Everything there looks a-ok, but maybe I'm not looking at the right spot?

Line 33. It modifies the < order of elements in the set.

# ¿ Apr 17, 2010 23:38

OddObserver: Apr 3, 2009

Plus, you could just write const char* filename = "f.txt".
Don't hand-count stuff the computer can count for you --- you may make a mistake.

# ¿ May 2, 2010 20:36

OddObserver: Apr 3, 2009

Magicmat posted:

Quick QT question (I didn't see a QT thread here, so this is the next best place, I guess.)

I'm trying to make a simple app, that has a main window with some controls on the upper half (a few buttons, and a textbox) and a QListView on the bottom half. See:
code:
 ____________________________________________
| File   Help                               |
|  ___________  ____________                |
| [Start Timer] [Stop Timer]  [_00:02:33__] |
|                                           |
|  _______________________________________  |
| |__Time 1________________00:27:19_______| |
| |__Time 2________________00:14:00_______| |
| |__Time 3________________00:05:29_______| |
| |_______________________________________| |
| |_______________________________________| |
| |_______________________________________| |                                            
|___________________________________________|
I tried using a QSplitter, with the QListView on the bottom and a QWidget at the top, and that worked with the resizing part OK, but I don't want the user to be able to move the split around like that, and plus the top half still has the same problem as using a blank QWidget as a central window.

I'm brand new to Qt, so I must be missing something obvious, but help me out here.

Set a QVBoxLayout as the layout for that widget.

Add a child QHBoxLayout.
Add buttons and time as child of the horizontal layout

Add the QListView.

The size would be split in the sensible way automatically.

# ¿ May 4, 2010 01:59

OddObserver: Apr 3, 2009

Zakalwe posted:

Worse than Whitesmiths and GNU? Surely you jest.

I don't think any of those styles introduce a risk of the code reader entirely missing a line of code at the beginning of the block...

# ¿ May 10, 2010 03:17

OddObserver: Apr 3, 2009

SintaxError posted:

I'm just refreshing my C++ knowledge after a few months in Java/scripting languages, and I'm running into a bit of trouble. I think it has something to do with a destructor, but I'm not sure what exactly. My program runs fine in debug mode until I try to delete one of my tableEntry objects, at which my program receives a SIGTRAP signal.

Problems I can see from quick read:

0) Unless you're doing some class homework with restrictions on legit language functionality, you should not be working with strings this way in a C++ program. Use a string class, like std::string (or std::wstring, or whatever)

1) When you're copying strings, you're not including space for zero termination in the allocation.

2) Whatever you allocate with new[] you should delete with delete[], not delete.

# ¿ May 17, 2010 07:42

OddObserver: Apr 3, 2009

The main problem with doing things a certain way because 'it's a small app' when learning is that anything real you make won't be small, so it'll be harder to establish whether the shortcuts you take are actually safe.

And in most real things, you likely won't know what parts are performance-critical until you profile, anyway, or whether the performance even matters (if you're taking 2ms vs. 1.8ms, it's probably not worth the effort).

C-style strings are actually a problematic approach when you're trying to be fast, too, since they do not express ownership, so in general you may end up making far more deep copies than, say, with a reference-counted COW string class, or more allocations than with a small-value optimization string class.

I think an important thing to keep in mind with C++ is that abstractions can be /good/ for performance work, since they put a lot mechanics of how stuff works in one place, letting you improve it w/o having to rework everything --- and C++ gives you a lot of tools like inlining and templates to eliminate the abstraction overhead itself.

# ¿ May 17, 2010 19:25

OddObserver: Apr 3, 2009

std::memcmp might help you (doesn't give you the index of difference, which you might need based on your pseudocode, though).

Edit: why are you using a float texture format?

# ¿ May 26, 2010 00:22

OddObserver: Apr 3, 2009

Vanadium posted:

Clearly if they just switch to C++ (that is, saying class instead of struct and maaaaaybe using member functions), they will catch up to clang in no time!

Well, at least more of them might notice just how slow compiling C++ code is with gcc.

# ¿ Jun 1, 2010 19:06

OddObserver: Apr 3, 2009

MrMoo posted:

If we're talking basic C data types the compiler can keep a variable in a register and never have to move the stack. The location of declaration can help determine whether a variable should be memory or register based.

And spill slots can be overlapped as well, as long as their live ranges are distinct. Though, it is an issue of quality of implementation, of course.

# ¿ Jun 5, 2010 03:08

OddObserver: Apr 3, 2009

Mr.Radar posted:

On the other hand, there might be another way to do what you're trying to do that doesn't involve hacking custom APIs into your OS. If you would post more details about your setup (OS and soundcard) and the ultimate goal you're trying to achieve we could probably point you in the right direction.

On Linux, it might be doable user-level as some sort of an ALSA module (assuming apps use ALSA, but most can be configured to); but that might just be harder than messing with the sound driver.

# ¿ Jun 21, 2010 06:19

OddObserver: Apr 3, 2009

What OS are you running, shrughes? Is it a BSD by any chance?

# ¿ Jun 28, 2010 07:13

OddObserver: Apr 3, 2009

shrughes posted:

Mac OS X Snow Leopard

I see. Looking at it, its memory allocator doesn't store heap information for sufficiently small allocations inline. Neither does FreeBSD's phkmalloc, which has a pretty unorthodox design.

Linux/glibc use a very classical design --- it's a derivate of dlmalloc, which is basically an ultra-well engineered version of the algorithms one would find described in TAOCP... So on a 32-bit machine, altering the code in the obvious way, for the string array you'll find something like:

p[-2]: 0x49
p[-1]: 0xf
p[0]: 0x804a884
p[1]: 0x804a89c
p[2]: 0x804a8b4
....

Here, it conceptually allocates (15+1)*4 = 64 bytes for the array plus the non-POD operator[]'s size storage[1]. The 0x49 is 72 + 1, with the 1 being a a bitfield denoting that previous block isn't free, with 72 being some sort of internal size. The difference between 64 and 72 is for 4 bytes of overhead, +4 bytes for... bah, it's too late and I am too tired to figure it out. Anyway, the most important property of such allocators when it comes to this discussion is that:

1) If you have a pointer to the beginning of the block, you can figure out the size easily... But for a non-POD, the pointer won't be to the beginning of the block if new[] was used, due to the hidden size field --- and whether that's the case or not, that can't be determined from just the type.

2) If you have a pointer somewhere in the heap, it is actually possible to determine the size of the block --- but you pretty much have to walk the entire drat heap to figure it out, though there may be some shortcuts based on page management and the like. Fancier designs might actually be able to do it easier, depending on the kind of data structures they use.

[1] Interestingly the size is stored in the caller code directly -- both the POD and non-POD versions call _Znaj; and delete[] on a non-POD actually emits an entire loop.

# ¿ Jun 28, 2010 08:11

OddObserver: Apr 3, 2009

Mr.Radar posted:

There isn't anything like that in the STL because there's no efficient way to implement it.You would either need to do a linear search through an array upon each insert or you would need to store the elements twice: once in a set and once in a vector. You could trivially roll your own using either technique, depending on whether space or time efficiency is more important to you.

Edit: I assume by "position" you mean insertion order? If you don't, then there may be something that will do this efficiently, just not in the STL.

Uhm, for insertion order, you just cross-link your hash/tree data structure with a doubly-linked list. Very small constant-factor overhead for all set operations, though of course it may be too much if the data structure is extremely hot. Heck, Java even provides one of these in its standard library (LinkedHashSet<E>)

If he means position based on a sort order, that's doable, too, by using a balanced tree (or a similar data structure) augmented by size of each subtree. It's O(log n) for every operation, of course, but that's unchanged from having this sort of container anyway, either.

# ¿ Jun 28, 2010 18:18

OddObserver: Apr 3, 2009

I suggest you learn to use valgrind...

# ¿ Jul 4, 2010 03:57

OddObserver: Apr 3, 2009

Rocko Bonaparte posted:

I wonder generally under the hood if it's efficient to iterate compared to, say, keeping a hash map and a linked list in sync.

It's a red-black tree or a comparable data structure (e.g. skip-list). So insertion/look ups, etc., are logarithmic cost, and /sorted/ traversal is linear.

# ¿ Jul 14, 2010 05:52

OddObserver: Apr 3, 2009

Googling for that comment finds this:
http://profile.iiita.ac.in/IEC2008063/Documents/study/imp books/adc/Microsoft Visual Studio 9.0/VC/ce/crt/src/xexp.c

And a bunch of similar files. Seems like some sort of source file for FP routines in MSVC runtime library has some floating point array, and the auto-completion indexed it somehow.

# ¿ Jul 16, 2010 06:09

OddObserver: Apr 3, 2009

Pretty much the most (only?) sensible way of implementing a std::vector<T>::iterator is as a struct/class that contains only a T*. No allocations or other heavy-duty stuff involved. If anything, putting it into a local may end up wasting memory.

.. And extending scope of variables beyond when they're needed is a bad idea. For example, if you're not careful, you might end up using the same "cached" iterator in 2 functions that may end up (perhaps indirectly) called from each other.

# ¿ Jul 17, 2010 04:27

OddObserver: Apr 3, 2009

If you want custom validation in a Qt MVC widget, you can create and set a delegate that overrides the createEditor method; see http://doc.qt.nokia.com/latest/model-view-delegate.html#providing-an-editor

And no, you can't override a non-virtual and have the superclass call the child class version. It's impossible.

# ¿ Jul 25, 2010 16:20

OddObserver: Apr 3, 2009

That's not the superclass calling the child version. You're calling the child version, which in turn calls the parent version.

I was sort of wrong considering the whole:
class ChildClass: public Foo<ChildClass> pattern, though, but that doesn't apply here anyway (I was thinking of a -fixed- base)

# ¿ Jul 25, 2010 16:35

OddObserver: Apr 3, 2009

Also, isn't tolower locale-sensitive? Using a simple specialized inline version may be measurably faster if that's that hot.

Edit #2: also, if you're using an std::map, you'll be doing a log number of comparisons, so you probably want to tolower once in advance.

OddObserver fucked around with this message at 06:40 on Aug 2, 2010

# ¿ Aug 2, 2010 06:37

OddObserver: Apr 3, 2009

Aren't you changing the image as you're blurring it? If so, then the computation for the subsequent pixels may get badly screwed up as they'll refer to new values other than old ones.

Edit: might also need to clamp your output to make sure it's in range. Not sure w/o looking at the math really carefully (and even then I personally probably won't know).
Edit #2: you also seem to be running off the edges there.

OddObserver fucked around with this message at 16:29 on Aug 5, 2010

# ¿ Aug 5, 2010 16:26

OddObserver: Apr 3, 2009

Uninitialized field, perhaps? ...Maybe the pgm_getaddrinfo call returns 0 addresses but doesn't fail? (I am not familiar with those APIs at all)

Edit:
VVVVVVVVVVVVVVVVVVVVVVVVVVVV
Sorry. I completely misread the question. Very weird indeed. Did you try ultra-clean builds cleaning out PCHes and stuff like that?

Edit #2:
What it seems to say is that what the debugger things of the layout of structure is different from what the compiler thinks.
32/64-bit mismatch, maybe?

OddObserver fucked around with this message at 04:59 on Aug 6, 2010

# ¿ Aug 6, 2010 04:32

Adbot: ADBOT LOVES YOU

# ¿ May 2, 2024 21:38

OddObserver: Apr 3, 2009

I think you need to use 'typename DG::Node' and not 'DG::Node' in this sort of a templated context to help disambiguate some parsing complications.

# ¿ Aug 20, 2010 20:44

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

«‹›4 »