|
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 |
|
|
# ? Jun 8, 2024 06:26 |
|
I hadn't seen that you had to specifically select a 64-bit platform
|
# ? May 27, 2014 10:55 |
|
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 |
|
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: I had to do this for tiling in a dumb little game I made recently. My code was roughly: code:
|
# ? May 30, 2014 04:43 |
|
Are the following two lines of code the same thing?code:
|
# ? May 30, 2014 13:50 |
|
Yes.
|
# ? May 30, 2014 13:53 |
|
Newf posted:Are the following two lines of code the same thing? Yes. This is also equivalent: code:
|
# ? May 30, 2014 13:54 |
|
Great, thanks.
|
# ? May 30, 2014 13:57 |
|
Newf posted:Are the following two lines of code the same thing? 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:
|
# ? May 30, 2014 18:04 |
|
Or better yet, don't do that and stick to the other style.
|
# ? May 30, 2014 18:09 |
|
just use std::add_pointer<int>::type a, b;
|
# ? May 30, 2014 19:22 |
|
Just use template<typename T> using ptr = T*; ptr<int> a, b; is literally impossible to mess up.
|
# ? May 30, 2014 19:58 |
|
The Laplace Demon posted:Just use template<typename T> using ptr = T*; It also lets you easily define function pointers. ptr<int(int)> f
|
# ? May 30, 2014 20:29 |
|
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. Altimor fucked around with this message at 21:35 on May 30, 2014 |
# ? May 30, 2014 20:55 |
|
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:
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 |
|
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 |
|
Altimor posted:The STL containers always allocate space for elements on the heap.
|
# ? May 30, 2014 21:25 |
|
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...)>. You could also use std::reference_wrapper<T(Args...)>
|
# ? May 30, 2014 21:28 |
|
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 |
|
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...)>. 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 |
|
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 |
|
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.
|
# ? May 31, 2014 00:34 |
|
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 |
|
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:
|
# ? May 31, 2014 22:01 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
The Laplace Demon posted:I'm genuinely a fan of observer_ptr from MNMLSTC Core Thanks for the plug
|
# ? Jun 1, 2014 09:31 |
|
Lord Windy posted:Does anyone have any good resources for learning CMake or Make files?
|
# ? Jun 1, 2014 12:15 |
|
Lord Windy posted:Does anyone have any good resources for learning CMake or Make files? 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 |
|
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 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 |
|
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 |
|
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 |
|
Hi again. I'm really bad at this... The Sensor.h file:code:
code:
code:
|
# ? Jun 4, 2014 18:23 |
|
vector should be std::vector because it is in the std namespace, not the global namespace.
|
# ? Jun 4, 2014 18:28 |
|
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 |
|
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 |
|
|
# ? Jun 8, 2024 06:26 |
Newf posted:
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:
|
|
# ? Jun 4, 2014 18:46 |