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 »

Hiowf: Jun 28, 2013; We don't do .DOC in my cave.

Boz0r posted:

How can I use more than 2 GB memory in Windows?

If you're on a 64-bit OS, compile your program for 64-bit mode, make sure the relevant variables are 64-bit.

If you're on a 32-bit OS, or can't compile your program for 64-bit, there are two possible hacks:

1) On a 32-bit OS, you can change a Windows startup option that will change the address space from a 2G OS/2G User apps split to a 1G OS/3G User apps split. Google for it.

2) If you're on a 64-bit OS, but the program is 32-bit, you might be able to use up to 4G of memory. Depending on the environment, some compiler/linker settings might need to be changed (/LARGEADDRESSAWARE or similar).

If you give more details, it may be possible to give more specific advice.

# ? May 27, 2014 10:44

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 22:01

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

I hadn't seen that you had to specifically select a 64-bit platform

# ? May 27, 2014 10:55

UnfurledSails: Sep 1, 2011

This is probably a simple question, but I'm rusty with C++ and my Google skills are failing me. I have a data file that I want to read into a two dimensional array. The format of the file is:

number of rows
number of columns
x1 x2> x3
y1 y2> y3
z1 z2> z3

and so on. I need this in a format such that accessing (0,0) gives me x1, (1,2) gives me z2 and so on. Any ideas on how to get started on doing this?

# ? May 29, 2014 19:23

Ericadia: Oct 31, 2007; Not A Unicorn

UnfurledSails posted:

This is probably a simple question, but I'm rusty with C++ and my Google skills are failing me. I have a data file that I want to read into a two dimensional array. The format of the file is:

number of rows
number of columns
x1 x2> x3
y1 y2> y3
z1 z2> z3

and so on. I need this in a format such that accessing (0,0) gives me x1, (1,2) gives me z2 and so on. Any ideas on how to get started on doing this?

I had to do this for tiling in a dumb little game I made recently. My code was roughly:

code:

inf >> rows;
inf >> columns;
for (int i = 0; i < rows; i++)
{
    for (int j = 0; j < columns; j++)
    {
        inf >> nice2DArray[i][j];
    }
}

# ? May 30, 2014 04:43

Newf: Feb 14, 2006; I appreciate hacky sack on a much deeper level than you.

Are the following two lines of code the same thing?

code:

int* a = &b;
int *a = &b;

# ? May 30, 2014 13:50

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

Yes.

# ? May 30, 2014 13:53

Marta Velasquez: Mar 9, 2013; Good thing I was feeling suicidal this morning...; Fallen Rib

Newf posted:

Are the following two lines of code the same thing?
code:
int* a = &b;
int *a = &b;

Yes. This is also equivalent:

code:

int * a = &b;

# ? May 30, 2014 13:54

Newf: Feb 14, 2006; I appreciate hacky sack on a much deeper level than you.

Great, thanks.

# ? May 30, 2014 13:57

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

Newf posted:

Are the following two lines of code the same thing?
code:
int* a = &b;
int *a = &b;

Essentially yes. Some people recommend using the style of the first line. These people are wrong, because syntactically the '*' binds to the identifier, not the type. The following does not declare two pointers:

code:

int* p, q;

# ? May 30, 2014 18:04

xgalaxy: Jan 27, 2004; i write code

Or better yet, don't do that and stick to the other style.

# ? May 30, 2014 18:09

Vanadium: Jan 8, 2005

just use std::add_pointer<int>::type a, b;

# ? May 30, 2014 19:22

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

Just use template<typename T> using ptr = T*;

ptr<int> a, b; is literally impossible to mess up.

# ? May 30, 2014 19:58

Slurps Mad Rips: Jan 25, 2009; Bwaltow!

The Laplace Demon posted:

Just use template<typename T> using ptr = T*;

ptr<int> a, b; is literally impossible to mess up.

It also lets you easily define function pointers. ptr<int(int)> f

# ? May 30, 2014 20:29

Altimor: Dec 11, 2013

Or you could just declare a pointer like a normal person. If I saw that code I'd think the guy who wrote it is a complete weirdo. While that function pointer is short, it doesn't look like a function pointer at first glance.

Malcolm XML posted:

If you're using C++, use std::vector or std::array.

~~The STL containers always allocate space for elements on the heap. Fixed arrays on the stack can be a better choice if you're dealing with code that runs often.~~ Nevermind std::array doesn't. If you do choose to use ~~STL containers~~ std::vector, use the reserve method to minimize heap allocation and moving/copying.

Altimor fucked around with this message at 21:35 on May 30, 2014

# ? May 30, 2014 20:55

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

Altimor posted:

Or you could just declare a pointer like a normal person. If I saw that code I'd think the guy who wrote it is a complete weirdo. While that function pointer is short, it doesn't look like a function pointer at first glance.

Where's your sense of adventure? It looks like a function pointer as much as unique_ptr<int(int)> and shared_ptr<int(int)> do. But I'm probably corrupted from extended exposure to function<R(A...)>.

Also, it makes writing functions returning function pointers a breeze. Compare the following:

C++ code:

bool (*foo(int bar, int baz))(const char*, const char*);
void (*(*quux(int a, const char* b))(int, int))(const char*, const char*) { return &foo; }

ptr<bool(const char*, const char*)> foo(int bar, int baz);
ptr<ptr<void(const char*, const char*)>(int, int)> quux(int a, const char* b) { return &foo; }

ptr<T> is more verbose, but I think the uninitiated to the horrors of function pointer syntax actually stand a chance at writing a function definition correctly.

Of course, using callback_t = void(*)(const char*, const char*); or even typedef void (*callback_t)(const char*, const char*); is the idiomatic solution that everybody should use when forced at gunpoint to do this sort of thing.

The Laplace Demon fucked around with this message at 21:22 on May 30, 2014

# ? May 30, 2014 21:18

shrughes: Oct 11, 2008; (call/cc call/cc)

Altimor posted:

The STL containers always allocate space for elements on the heap. Fixed arrays on the stack can be a better choice if you're dealing with code that runs often. If you do choose to use STL containers, use the reserve method to minimize heap allocation.

The reserve method's benefit is avoiding the excessive copying/moving, not the heap allocation which is negligible.

Repeated heap allocation in the same code wouldn't be expensive anyway if you're doing the same small allocation/free over and over again. Unless you have a terrible malloc implementation.

# ? May 30, 2014 21:23

Dicky B: Mar 23, 2004

Altimor posted:

The STL containers always allocate space for elements on the heap.

std::array doesn't.

# ? May 30, 2014 21:25

Slurps Mad Rips: Jan 25, 2009; Bwaltow!

The Laplace Demon posted:

Where's your sense of adventure? It looks like a function pointer as much as unique_ptr<int(int)> and shared_ptr<int(int)> do. But I'm probably corrupted from extended exposure to function<R(A...)>.

Also, it makes writing functions returning function pointers a breeze. Compare the following:
C++ code:
bool (*foo(int bar, int baz))(const char*, const char*);
void (*(*quux(int a, const char* b))(int, int))(const char*, const char*) { return &foo; }

ptr<bool(const char*, const char*)> foo(int bar, int baz);
ptr<ptr<void(const char*, const char*)>(int, int)> quux(int a, const char* b) { return &foo; }
ptr<T> is more verbose, but I think the uninitiated to the horrors of function pointer syntax actually stand a chance at writing a function definition correctly.

You could also use std::reference_wrapper<T(Args...)> :v:

# ? May 30, 2014 21:28

Vanadium: Jan 8, 2005

SAHChandler posted:

It also lets you easily define function pointers. ptr<int(int)> f

This method sucks, no opportunities to showcase my hard-earned function pointer type parsing ability.

# ? May 30, 2014 21:33

Altimor: Dec 11, 2013

The Laplace Demon posted:

Where's your sense of adventure? It looks like a function pointer as much as unique_ptr<int(int)> and shared_ptr<int(int)> do. But I'm probably corrupted from extended exposure to function<R(A...)>.

Also, it makes writing functions returning function pointers a breeze. Compare the following:
C++ code:
bool (*foo(int bar, int baz))(const char*, const char*);
void (*(*quux(int a, const char* b))(int, int))(const char*, const char*) { return &foo; }

ptr<bool(const char*, const char*)> foo(int bar, int baz);
ptr<ptr<void(const char*, const char*)>(int, int)> quux(int a, const char* b) { return &foo; }
ptr<T> is more verbose, but I think the uninitiated to the horrors of function pointer syntax actually stand a chance at writing a function definition correctly.

Of course, using callback_t = void(*)(const char*, const char*); or even typedef void (*callback_t)(const char*, const char*); is the idiomatic solution that everybody should use when forced at gunpoint to do this sort of thing.

I forgot the STL pointer classes even existed. When I use C++ it's more like C with classes, so I'm probably the weirdo here.

# ? May 30, 2014 21:41

FamDav: Mar 29, 2008

you keep using that word weirdo like youre not posting on an internet comedy forum about your pointer declaration opinions

# ? May 31, 2014 00:13

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

shrughes posted:

Repeated heap allocation in the same code wouldn't be expensive anyway if you're doing the same small allocation/free over and over again. Unless you have a terrible malloc implementation.

Depends on what you consider "expensive" mostly. It's pretty easy to come up with examples of pulling a small allocation/free out of a loop making the loop twice as fast, which makes the allocation either very expensive (if you're looping over enough things for its speed to be relevant in any way) or completely trivial (if not).

# ? May 31, 2014 00:34

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

Vanadium posted:

just use std::add_pointer<int>::type a, b;

The Laplace Demon posted:

Just use template<typename T> using ptr = T*;

See all you fine dandies so proud, so cock-sure, prancin' aboot bein' able to use C++11. I'm still waiting for the day I can finally write auto butt = fart();

# ? May 31, 2014 11:13

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

Zopotantor posted:

See all you fine dandies so proud, so cock-sure, prancin' aboot bein' able to use C++11. I'm still waiting for the day I can finally write auto butt = fart();

I can't help with lacking auto, but here's a full implementation of add_pointer for C++03:

C++ code:

template<typename T> struct remove_reference     { typedef T type; };
template<typename T> struct remove_reference<T&> { typedef T type; };
template<typename T> struct add_pointer {
    typedef typename remove_reference<T>::type *type;
};

C++03 is no excuse for not having type traits in your toolbox. Modern C++ Design was written 13 years ago.

# ? May 31, 2014 22:01

Edison was a dick: Apr 3, 2010; direct current only

I'm not good with sarcasm over the internet, are people really saying this is better than the C pointer syntax?

# ? May 31, 2014 23:30

Vanadium: Jan 8, 2005

It doesn't have the "int * this_is_pointer, this_isn't;" problem but obviously the std::add_pointer<>::type variant is too verbose. I think ptr<> is worth it at least for function pointers or other weird cases, if not for int main(int argc, ptr<ptr<char>>).

# ? Jun 1, 2014 00:20

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

Edison was a dick posted:

I'm not good with sarcasm over the internet, are people really saying this is better than the C pointer syntax?

ptr<T> is arguably better for function pointers. A (weak) case could be made for ptr<T> elsewhere for the sake of keeping things consistent, and std::add_pointer<T>::type has its place in writing generic library code. If you're writing data member or function member pointers, I think you're just hosed.

I'm genuinely a fan of observer_ptr from MNMLSTC Core. It has the interface of a smart pointer, and it explicitly tells the user that they aren't responsible for freeing the memory. My personal view is that raw pointers don't have a place in modern C++ (11 and later, 03 with boost, etc) unless there's an explicit convention that raw pointers are observers.

Edit:

SAHChandler posted:

Thanks for the plug

Didn't even register your username. Thanks for the awesome library!

Everybody check MNMLSTC Core out. It's absolute top-notch library code implementing standard library additions found in various proposals for C++14 and beyond. There's even (AFAIK) complete docs here. A great drop-in for any project.

The Laplace Demon fucked around with this message at 10:39 on Jun 1, 2014

# ? Jun 1, 2014 00:51

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

Edison was a dick posted:

I'm not good with sarcasm over the internet, are people really saying this is better than the C pointer syntax?

C++ is pretty much an irony-free zone at this point.

# ? Jun 1, 2014 03:12

Lord Windy: Mar 26, 2010

Does anyone have any good resources for learning CMake or Make files?

I'm finding the tools to compile C/C++ programs harder than the actual language. The only good experiences with compiling has been with CMake and Make, but I'm trying to move beyond simple programs into more complex ones but the documentation for both just isn't the best

# ? Jun 1, 2014 06:45

Slurps Mad Rips: Jan 25, 2009; Bwaltow!

The Laplace Demon posted:

I'm genuinely a fan of observer_ptr from MNMLSTC Core

Thanks for the plug

# ? Jun 1, 2014 09:31

Dicky B: Mar 23, 2004

Lord Windy posted:

Does anyone have any good resources for learning CMake or Make files?

I'm finding the tools to compile C/C++ programs harder than the actual language. The only good experiences with compiling has been with CMake and Make, but I'm trying to move beyond simple programs into more complex ones but the documentation for both just isn't the best

If you have a specific CMake problem then you could try the CMake mailing list, or this thread.

# ? Jun 1, 2014 12:15

Marta Velasquez: Mar 9, 2013; Good thing I was feeling suicidal this morning...; Fallen Rib

Lord Windy posted:

Does anyone have any good resources for learning CMake or Make files?

I'm finding the tools to compile C/C++ programs harder than the actual language. The only good experiences with compiling has been with CMake and Make, but I'm trying to move beyond simple programs into more complex ones but the documentation for both just isn't the best

If you want to learn how to make a plain old Makefile, the official GNU documentation is actually pretty good.

# ? Jun 1, 2014 13:39

MrMoo: Sep 14, 2000

There are various slides for CMake online which are Ok introductions:

http://www.bogotobogo.com/cplusplus/files/cmake/CMake-tutorial-pdf.pdf

I tend to find many OSS projects go over crazy with their configuration as they don't understand it that well either. I have a project with both Scons, CMake, and Automake if you want to compare. It's mainly just building a library, I found adding unit testing builds really wanting, Autoconf is spotty.

pre:

Scons
SConstruct
+--Sconscript.autoconf
+--Sconscript.libpgmex
+--Sconscript.libpgm

CMake
CMakeLists.txt
+--cmake
   +--Modules
      +--TestOpenPGMVersion.cmake

Autoconf
bootstrap.sh
+--configure.ac
+--Makefile.am

The modern high level tools: CMake, Scons, etc, need to update frequently with modern compilers which can be quite annoying. MSVC support is quite challenging as CMake only just received minimal toolset support which is only mandatory for XP support on MSVC2012 which is kind of moot now but it doesn't support the paradigm everywhere.

MSVC toolsets are Microsoft's preferred mechanism of using the latest build system with older compiler engines: they explicitly recommend building VC90 projects with VC120 for example instead of VC90 which most developers would go with. This would be OK if Microsoft actually regularly tested, shipped fixes, and didn't deliberately break things:

Microsoft posted:

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.Cpp.Platform.targets(58,5): error MSB8032: The Platform or PlatformToolset is not available from a 64bit environment. Consider building from 32bit environment instead.

# ? Jun 1, 2014 15:37

Lord Windy: Mar 26, 2010

Thanks guys.

That CMake tutorial isn't half bad. I'm already OK at Make, so I might keep trying to learn the two of them and just pick the one I like more at the end. I primarily use Macs so I guess it doesn't matter which one I end up liking

# ? Jun 3, 2014 07:50

Tetraptous: Nov 11, 2004; Dynamic instability during transition.

So you know, CMake can output XCode project files as well as Makefiles, which makes it pretty handy for when you want to use some of Apple's tools (e.g Instruments) on your code.

# ? Jun 3, 2014 14:43

Newf: Feb 14, 2006; I appreciate hacky sack on a much deeper level than you.

Hi again. I'm really bad at this... The Sensor.h file:

code:

#pragma once
#include "resource.h"
#include <vector>

class DeviceEnumerator {
public:
	static vector<CString> GetSensorPorts();


};

the Sensor.cpp file:

code:

#include "Sensor.h"
#include <SetupAPI.h>

int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
	vector<CString> ports = DeviceEnumerator::GetSensorPorts();
	return 0;
}

vector<CString> DeviceEnumerator::GetSensorPorts()
{ 
	return *new vector<CString>;
}

and the errors:

code:

Error	1	error C2143: syntax error : missing ';' before '<'						(.h)
Error	2	error C4430: missing type specifier - int assumed. Note: C++ does not support default-int	(.h)
Error	3	error C4430: missing type specifier - int assumed. Note: C++ does not support default-int	(.h)
Error	4	error C2238: unexpected token(s) preceding ';'							(.h)
Error	5	error C2039: 'GetSensorPorts' : is not a member of 'DeviceEnumerator'				(.cpp)
Error	6	error C3861: 'GetSensorPorts': identifier not found						(.cpp)
Error	7	error C2039: 'GetSensorPorts' : is not a member of 'DeviceEnumerator'				(.cpp)
	8	IntelliSense: #error directive: Please use the /MD switch for _AFXDLL builds	
	9	IntelliSense: vector is not a template	
	10	IntelliSense: declaration is incompatible with "<error-type> DeviceEnumerator::GetSensorPorts()"

Mousing over 'vector' in the method declaration from Sensor.h shows 'class std::vector<CString, std::allocator<CString>>', but mousing over GetSensorPorts in the method definition in Sensor.cpp shows 'Error: declaration is incompatible with "<error-type> DeviceEnumerator::GetSensorPorts()". It looks like the .cpp file doesn't understand the declaration in the .h file?

# ? Jun 4, 2014 18:23

pseudorandom name: May 6, 2007

vector should be std::vector because it is in the std namespace, not the global namespace.

# ? Jun 4, 2014 18:28

Newf: Feb 14, 2006; I appreciate hacky sack on a much deeper level than you.

pseudorandom name posted:

vector should be std::vector because it is in the std namespace, not the global namespace.

Thanks. Why was visual studio able to pick up the correct class (on my mouseover) when the compiler wasn't?

# ? Jun 4, 2014 18:31

pseudorandom name: May 6, 2007

IntelliSense actually uses a completely different C++ parser than the compiler, and probably also searches every namespace simultaneously for the word you're hovering over.

(Ideally, the editor would pass the entire source file and the mouse cursor position to IntelliSense and the match would be completely unambiguous, but if it just passes the text under the cursor without any context, there's no way to know which namespace is relevant.)

pseudorandom name fucked around with this message at 18:37 on Jun 4, 2014

# ? Jun 4, 2014 18:34

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 22:01

nielsm: Jun 1, 2009

Newf posted:

code:

vector<CString> DeviceEnumerator::GetSensorPorts()
{ 
	return *new vector<CString>;
}

Don't do that. Really don't do that.

What you do here is allocate an object on the heap, dereference the new object, construct a copy of that heap-allocated object on the stack, then return that. The heap-allocated object still exists, but there are no references to it. You have a memory leak.

What you should actually do:

C++ code:

std::vector<CString> DeviceEnumerator::GetSensorPorts()
{
	std::vector<CString> ports;
	ports.push_back("stuff");
	return ports;
}

Note the complete absence of the "new" keyword: No (explicit) heap allocations are being done at all. A vector object is allocated on the stack, something is added to it, and then it's returned. The return might cause a copy to be made, but a smart compiler can do optimizations on that.

# ? Jun 4, 2014 18:46

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

«‹›641 »