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 »

fritz: Jul 26, 2003

Unless I'm totally misreading it, could you do a map keyed on the character that's the process name and skip the set entirely?

# ? Oct 19, 2014 01:22

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 17:24

hooah: Feb 6, 2006; WTF?

GrumpyDoctor posted:

Well, in that case, you still don't need to roll your own search.

Well hell, I forgot all about find_if! Thanks!

fritz posted:

Unless I'm totally misreading it, could you do a map keyed on the character that's the process name and skip the set entirely?

This would be another approach. As I said before, I use anything other than vector so infrequently that I forget about them. I really need to get over that.

# ? Oct 19, 2014 01:26

The Laplace Demon: Jul 23, 2009; "Oh dear! Oh dear! Heisenberg is a douche!"

hooah posted:

Because when the client program wants to erase something, it'll ideally just give a char that is the process's name, and unless I'm misunderstanding it, set::find takes the same type as what the set stores. I suppose I could re-write the client program to create the Process objects itself, but I'd hoped to avoid having the client know about what seems like internal implementation details.

C++14 introduces "transparent" comparators for ordered containers that allow you to do my_set.find('a'), but that might not be an option here. It'd work something like this:

C++ code:

struct cmp {
    using is_transparent = void; // doesn't matter what type, as long as it exists

    bool operator()(char id, Process p) { return id < p.GetLabel(); }
    bool operator()(Process p, char id) { return p.GetLabel() < id; }
    bool operator()(Process lhs, Process rhs) { return lhs.GetLabel() < rhs.GetLabel(); }
};

std::set<Process, cmp> my_set;
// populate my_set
my_set.find('F').Kill();

Definitely sort on your lookup index by the way. Not that it really matters for a max of 256 processes, but still...

fritz posted:

Unless I'm totally misreading it, could you do a map keyed on the character that's the process name and skip the set entirely?

Yeah, this. Or std::array<std::unique_ptr<Process>, 1 << CHAR_BIT> my_set; considering the key set is so tiny.

C++ code:

// O(1) insert/replace
my_set[label] = std::make_unique(addr, label);

// O(1) delete
my_set[label] = nullptr;

// O(1) lookup
if (my_set[label]) {
    // use my_set[label]
}

The Laplace Demon fucked around with this message at 01:34 on Oct 19, 2014

# ? Oct 19, 2014 01:30

hooah: Feb 6, 2006; WTF?

The Laplace Demon posted:

Or std::array<std::unique_ptr<Process>, 1 << CHAR_BIT> my_set; considering the key set is so tiny.

Whoa whoa whoa, could you explain what the heck is going on here? I just glanced at what a std::array is (as opposed to a C array, I guess), and I understand what's going on until the << CHAR_BIT part. How can you insert anything into the literal 1?

# ? Oct 19, 2014 01:44

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

hooah posted:

Whoa whoa whoa, could you explain what the heck is going on here? I just glanced at what a std::array is (as opposed to a C array, I guess), and I understand what's going on until the << CHAR_BIT part. How can you insert anything into the literal 1?

It's a plain old left shift.

# ? Oct 19, 2014 01:47

Jewel: May 2, 2009

hooah posted:

How can you insert anything into the literal 1?

STL devs thought they were smart and made << and >> both insertion operators and bitshifting operators at the same time, depending on what the object they're used on's implementation of them is. For numbers it's a bitshift, for iostream/stringstream it's a concat operation, and for filestream it's.. I guess technically concat but more insertion. STL's design decisions are Not Very Good.

# ? Oct 19, 2014 01:58

The Laplace Demon: Jul 23, 2009; "Oh dear! Oh dear! Heisenberg is a douche!"

hooah posted:

Whoa whoa whoa, could you explain what the heck is going on here? I just glanced at what a std::array is (as opposed to a C array, I guess), and I understand what's going on until the << CHAR_BIT part. How can you insert anything into the literal 1?

Sorry. Basically this, but portable to platforms where a byte is not 8 bits and using std::array instead of raw arrays.

C++ code:

std::unique_ptr<Process> my_set[256];

Equivalently, UCHAR_MAX + 1 or std::numeric_limits<unsigned char>::max() + 1.

# ? Oct 19, 2014 01:58

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

The Laplace Demon posted:

Sorry. Basically this, but portable to platforms where a byte is not 8 bits

I'm sure the three Cray computers left in the world will be happy for that consideration.

# ? Oct 19, 2014 02:04

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Jewel posted:

STL devs thought they were smart and made << and >> both insertion operators and bitshifting operators at the same time, depending on what the object they're used on's implementation of them is. For numbers it's a bitshift, for iostream/stringstream it's a concat operation, and for filestream it's.. I guess technically concat but more insertion. STL's design decisions are Not Very Good.

Pretty sure iostream's clever overloading predates the STL.

# ? Oct 19, 2014 02:14

The Laplace Demon: Jul 23, 2009; "Oh dear! Oh dear! Heisenberg is a douche!"

Suspicious Dish posted:

I'm sure the three Cray computers left in the world will be happy for that consideration.

Haha, right?

This probably won't be running on DSPs where that'd ever be a concern nowadays, but I still use the constants for their documentation of intent.

# ? Oct 19, 2014 02:32

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

You're like that guy who does int buffer_size = width * height * sizeof (char);.

# ? Oct 19, 2014 02:38

pseudorandom name: May 6, 2007

Subjunctive posted:

Pretty sure iostream's clever overloading predates the STL.

Pretty sure the bit shift operators predate C++.

# ? Oct 19, 2014 02:40

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

pseudorandom name posted:

Pretty sure the bit shift operators predate C++.

Pretty sure that in this language family overloading doesn't.

(You're pretty, I'm sure.)

Edit: well, int/float/double/char overload of + was always there, I guess.

# ? Oct 19, 2014 03:02

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!

Note to the guy with the sorted process list problem - the suggestion of a map keyed on the char-based process identifier would have to be in addition to the set, for your purposes, I think, since as I understand it the whole point of your ordered list was that you wanted the processes with adjacent memory to be listed adjacent to each other. If you just map on the names, you'll lose that ordering, but you could have a set of the addresses and a map of char-based identifier to addresses and have fun trying to keep them in sync.

Unless some balance-combination of [the number of entries is large and you're doing char-based lookups frequently], you're likely better off just doing a linear search through your set for the char-based key. The C++14 transparent thing for that is cool, but if you don't have C++14 available then writing your own 'find' function for finding on a different criterion is really okay. (You could use std::find_if to skip writing the loop part.)

# ? Oct 19, 2014 03:24

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

Jewel posted:

STL devs thought they were smart and made << and >> both insertion operators and bitshifting operators at the same time, depending on what the object they're used on's implementation of them is. For numbers it's a bitshift, for iostream/stringstream it's a concat operation, and for filestream it's.. I guess technically concat but more insertion. STL's design decisions are Not Very Good.

iostreams is an entirely separate library from the STL. It's also the oldest of the various libraries added to the C++ standard library (not counting the C stdlib), and it shows.

# ? Oct 19, 2014 03:58

The Laplace Demon: Jul 23, 2009; "Oh dear! Oh dear! Heisenberg is a douche!"

Suspicious Dish posted:

You're like that guy who does int buffer_size = width * height * sizeof (char);.

# ? Oct 19, 2014 05:16

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

Suspicious Dish posted:

You're like that guy who does int buffer_size = width * height * sizeof (char);.

That's actually valuable; it makes it immediately obvious to the reader that this is a byte-size calculation and that it's for an array of chars.

# ? Oct 19, 2014 06:25

Pseudoscorpion: Jul 26, 2011

Suspicious Dish posted:

You're like that guy who does int buffer_size = width * height * sizeof (char);.

It's future-proofing! Maybe they'll change sizeof(char) at some point! :downs:

I do this because it makes my code ever-so-slightly clearer :ssh:

# ? Oct 19, 2014 12:22

Zopotantor: Feb 24, 2013; ...und ist er drin dann lassen wir ihn niemals wieder raus...

Jewel posted:

STL devs thought they were smart and made << and >> both insertion operators and bitshifting operators at the same time, depending on what the object they're used on's implementation of them is. For numbers it's a bitshift, for iostream/stringstream it's a concat operation, and for filestream it's.. I guess technically concat but more insertion. STL's design decisions are Not Very Good.

iostreams are pre-STL. Thank Bjarne for that poo poo; STL was a much needed improvement on prior C++ libraries.

# ? Oct 19, 2014 13:12

Heavy_D: Feb 16, 2002; "rararararara" contains the meaning of everything, kept in simple rectangular structures

Is there a standard alternative to iostreams that isn't as weird? Or a chance there ever will be one in a future c++ spec?

# ? Oct 19, 2014 13:32

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.

Heavy_D posted:

Is there a standard alternative to iostreams that isn't as weird? Or a chance there ever will be one in a future c++ spec?

There really isn't a great alternative. Realistically, you'd probably use something else to do user input in more than a toy project, and if you have to do a lot of dumb string stuff or worry about i18n you might just be using the wrong tool for whatever you're trying to do.

# ? Oct 19, 2014 13:58

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

Heavy_D posted:

Is there a standard alternative to iostreams that isn't as weird? Or a chance there ever will be one in a future c++ spec?

stdio.h gives up type safety but is less painful to use in most cases imo. There have been a couple of attempts from academia to make a better C++ IO library but none have caught on.

# ? Oct 19, 2014 16:55

Falcorum: Oct 21, 2010

Technically, you could get a typesafe stdio now that variadic templates exist. The odds of that happening (at least in a standard way) are pretty slim however.

# ? Oct 19, 2014 17:40

nielsm: Jun 1, 2009

Could C++14 constexpr functions together with static_assert be used to type-check arguments for printf-style format strings?

# ? Oct 19, 2014 18:22

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

GCC already gives you warnings for arguments that conflict with the types in printf format strings, no idea what the implementation is based on (probably a bunch of builtin crap)

# ? Oct 19, 2014 19:02

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

Blotto Skorzany posted:

GCC already gives you warnings for arguments that conflict with the types in printf format strings, no idea what the implementation is based on (probably a bunch of builtin crap)

Hooray for dependent types

# ? Oct 19, 2014 19:13

Vanadium: Jan 8, 2005

Is the problem with iostreams vs stdio really just that overloading << is gross and not the more architectural poo poo?

# ? Oct 19, 2014 19:13

FamDav: Mar 29, 2008

q: when you feed a boolean into a stream, does it print a numeric or textual representation?

a: who knows!

# ? Oct 19, 2014 19:49

hooah: Feb 6, 2006; WTF?

FamDav posted:

q: when you feed a boolean into a stream, does it print a numeric or textual representation?

a: who knows!

Surely it prints 0 or 1 unless you specify boolalpha, yes?

# ? Oct 19, 2014 19:54

Telarra: Oct 9, 2012

hooah posted:

Surely it prints 0 or 1 unless you specify boolalpha, yes?

This is correct.

C++ code:

cout << true << endl;
cout << false << endl;
cout << boolalpha;
cout << true << endl;
cout << false << endl;

code:

1
0
true
false

# ? Oct 19, 2014 20:00

FamDav: Mar 29, 2008

The who knows is because every time you pass configuration to the stream, you have now potentially changed the output of any other log statement at any other point in your system, unless they have also defensively set their configuration.

# ? Oct 19, 2014 20:05

Vanadium: Jan 8, 2005

That's why you use some boost utility thing that saves the iostream state and restores it on scope exit!

# ? Oct 19, 2014 21:54

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

Vanadium posted:

That's why you use some boost utility thing that saves the iostream state and restores it on scope exit!

Yeah, I'm going to just manually push my state onto a stack at the start of a routine and pop it back off at the end like an ~~animal~~assembly programmer. That sounds great.

# ? Oct 19, 2014 22:14

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

Blotto Skorzany posted:

Yeah, I'm going to just manually push my state onto a stack at the start of a routine and pop it back off at the end like an ~~animal~~assembly programmer. That sounds great.

~~The Aristocrats~~ C++!

# ? Oct 19, 2014 22:23

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

Vanadium posted:

Is the problem with iostreams vs stdio really just that overloading << is gross and not the more architectural poo poo?

I will mess up your program by doing cout << hex. It's just a horrible, state-ful API and that's not really what you want.

Something basically like printf that was typesafe and also called the correct cast operator for a thing when giving it weird data would basically be the best printf replacement. Otherwise, printf and doing the cast manually is better than iostream.

# ? Oct 19, 2014 22:44

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

Suspicious Dish posted:

I will mess up your program by doing cout << hex. It's just a horrible, state-ful API and that's not really what you want.

Something basically like printf that was typesafe and also called the correct cast operator for a thing when giving it weird data would basically be the best printf replacement. Otherwise, printf and doing the cast manually is better than iostream.

Boost.Format does exist. I used for a little bit and didn't want to kill myself (any more than working with C++ in general does).

# ? Oct 19, 2014 22:52

Boz0r: Sep 7, 2006; The Rocketship in action.

I'm trying to reduce my programs memory usage and so far it's going badly. I have a std::vector of Vector3D(double x,y,z) that I want to convert to a std::vector of pointers to these Vector3Ds as I'm going to copy these a shitload of times in a recursive algorithm.

code:

    std::vector<Vector3D> &input = fromSomewhere();    // n = 2^24. Shoulde be 2^24*(8+8+8) = 384 MB
    // Memory usage 395 MB

    std::vector<std::shared_ptr<Vector3D>> input_pointers = std::vector<std::shared_ptr<Vector3D>>();
    input_pointers.reserve(input.size());
    // 658 MB

    for (int j = 0; j < input.size(); ++j) {
        input_pointers.push_back(std::make_shared<Vector3D>(input.at(j)));
    }
    // 3 GB, what the hell?

What should I be doing here?

# ? Oct 19, 2014 22:55

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

Boz0r posted:

I'm trying to reduce my programs memory usage and so far it's going badly.

You're using C++.

# ? Oct 19, 2014 23:13

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

Boz0r posted:

I'm trying to reduce my programs memory usage and so far it's going badly. I have a std::vector of Vector3D(double x,y,z) that I want to convert to a std::vector of pointers to these Vector3Ds as I'm going to copy these a shitload of times in a recursive algorithm.
code:
    std::vector<Vector3D> &input = fromSomewhere();    // n = 2^24. Shoulde be 2^24*(8+8+8) = 384 MB
    // Memory usage 395 MB

    std::vector<std::shared_ptr<Vector3D>> input_pointers = std::vector<std::shared_ptr<Vector3D>>();
    input_pointers.reserve(input.size());
    // 658 MB

    for (int j = 0; j < input.size(); ++j) {
        input_pointers.push_back(std::make_shared<Vector3D>(input.at(j)));
    }
    // 3 GB, what the hell?
What should I be doing here?

Do you have some reason to be using shared_ptrs, as opposed to unique_ptrs, or even bare pointers?

# ? Oct 19, 2014 23:16

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 17:24

seiken: Feb 7, 2005; hah ha ha

code:

    std::vector<Vector3D> &input = fromSomewhere();    // n = 2^24. Shoulde be 2^24*(8+8+8) = 384 MB
    // Memory usage 395 MB
    // 384 + some overhead for whatever else the program is using

    std::vector<std::shared_ptr<Vector3D>> input_pointers = std::vector<std::shared_ptr<Vector3D>>();
    input_pointers.reserve(input.size());
    // 658 MB
    // the shared_ptr wrapper is implemented with two pointers; 658 MB = 384 MB + overhead + 2^24*(8+8) bytes

    for (int j = 0; j < input.size(); ++j) {
        input_pointers.push_back(std::make_shared<Vector3D>(input.at(j)));
    }
    // 3 GB, what the hell?
    // now you are actually allocating a bunch of independent blocks of memory (control blocks) on the heap
    // for the shared_ptrs to reference, separate from the shared_ptr wrappers inside the vector.
    // size of control block depends on implementation but typically includes space for the Vector3D itself,
    // space for deleter, allocator, at least two reference counts (strong and weak) (and padding)

See implementation notes section of std::shared_ptr, but basically shared_ptr is a very bad way of reducing memory usage. You'll be better off either just copying the raw Vector3Ds (24 bytes is small after all), or storing them in a constant vector and using raw pointers into the vector (only 8 bytes each)

Suspicious Dish posted:

You're using C++.

Congrats on your recent poo poo post. :getout:

seiken fucked around with this message at 23:21 on Oct 19, 2014

# ? Oct 19, 2014 23:18

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

«‹›641 »