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 »

ultrafilter: Aug 23, 2007; It's okay if you have any questions.

Way back when I used MFC to build simple Windows GUIs. I don't think that's the current MS standard, but if you know for sure that you'll never run on anything but Windows then the equivalent might be your best bet.

# ? Jul 27, 2022 23:16

Adbot: ADBOT LOVES YOU

# ? Jun 8, 2024 06:15

Foxfire_: Nov 8, 2010

cheetah7071 posted:

Showing my own ignorance here, but is it really necessary to be backed by a proper rendering engine like directx or opengl if all I want is buttons and file select prompts and stuff? I just sort of assumed that that wouldn't be necessary, but maybe that's wrong because every library I've looked at has been a generalizing abstraction over rendering engines.

Everything should eventually be backed by something that knows about how the GPU works, which mostly means directx on windows. Dragging around a window full of stuff on a high resolution display will lag badly if it is the CPU doing the work. But the thing implementing that doesn't have to be close to the library you're using. Even the ancient Win32 GDI drawing functions have been implemented on top of directx since Windows 7.

# ? Jul 27, 2022 23:32

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!

Foxfire_ posted:

Everything should eventually be backed by something that knows about how the GPU works, which mostly means directx on windows. Dragging around a window full of stuff on a high resolution display will lag badly if it is the CPU doing the work. But the thing implementing that doesn't have to be close to the library you're using. Even the ancient Win32 GDI drawing functions have been implemented on top of directx since Windows 7.

And you'll probably actually get better/cheaper performance Win32 style if you're just doing basic stuff, because the abstraction most likely turns your lines and sprites and poo poo into a bitmap, then when you drag the window around it'll just be rendering the bitmap, which you *could* do explicitly in DirectX, but if you were doing it in DirectX you'd more likely just render all the elements every frame of the drag operation because you already wrote that code.

Edit: the Win32 API is less horrible than MFC, by the way. Getting started with it is a bit of a hurdle but once you've got a few of the concepts down it's pretty simple and easy to work with. And won't keep loving you with things you didn't want like MFC did.

# ? Jul 27, 2022 23:47

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

cheetah7071 posted:

Does anyone in here have advice on packages for making simple GUIs? I know the usual advice is to write your GUI in another language even if your backend is C++, but what I want is so simple that it feels like it really ought to be easier to not add another language to the project. All I really need is things like radio select buttons, checkboxes, text input, file select prompts--basically just a visual wrapper for the same options present on the command line interface. It needs to be open source (or at least usable in an open source project). Cross-platform would be nice but I'll take what I can get--windows is the minimum.

Every package I've found seems to be insanely heavy-weight, intended for people writing extremely complex software way beyond the capacity I actually need, with complexity and difficulty to link/include commensurate with their power

Building a UI language for some dead game consoles is on my list of projects. Going to base it off the example in the lex/yacc book that got derided as entirely worthless in reviews and cut from the flex/bison book

# ? Jul 28, 2022 00:30

OddObserver: Apr 3, 2009

roomforthetuna posted:

Edit: the Win32 API is less horrible than MFC, by the way. Getting started with it is a bit of a hurdle but once you've got a few of the concepts down it's pretty simple and easy to work with. And won't keep loving you with things you didn't want like MFC did.

About.... 15 years or so, probably more, ago, I think I've found that wxWidgets was a far better take on MFC than MFC. Maybe it's still friendly enough? Qt also makes easy stuff easy, but it's not a small library, and if it still uses moc build stuff can be a headache.

# ? Jul 28, 2022 00:45

nelson: Apr 12, 2009; College Slice

I have a class MyClass that takes in a standard::shared_ptr foo. foo has several member functions of the form void bar1(int), void bar2(int), etc� In MyClass, I am trying to make my own �common� function that takes as an argument a bar function.

I used std::function<void>(int).

I can pass bar functions successfully if I wrap them in a lambda. How do I pass them without using a lambda, or is that not recommended?

# ? Jul 28, 2022 20:41

Absurd Alhazred: Mar 27, 2010; by Athanatos

nelson posted:

I have a class MyClass that takes in a standard::shared_ptr foo. foo has several member functions of the form void bar1(int), void bar2(int), etc� In MyClass, I am trying to make my own �common� function that takes as an argument a bar function.

I used std::function<void>(int).

I can pass bar functions successfully if I wrap them in a lambda. How do I pass them without using a lambda, or is that not recommended?

You need a lambda because you have to pass the objects along, as they're member functions. Incidentally, be very careful about passing objects along to make sure they're not released before the lambda body gets called.

# ? Jul 28, 2022 20:51

cheetah7071: Oct 20, 2010; honk honk; College Slice

The syntax is a bit wonky but you can pass member function pointers around.

like I think this will work:

code:

class Foo {
public:
	void func1(int a);
	void func2(int a);
};

using FooFunc = void(Foo::*)(int);

class HasFoo {
public:
	std::shared_ptr<Foo> ptr;
	void applyFunction(FooFunc fun, int a) {
		((*ptr).*fun)(a);
	}
};

I might have the syntax slightly wrong; it's very obtuse. But something along these lines definitely works.

# ? Jul 28, 2022 20:56

nelson: Apr 12, 2009; College Slice

Thanks for the quick replies. Looks like using a lambda was the most straightforward way after all.

# ? Jul 28, 2022 21:31

Nalin: Sep 29, 2007; Hair Elf

You could use std::bind if you don't want to use a lambda, but I think the general consensus the last time I looked into this is to just use a lambda.

BTW, std::bind would look like this:

code:

struct Foo {
    void bar1(int a) {}
    void bar2(int b) {}
};

using MyFunc = std::function<void(int)>;

void myBarFunc(MyFunc f)
{}

Foo foo;
MyFunc fun = std::bind(&Foo::bar2, &foo, std::placeholders::_1);
myBarFunc(fun);

# ? Jul 28, 2022 22:26

feedmegin: Jul 30, 2008

Foxfire_ posted:

Everything should eventually be backed by something that knows about how the GPU works, which mostly means directx on windows. Dragging around a window full of stuff on a high resolution display will lag badly if it is the CPU doing the work.

If thats happening something is SERIOUSLY wrong, tbf. This was a solved problem with hardware bitblt in like the early 90s long before GPUs. I could see it on old Linux if you were using VesaFB but there's no excuse on any version of Windows post 95.

Also if we are talking about moving windows around on the normal desktop, specifically, that is being done by the window manager not your apps GUI toolkit. (And how full of stuff it is is irrelevant, you aren't re-rendering each control as the window is dragged)

Using unaccelerated raster graphics to draw undemanding stuff within a top level window is perfectly viable, though and Qt has such a backend. Still needs to talk to the relevant system API to get a surface to draw on though.

feedmegin fucked around with this message at 01:06 on Jul 30, 2022

# ? Jul 30, 2022 00:58

Foxfire_: Nov 8, 2010

I'm thinking of childhood memories of how stuff would perform in the time between installing windows/a new graphics card and installing a device-specific driver for it. You'd get 640x480 and moving things around would lag

# ? Jul 30, 2022 02:17

feedmegin: Jul 30, 2008

Foxfire_ posted:

I'm thinking of childhood memories of how stuff would perform in the time between installing windows/a new graphics card and installing a device-specific driver for it. You'd get 640x480 and moving things around would lag

Yeah at which point youre at the equivalent of vesafb (well raw VGA really). Thing is pretty much every graphics card you can fit in a PC should have a Windows driver unless you I dunno ripped it out of a Mac or a PCI capable Sun workstation or something. Either way it's not something an individual application can do anything about.

# ? Jul 30, 2022 09:48

StumblyWumbly: Sep 12, 2007; Batmanticore!

Does anyone have a good recommendation for writing optimized C code?

I work on microcontrollers, and we're working on efficiency vs clarity. My memory on optimization, which seems to be true from testing, is that C will optimize code in a file but not really code between files. So, if you're calling a function using a constant input, the call will only be optimized if it is inline. This gets frustrating when we're calling vendor provided DMA setup code, so the way to speed things up seems to be to copy the vendor code and strip out everything that doesn't apply because the optimizer doesn't see that we're always running the same way, just with 2 parameters out of 10 being different.

# ? Aug 7, 2022 00:35

pseudorandom name: May 6, 2007

Modern C compilers support link-time optimization.

But is your DMA setup code even performance critical?

# ? Aug 7, 2022 00:47

ExcessBLarg!: Sep 1, 2001

StumblyWumbly posted:

This gets frustrating when we're calling vendor provided DMA setup code, so the way to speed things up seems to be to copy the vendor code and strip out everything that doesn't apply because the optimizer doesn't see that we're always running the same way, just with 2 parameters out of 10 being different.

I'd say the problem is that the vendor is providing an omnibus function with 10 parameters. If they're not breaking the interface down into something more digestible then you may just have to.

# ? Aug 7, 2022 03:26

StumblyWumbly: Sep 12, 2007; Batmanticore!

pseudorandom name posted:

Modern C compilers support link-time optimization.

But is your DMA setup code even performance critical?

The DMA setup happens in an interrupt and seems to be taking a surprisingly long time, so it would definitely be nice to speed up. I'll look into the link-time optimization, that may be the keyword I needed.

ExcessBLarg! posted:

I'd say the problem is that the vendor is providing an omnibus function with 10 parameters. If they're not breaking the interface down into something more digestible then you may just have to.

Yeah, this is definitely part of the problem. DMAs are such flexible features that its hard to make an interface that is simple, efficient, and flexible.

# ? Aug 7, 2022 04:59

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

As a warning, low-level code is often not written in a way that works under new optimizations, especially LTO. It is very easy for a function that does individual operations common in hardware drivers (e.g. memory-mapped I/O) to work just fine when it�s basically compiled as if it were an opaque intrinsic, but to break badly when it�s analyzed with / inlined into its callers because it isn�t using the right language features to express its unusual semantics (e.g. doing that I/O with volatile accesses).

# ? Aug 7, 2022 06:48

Qwertycoatl: Dec 31, 2008

Eww, really? I saw some blogpost once about hardware access by someone who used std::atomic because volatile wasn't "modern", but I didn't realise people like that were common enough to be a problem

e: Oh I guess the common bad way is just to use normal memory access and hope for the best

Qwertycoatl fucked around with this message at 11:33 on Aug 7, 2022

# ? Aug 7, 2022 11:31

Xarn: Jun 26, 2015

Qwertycoatl posted:

e: Oh I guess the common bad way is just to use normal memory access and hope for the best

Yep. Also for cross-thread communications, because people are kinda stupid (and also atomics came in late to the language).

# ? Aug 7, 2022 12:52

OddObserver: Apr 3, 2009

Xarn posted:

Yep. Also for cross-thread communications, because people are kinda stupid (and also atomics came in late to the language).

Memory consistency issues were also somewhat undertaught when I was a student, but that was a long time ago so maybe some adjustments have been made since then given the near universality of multi-core systems these days.

# ? Aug 7, 2022 13:14

Foxfire_: Nov 8, 2010

For a specific example, STs peripheral library does illegal aliasing things. It won't compile as intended if you leave strict aliasing optimizations on and give the optimizer a wide enough view to use them.

The particular bit I know of is with the crc peripheral. Their function accepts a char buffer, bit they want to do 32 bit writes to the peripheral. They did it with some single byte accesses to get to a 4 byte boundary then an illegal cast to int* and reading through that

# ? Aug 7, 2022 19:09

qsvui: Aug 23, 2003; some crazy thing

Wow, looks like C23 is adding a LOT of new stuff. Much of it is lifted from C++. Some highlights:

constexpr (not for functions though)
auto (works like GCC __auto_type)
nullptr
Binary literals
Digit separators
custom enum underlying types (e.g. enum E : uint8_t)
Attributes (e.g. [[deprecated]], [[fallthrough]], etc.)

Also added was #embed which allows you to do something like this:

C code:

static const uint8_t honk[] = {
#embed <data/honk.wav>
};

# ? Aug 7, 2022 21:29

ultrafilter: Aug 23, 2007; It's okay if you have any questions.

I wouldn't mind getting #embed over in C++ land.

# ? Aug 7, 2022 21:37

repiv: Aug 13, 2009

The person who got #embed into C is also pushing for std::embed in C++ but apparently it's been hell getting them through standardization, they've been fighting for that basic rear end feature for 5 years

Odds are that compilers will support #embed in C++ mode anyway, even if it's not technically in the spec yet

# ? Aug 7, 2022 21:47

Absurd Alhazred: Mar 27, 2010; by Athanatos

repiv posted:

The person who got #embed into C is also pushing for std::embed in C++ but apparently it's been hell getting them through standardization, they've been fighting for that basic rear end feature for 5 years

Odds are that compilers will support #embed in C++ mode anyway, even if it's not technically in the spec yet

Maybe that person should have called it an "embedding concept" and it would have gotten more votes.

# ? Aug 7, 2022 21:50

repiv: Aug 13, 2009

https://thephd.dev/finally-embed-in-c23

It actually started as a C++ proposal but C ended up getting there first

# ? Aug 7, 2022 21:57

BattleMaster: Aug 14, 2000

Binary literals are one of those "about drat time" things that tons of compilers especially for embedded platforms have independently implemented ages ago.

# ? Aug 7, 2022 22:03

Xarn: Jun 26, 2015

#embed happened literally only because WG21 was too disfunctional for std::embed to happen, to backdoor embed into C++.

# ? Aug 7, 2022 22:20

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!

That form of embed is funny because I've written essentially that myself as a "preprocessor" [code generation] for several languages. It's bizarre that it took this long for it to be recognized as a thing people want/use.

# ? Aug 8, 2022 01:46

Spatial: Nov 15, 2007

Embed is a good one. You have to laugh at the absurd inefficiency of parsing every byte of a binary file as human readable numbers.

# ? Aug 8, 2022 12:21

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!

Spatial posted:

Embed is a good one. You have to laugh at the absurd inefficiency of parsing every byte of a binary file as human readable numbers.

Yeah, I did in one context make a thing that just turned the binary into an object file, but the inconsistent format of object files makes that not as easily cross-platform at turning it into string-bytes. I hope #embed is *more like* the former.

# ? Aug 8, 2022 13:56

Xarn: Jun 26, 2015

Depends on whether the implementations will be on the ball or not.

My 8 ball says "reply hazy, try again later".

# ? Aug 8, 2022 15:44

nielsm: Jun 1, 2009

The blog linked earlier said the speedup already exists and is great. If you actually ran just the preprocessor on the C file you'd get a bloated output with a sequence of ints, but what I gather is that when you run the regular compiler to produce an object file, the compiler acts "as-if" the embedded file was read in as a sequence of integer literals, but actually just embeds the content directly. The 5x bloat is never actually produced in either memory or on disk.

# ? Aug 8, 2022 17:12

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

roomforthetuna posted:

That form of embed is funny because I've written essentially that myself as a "preprocessor" [code generation] for several languages. It's bizarre that it took this long for it to be recognized as a thing people want/use.

The argument against it was basically that everyone's written that tool before and so the language didn't need it, which is a stupid argument even if you ignore the fact that #embed works a lot better.

# ? Aug 8, 2022 19:11

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

Also there's a bizarrely large number of people who think that xxd is present everywhere because they apparently can't conceive of a machine not having vim installed.

# ? Aug 8, 2022 19:13

more falafel please: Feb 26, 2005; forums poster

Plorkyeran posted:

Also there's a bizarrely large number of people who think that xxd is present everywhere because they apparently can't conceive of a machine not having vim installed.

vi or a compatible editor is part of the posix standard, wrap it up emacsailures

# ? Aug 8, 2022 19:20

ExcessBLarg!: Sep 1, 2001

Plorkyeran posted:

Also there's a bizarrely large number of people who think that xxd is present everywhere because they apparently can't conceive of a machine not having vim installed.

There's no excuse not having xxd installed on a machine that also has gcc or clang.

# ? Aug 9, 2022 15:23

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

What if I told you that you can compile c++ without having gcc or clang?

# ? Aug 9, 2022 19:03

Adbot: ADBOT LOVES YOU

# ? Jun 8, 2024 06:15

Xarn: Jun 26, 2015

Lies.

# ? Aug 9, 2022 19:25

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

«‹›641 »