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

«‹›2 »

feedmegin: Jul 30, 2008

Contero posted:

I've been thinking about making a simple script that reads a file and produces a .c file that contains the entire file written as a byte array.
code:
char fileData[2048] = { 0x0A, 0x0B ... 0xAB };
This packs the file into the executable without having to use something platform specific like ELF or windows resource files, or dealing with a library like Qt. And it makes getting at the data as straightforward as possible.

What's the downside to this? Would this cause performance issues that ELF or rc files wouldn't? Is there some limit to global data that I'm not aware of?

You should be fine doing this - I believe that's precisely how the Qt resource mechanism works, and I can't off the top of my head think of any limits that wouldn't hit you in any case (like > 4 gigs on a 32-bit system or whatever).

# ¿ Feb 6, 2012 21:18

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 19:57

feedmegin: Jul 30, 2008

Jam2 posted:

Why is this invalid in C? Are parameters not considered in function signatures?

Correct. What matters is the raw function name. (which is why C compilers, unlike C++, don't have to do name mangling)

# ¿ Feb 22, 2012 20:12

feedmegin: Jul 30, 2008

Rocko Bonaparte posted:

Man all of this talk reminds of an phone interview I think I bombed. They wanted to know what would happen if I returned a pointer to a stack variable in a function. I think the answer they wanted was "instant crash," but I told them instead was a ticking time bomb based on how it was compiled and the system's memory management rules. So I was trying to go through one way where it would crash the first time the referenced data was touched outside the function, and I don't think they wanted any of it. These folks weren't explicitly using x86 or some particular OS so I couldn't just peg it to one thing or another.

If that was actually the answer they wanted you probably didn't want to work there anyway. Given most systems (with virtual memory) use 4k pages and given most stack frames are small, an instant crash would actually be fairly unlikely if it was dereferenced right away.

# ¿ Mar 1, 2012 18:32

feedmegin: Jul 30, 2008

dynamic_cast gives you a null pointer (when used with a pointer) not an exception.

# ¿ Aug 5, 2015 19:12

feedmegin: Jul 30, 2008

Nippashish posted:

What is wrong with trigraphs? Can't you just not use them? I would have no idea what trigraphs even were if it weren't for people on the internet complaining about how terrible they are.

With di/trigraphs, you can't define a function called, for example, 'or', because that gets interpreted as ||. That's kind of sucky in my opinion given the only reason they were in the standard is ancient sucky IBM kit.

Edit: looks like digraphs are still in though?

With trigraphs the problem is more string constants -

puts("What??!??!");

will not print what you might expect.

feedmegin fucked around with this message at 11:46 on Sep 24, 2015

# ¿ Sep 24, 2015 11:43

feedmegin: Jul 30, 2008

Star War Sex Parrot posted:

I don't really find myself mixing C and C++ libraries very much, but I think if you want to use the C STL in C++ you should to include it as <cstdlib>, not <stdlib.h>

Try that first, I guess.

edit: I don't use MSVS so I had to look up what stdafx.h was. Huh.

Should maybe but it should work the other way too.

# ¿ Nov 6, 2015 20:35

feedmegin: Jul 30, 2008

Joda posted:

I did some testing and you're right; removing -static from the list of flags fixes the issue. However, I'm still linking four other libraries (on top of glibc and libsdc++) statically; only I'm doing it by compiling them alongside the project, as opposed to linking them with a compiler flag. How are these two fundamentally different? I'm still just compiling a library file, then linking it against my main executable at the end.

E: Not to mention the fact that it actually works as intended on MinGW with the -static flag?

A static library (collection of .o files that will be copied into your eventual, dynamically linked program) is different from using the -static gcc flag (try and make a program only out of static libraries, no shared libraries at all not even libc). The only reason you'd do the latter is for compiling things like basic utilities in /bin that you want to work even if you somehow mess up/delete glibc.

# ¿ Dec 7, 2015 12:28

feedmegin: Jul 30, 2008

netcat posted:

pre:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x5580f106 in memcpy () from libc.so.6
(gdb) bt
#0  0x5580f106 in memcpy () from libc.so.6
#1  0x56437008 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Happens on program exit about 1 / 1000.

Are you aware of valgrind?

# ¿ Dec 16, 2015 15:31

feedmegin: Jul 30, 2008

netcat posted:

So for a more embarrassing question. To use Asan we have to move to gcc 4.8.1 (from ancient 4.6.3) and suddenly this code fails to compile:

To make a hollow sound laughing. One of our build platforms is still on gcc 3.4 and that's not even the oldest version in the building.

# ¿ Dec 17, 2015 11:21

feedmegin: Jul 30, 2008

Chuu posted:

Any advice for the best way to go about trying to figure out why GDB is constantly lying to me about the return values of functions called on standard collections?

As an example, I have a std::deque that I am constantly adding/removing items from. The logic works correctly, and I've added a ton of asserts to make sure the contents are consistent with what I expect them to be.

In GDB, I always get very weird results when interacting with it. For example, on the first iteration -- where I know the collection has zero elements -- I'll get .size() == 1, .empty() == true, and .size() stringstream'd and then .str()'d results in "0" like I'd expect. Every time an iteration occurs, i.e. every time I hit the breakpoint again -- size() is always 0 or 1 (which is what I expect) when checked via asserts, but gdb always reports a value that is incremented from the previous iteration -- i.e. 1,2,3,....

Anyone run into something like this before? I've wasted hours trying to track this down.

I'm using RHEL devtoolset-4 for reference. That's gcc 5.2.1 and gdb 7.20. I've tried many permutations of compiler flags, but will take any advice on particular values of interest. Code must be compiled targeting gnu-c++14 or std-c++14.

Are you compiling with optimisations?

If you literally want to see what the actual return value was, do info registers eax (32-bit) or rax (64-bit), which the SysV ABI specifies as the return register on x86, immediately after the function call.

# ¿ Jan 15, 2016 12:13

feedmegin: Jul 30, 2008

roomforthetuna posted:

Here are a selection of answers to this question. The "select" option that's the highest rated answer should be supported to some extent regardless of OS. To make the relevance clearer I should probably mention that stdin is a file descriptor. http://stackoverflow.com/questions/2917881/how-to-implement-a-timeout-in-read-function-call
(The select option is also relatively simple as it doesn't involve multithreading at all.)

Worth noting: Windows select() only works on network sockets, because network sockets are not file handles on Windows and select was/is a be-compatible-with-Unix hack on top of the OS.

# ¿ Jan 29, 2016 12:15

feedmegin: Jul 30, 2008

JawKnee posted:

SDL is crossplatform (I think), there is no standard tool for doing GUIs that is crossplatform though - I just went through trying to do this for an application I was working on.

VVV Sorry I meant standard, not native

Well obviously. Platforms are standards. Who would even define a 'standard' cross platform tool?

Qt is awesome btw but it is C++ which is uh not the same as C. Same with wxWidgets.

feedmegin fucked around with this message at 15:00 on Feb 28, 2016

# ¿ Feb 28, 2016 14:57

feedmegin: Jul 30, 2008

Subjunctive posted:

Tk has C bindings, if we've moved to crazytown.

Tk is written in C, you mean. It has TCL bindings

It used to be the best way to do open source cross platform GUI stuff in the mid 90s, but yeah, we have better options now.

I guess there's also EFL (the Enlightenment toolkit).

feedmegin fucked around with this message at 12:25 on Feb 29, 2016

# ¿ Feb 29, 2016 12:22

feedmegin: Jul 30, 2008

Doc Block posted:

Isn't it mostly because on Windows the C runtime translates the \r\n into just \n when reading files opened in text mode, and vice-versa when writing, because Windows uses CR+LF for newline instead of just LF?

I remember being bitten by that years ago when trying to port some code written for Linux to Windows that sloppily opened all files in text mode, regardless of whether they were text or binary.

edit: and also for mainframe operating systems and their weird character sets too, I guess.

For extra fun, classic (pre-OS X) MacOS used only \r and not \n. Because gotta make sure we cover all the bases, right, can't have people just stripping off any \r's and calling it good, that'd be too easy!

# ¿ Mar 1, 2016 14:22

feedmegin: Jul 30, 2008

Subjunctive posted:

Do people still like Muchnick as a compiler book?

I do (as an advanced 'how do I optimise poo poo' text, not like compilers 101).

I'm kind of curious how much of it is relevant to the modern day, though - these days I would have thought optimising memory accesses, cacheing and so on is way way more important than the sort of micro-optimisations traditional compiler spent a lot of effort on.

Edit: I liked Linkers and Loaders, but it is very specifically about linkers and loaders so unless you're going to be directly messing about with PE-COFF/Mach-O/ELF files you're going to get limited use out of it (and if you are doing that it's useful background but you could probably just read the relevant spec for the file format you're interested in instead).

feedmegin fucked around with this message at 13:36 on Mar 24, 2016

# ¿ Mar 24, 2016 13:28

feedmegin: Jul 30, 2008

Le0 posted:

I wanna play with Qt and I'd like to make an application that can handle data packets (ethernet, ip or whatever).
I'm thinking of creating each packet field as a std::bitset, then concatenate all the bitset to create the complete packet.

Would there be a better type suited to do this?

That seems like it would be...slow.

The old-school way would be to use pointers of the relevant type and offset (uint32_t's or whatever) into a buffer. Watch for network versus host byte order! (because unless you're on a SPARC box like it's 1995 or something else old-school, those will be different).

# ¿ Apr 5, 2016 18:55

feedmegin: Jul 30, 2008

b0lt posted:

Endianness doesn't matter much anymore, everything that matters is little endian (except for fields that are mandated to be big endian ).

Yes, that's exactly my point. The BSD sockets API and TCP/IP were both defined on big-endian machines and popularised by Sun. It's all big-endian, that's why there's ntohs and htons and whatever all over the place if you're doing low-level socket code.

# ¿ Apr 5, 2016 19:51

feedmegin: Jul 30, 2008

Ralith posted:

New code these days usually uses something that automatically generates accessor code from a schema definition, so you never have to worry about fiddling with memory by hand. My favorite is Cap'n Proto, which is efficient and has very good support for maintaining forwards/backwards compatibility across protocol revisions.

This guy isnt trying to serialise, hes trying to read tcp packet headers and such that are in a predefined binary format.

Edit: I was talking about Le0, yeah, sorry. Serialising stuff de novo when you control the wire format and having to read an existing protocol are two different things.

feedmegin fucked around with this message at 09:17 on Apr 8, 2016

# ¿ Apr 7, 2016 12:58

feedmegin: Jul 30, 2008

rjmccall posted:

Creating a new kernel-scheduled thread is actually a really expensive operation on almost every established operating system, but IIRC that's especially true on Windows. This is why people tend to recommend offloading work onto a thread pool instead of creating a new thread. There are definitely languages/environments with really cheap threads, but they use M-to-N threading, and they overwhelmingly tend to not be C environments.

Hmm. This does raise the question of why M:N schedulers for Posix threads have not generally been as successful/performant as modern Linux's 1:1 threading. I know it was tried for Linux too before the current approach won out..what about other languages makes that easier?

# ¿ May 13, 2016 22:28

feedmegin: Jul 30, 2008

Qwertycoatl posted:

I like the bit where they made it by taking a library in C and renaming all the foo(bar) to bar->foo()

I like how it punts entirely on event handling (for now, they say, but we know how fast standards move). If I understand correctly, you can't even use this to redraw things when your window gets resized. :wtc:

# ¿ May 24, 2016 19:07

feedmegin: Jul 30, 2008

nielsm posted:

What window? Cairo has never really been concerned with any UI or interaction aspects of what you draw, it's just a way of drawing on surfaces obtained in mysterious ways. Similar to how OpenGL doesn't actually specify how you get a drawable surface, that's up to implementation-specific APIs.
I believe the intention is that whatever UI library you use would give you surface objects back, which you can then draw on using the standard drawing API, but if you want to react to UI-related changes (like window with surface resizing, mouse clicking somewhere etc.) that's something you have to handle with the UI library.

Besides, who says you're even drawing to a screen surface at all?

If you have to use platform-specific stuff to do literally anything useful at all, what's the point of standardising just part of the whole process? If you're using a UI library like Qt or whatever then you can just use Qt, after all.

# ¿ May 24, 2016 21:58

feedmegin: Jul 30, 2008

Subjunctive posted:

You might not be interacting with UI meaningfully at all, just (or primarily) producing images.

Producing images into what, though? There's nothing in there that says 'make me a GIF', for example. I don't think I even saw something that said 'make me a fixed size window on the desktop of size x times y' (and what x times y do you pick with no way of knowing the desktop resolution). 'Just producing images' is a really, really niche thing for something that's intended to go into the standard library; there's a reason GUI libraries normally involve a whole lot more than that.

# ¿ May 24, 2016 22:17

feedmegin: Jul 30, 2008

I guess my point is, if I want to write, like, grep or something I can do that right now in standard C++ using nothing but the standard and it will work on all standards-compliant platforms now, in the past, or on the future. It should work on VMS or z/OS or FutureOS3000. I can't do that with this library, because afaics it fundamentally depends on doing platform-specific stuff for it to be useful for pretty much anything. For that reason, useful though it might be, I don't see why it belongs in the standard rather than being, like actual Cairo, a third party library. Especially before, for example, incorporating something like boost::filesystem; standard C++ currently doesn't even know what a directory is! I mean I know there is a TS for that too, but that sort of thing kind of seems higher priority to me than a barely-useful 2d graphics API.

feedmegin fucked around with this message at 23:24 on May 24, 2016

# ¿ May 24, 2016 23:12

feedmegin: Jul 30, 2008

Sagacity posted:

I'm building an open-source application with Qt. There's a bunch of useful stuff in KDE that I'd like to use (KItemModels and KItemViews, specifically). If I want to comply with their licensing (LGPL I believe), am I allowed to just copy/paste the source files in my project with proper attribution or am I really forced to have everyone build the KDE frameworks themselves?

The reason I ask is that these libraries I want to use are fairly self-contained. It's a big hassle to get KDE to build on Windows and OS/X, when I could just compile the classes as part of my app and be done with it.

It's the Library GPL for a reason. You can ship the KDE libraries with your project as binaries. You can probably make your own little library with the KDE stuff in it and link against that, too, as long as you release the source/makefiles/etc. You can't just bung the source into your application and still keep it closed source.

Edit: v0v fine now it's the Lesser GPL. It didn't start out being called that, though!

feedmegin fucked around with this message at 13:09 on Jun 2, 2016

# ¿ Jun 2, 2016 11:44

feedmegin: Jul 30, 2008

VikingofRock posted:

As someone who knows very little about licenses, what is the difference in the licenses that causes this?

BSD licences allow you to take the source to <x>, do what you like with it, incorporate it in your own product, and not release any of the changes you have made. At most they compel you to say that you used product <x> in your stuff.

The GPL does not allow you to do this thing, it's the explicit reason it came into being.

# ¿ Jun 8, 2016 19:15

feedmegin: Jul 30, 2008

Of course that enum could go pear shaped on a 64 bit platform where an enum could be 64 bits...

# ¿ Jun 12, 2016 12:30

feedmegin: Jul 30, 2008

Volguus posted:

The way I am interpreting it is that you can re-redistribute your application as long as your are conforming to the GPL/LGPL licenses. For a commercial application you really don't want to touch GPL libraries. However, it is perfectly fine to use an LGPL library as long as your are dynamically linking to it. No static linking.
The additional restriction is : any changes you make to an LGPL library you must publish the source code for that if you are redistributing your application (and that library).
If you buy the license you are essentially buying support and the ability to change Qt and not publish the changes (and that is a perfectly reasonable and valid way to go for many companies).

Other than that, you are free as a bird.

Yes, this is correct. It's been a long, long time since you needed to pay Trolltech/Nokia/the Qt company to use Qt for commercial/closed-source development. Nor do you have to pay them just to use Qt Creator, :wtc:

# ¿ Jun 22, 2016 10:40

feedmegin: Jul 30, 2008

For what it's worth, if you do end up learning C++ you can make games/apps for Android in that, too, using Qt :sun:

# ¿ Aug 24, 2016 14:23

feedmegin: Jul 30, 2008

leper khan posted:

^a good post.

Not using std::string (or wstring, ..) has been a pretty strong leading indicator that I'm going to be dealing with a house of horrors. At least for projects started in the past 5-ish years.

Counterpoint: anything written using Qt :colbert:

# ¿ Oct 7, 2016 20:41

feedmegin: Jul 30, 2008

Klades posted:

You can consider them whatever you want, but pointers are their own type, not just a syntax layer on top of whatever they're pointing to. This is generally true all the way down to the hardware.

[] in C genuinely is syntactic sugar for pointers, though.

# ¿ Nov 12, 2016 17:16

feedmegin: Jul 30, 2008

Cory Parsnipson posted:

Is this because of performance reasons or something else?

Performance reasons is probably sufficient, but also in general using exceptions for control flow is 'not the C++ way'. C++ implementations generally try to make exception handling where exceptions don't actually get thrown cheap/free at the expense of making the actual process of throwing an exception slow/expensive. This isn't Python.

# ¿ Jun 1, 2017 12:57

feedmegin: Jul 30, 2008

Ralith posted:

Also useful for portably formatting stdint.h types with printf format strings, which might be the exact circumstances of the code fragment in question.

Hmm maybe I'm dumb because of the heat today but how does that work?

# ¿ Jun 19, 2017 10:30

feedmegin: Jul 30, 2008

Subjunctive posted:

I thought OP wanted to track main's scope regardless of where the program was executing.

Why? It kinda sounds like you actually want to make those variables global if that matters to you outside of main() itself.

(Hopefully foutre isn't thinking of like old style LISP dynamic scoping or something where main()'s locals could be visible to the functions main() calls or anything)

# ¿ Jul 22, 2017 18:27

feedmegin: Jul 30, 2008

Subjunctive posted:

I don't know why, that's just how I read the post.

Sorry, I meant I was asking the OP why :shobon:

# ¿ Jul 23, 2017 11:31

feedmegin: Jul 30, 2008

Doc Block posted:

Usually this happens when the bytes per line isn't what you thought it was, which causes part of the next line to display on the current one (or vice versa), which gets worse as it goes on, giving the skew you're seeing.

Some platforms pad out the bytes per row of pixels in a widget/image/whatever to make them fall on certain byte and pixel alignments to make them faster for the GPU to draw.

In particular 634 is not 32 bit aligned. You can optionally supply a 'bytes per line' to QImage's constructor as well as the width and height; try setting that to maybe 636 for that (assuming this really is an 8 bit greyscale image)?

# ¿ Aug 17, 2017 14:09

feedmegin: Jul 30, 2008

da beeper king BABY posted:

Does anyone know of a good guide or intro to C++ or Qt for people that already know C fairly well? This is just for a dumb hobby app so I don't need to be an expert.

For Qt, the product documentation is pretty good (disclaimer, I wrote some of it about 15 years ago!). But you'd want to know C++ first and that's uh quite a big topic. It's a much larger language than C.

# ¿ Aug 17, 2017 21:42

feedmegin: Jul 30, 2008

Ralith posted:

Is it poor form to plug Rust in this thread? C++'s not the only realistic option for low level code any more, and predictably, the alternatives do package management (among other things) better. The only reason I'm doing C++ at all any more is for day job stuff.

Some of us program microcontrollers in plain old C :sun:

# ¿ Sep 5, 2017 22:36

feedmegin: Jul 30, 2008

Private Speech posted:

There's like 3 embedded developers posting in UKMT apparently? Weird.

I can believe wrangling embedded hardware on the reg drives a man to communism tbh

# ¿ Sep 6, 2017 13:13

feedmegin: Jul 30, 2008

VikingofRock posted:

Huh, today I learned that you can compare function pointers. I don't know why I always assumed that they were special and that you couldn't.

In theory on some wacko architectures they can be a bit funky . In the real world : literally just the address of the first instruction of the function.

# ¿ Sep 6, 2017 21:06

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 19:57

feedmegin: Jul 30, 2008

b0lt posted:

except on 32-bit ARM, where the LSB of a function pointer will select which instruction encoding the CPU will use

Well, true I guess. On executing the bx instruction, yes, the LSB determines whether to enter Thumb or 'classic' mode (and the LSB is then ignored in calculating the actual address, so it's still 2/4 byte aligned; thus for a pointer to a Thumb function the value of the function pointer is technically the address of the first instruction plus one byte). That said, that's only if you're using the bx instruction which is specifically for if you want to change modes. For other branch instructions that would just be an invalid (unaligned) address.

That's a much smaller implementation wrinkle than e.g. the old 386-style DOS memory models with segments or the wacky sort of stuff you saw on the AS/400; you could for example presumably have two different segment registers pointing at the same area of memory in which case you could have two far pointers that are 'unequal' that are in fact equal.

Edit: and yes, I'm not a huge fan of our recent rebranding but whatevs I guess, marketing gonna market :shrug:

feedmegin fucked around with this message at 17:08 on Sep 7, 2017

# ¿ Sep 7, 2017 16:57

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

«‹›2 »