|
I always make sure to disable the Microsoft language extensions in the project options (I believe it's in the 'Language' section). That should keep your code relatively clean so it can be ported away from Visual C++ fairly easily. It may take away 64-bit integers all together though since C++ doesn't have one in the standard.
|
#
?
May 24, 2008 23:17
|
|
|
|
| # ? May 18, 2024 07:51 |
|
|
Since there doesn't appear to be a Win32 questions thread, I'll just ask this here: given a PIDL, how does one open the file identified by that PIDL? I know you could convert the PIDL to its display name and use I/O streams, but I think that would fail for stuff that's not a real filesystem object...
|
|
#
?
May 25, 2008 03:14
|
|
|
Can someone explain what I'm doing wrong with semaphores here: http://codepad.org/4MXCzn9o On OSX it compiles, but on fedora it fails to link: sem.c:(.text+0x59): undefined reference to `sem_wait' sem.c:(.text+0x8e): undefined reference to `sem_post' edit: Ok -lpthread to compile, but the output is still wonky. vanjalolz fucked around with this message at 06:32 on May 25, 2008 |
|
#
?
May 25, 2008 06:24
|
|
|
vanjalolz posted:Can someone explain what I'm doing wrong with semaphores here: http://codepad.org/4MXCzn9o You probably need to tell GCC to link to it with -lpthread. OS X shoves a lot of POSIX functions into one huge library (libSystem) which is probably why it worked there. Also, your code doesn't actually compile for me with gcc 4.1 (due to type assignment/argument errors), but I'm guessing you just need to link to that library. I would install the dev man pages for your distribution and make sure you're using the API correctly. Allie fucked around with this message at 06:44 on May 25, 2008 |
|
#
?
May 25, 2008 06:36
|
|
|
Yeah theres something weird about these semaphore functions. I think I'm mixing different implementations because some accept sem_t, others accept an int. This is the code I have now which compiles and runs on fedora, and no longer returns errors from sempost/wait: http://codepad.org/EJVgLXin What's the easiest way to get counting semaphores on posix which continue to work after a fork()? edit: drat, sem_init not implemented on osx :/
|
|
#
?
May 25, 2008 06:50
|
|
|
Smackbilly posted:The context is that I'm writing an app that does asynchronous communication over UDP. Since UDP is unreliable, certain packets that are not ACK'ed after a timeout need to be re-sent. The way I'm currently handling this is: Why are you emulating TCP?
|
|
#
?
May 25, 2008 08:46
|
|
|
Avenging Dentist posted:Since there doesn't appear to be a Win32 questions thread, I'll just ask this here: given a PIDL, how does one open the file identified by that PIDL? I know you could convert the PIDL to its display name and use I/O streams, but I think that would fail for stuff that's not a real filesystem object... I think I figured this out. For the curious, I grabbed the desktop IShellFolder instance with SHGetDesktopFolder and then pulled out an IStream with BindToStorage.
|
|
#
?
May 25, 2008 15:49
|
|
|
Zombywuf posted:Why are you emulating TCP? 1. I didn't write the protocol 2. Not all packets are ACK'ed, only certain important packets 3. I'm not emulating TCP connections or flow control
|
|
#
?
May 25, 2008 17:31
|
|
|
Zombywuf posted:Why are you emulating TCP? TCP is not always necessary.
|
|
#
?
May 25, 2008 18:17
|
|
|
more falafel please posted:TCP is not always necessary. No, but if you're ACKing packets it's usually the better option. But it seems Smackbilly has no say in the protocol so it's moot anyway.
|
|
#
?
May 25, 2008 21:31
|
|
|
Zombywuf posted:No, but if you're ACKing packets it's usually the better option. But it seems Smackbilly has no say in the protocol so it's moot anyway. Lots of games using UDP with a very thin reliable layer on top of it. It can be tweaked to better match their traffic patterns (small packets, no bulk transfers, compensation for loss at the application layer) than TCP. vvvvvvvv Considering the subject, your analogy should be reversed 
haveblue fucked around with this message at 05:26 on May 26, 2008 |
|
#
?
May 26, 2008 00:48
|
|
|
HB posted:Lots of games using UDP with a very thin reliable layer on top of it. It can be tweaked to better match their traffic patterns (small packets, no bulk transfers, compensation for loss at the application layer) than TCP. TCP is way, way, way overkill for most applications. For most applications, it doesn't matter, because the hit you take for using TCP isn't big enough to worry about. There are some applications, games being one of them, where most of the time, you want to reduce bandwidth as much as possible and not waste processing time in the OS doing more checking than you need. Also, many network protocols are not stream-oriented, which leads to building a "message" structure analogous to the underlying packet structure inside the TCP stream, which is in turn on top of the packet structure. I don't have any idea if a reliable UDP layer is the right tool for Smackbilly's protocol, but he apparently has no control over it. But it's not "emulating TCP" any more than an RDBMS is "emulating a hash table".
|
|
#
?
May 26, 2008 05:13
|
|
|
I'm trying to write a program that could cause my Windows XP computer to do a BSOD. This is apparently harder than I had imagined. Does anyone have a short code snippet that could do this?ZorbaTHut posted:With admin access, or without admin access? With admin access. I'm just trying to kill my dell. Could you give me a little more in-depth hint? I'm not too hot on C++ yet. Boz0r fucked around with this message at 14:06 on May 26, 2008 |
|
#
?
May 26, 2008 13:51
|
|
|
Boz0r posted:I'm trying to write a program that could cause my Windows XP computer to do a BSOD. This is apparently harder than I had imagined. Does anyone have a short code snippet that could do this? With admin access, or without admin access? Without admin access it should be impossible. With admin access you could always grab the Driver Development Kit, head to Ring 0, and just clobber random bits of RAM.
|
|
#
?
May 26, 2008 14:01
|
|
|
Boz0r posted:I'm trying to write a program that could cause my Windows XP computer to do a BSOD. This is apparently harder than I had imagined. Does anyone have a short code snippet that could do this?
|
|
#
?
May 26, 2008 14:18
|
|
|
HB posted:vvvvvvvv Considering the subject, your analogy should be reversed Boz0r posted:With admin access. I'm just trying to kill my dell. Please don't futurequote, it makes threads hell to read. 
|
|
#
?
May 26, 2008 14:35
|
|
|
I've got a C program I'm fixing/updating and there are couple constants I can't identify that hopefully someone recognizes. The program basically is a wrapper around a plain text file before sending it off to a printer. It does things like add page numbers, line numbers, a header saying what file is being printed, etc. The program used to talk straight to a HP LJ 4m+. The network changed a bit and now that printer is accessed by going through an LPD print server (and hence why I'm updating the program). It has a whole bunch of undocumented usage of PCL 5e (HP's Printer Control Language) that I've been deciphering. However the constants in question don't quite look like PCL commands, which is a lot of the reason I'm confused. The constants are: code:The minimal documentation about -T is "do print through terminal to laserjet". The other weird thing is PRT_ON is printed before job control commands (ie simplex/duplex and orientation PCL commands) and PRT_OFF is printed immediately following the job control commands and before the contents of the file that is being processed. I don't think these are PCL commands because PCL commands start with ESC (hex 0x1B, octal 033, decimal 27). However other PCL commands were declared using \033, so I can't rule out that these were typos and should have had an extra 0 to make them octal constants. But I haven't run across any PCL commands that use a [ and PCL commands terminate by a capital letter, which "i" is not. (Keep in mind I hardly knew what PCL was a few hours ago, so I can't say authoritatively that they are not PCL commands) Does anyone recognize what those constants do?
|
|
#
?
May 27, 2008 21:39
|
|
|
They look like those ANSI escapes used to get colored text on terminals. 
|
|
#
?
May 27, 2008 21:41
|
|
|
Vanadium posted:They look like those ANSI escapes used to get colored text on terminals. I think you've got it. According to here those commands do: quote:Stop Print Log <ESC>[4i Now this does mean that the program didn't correctly function earlier since the constant would need to be \033, not \33, but it clearly is almost the intended behavior of the original programmer. (The order of PRT_ON and PRT_OFF also need to be switched in the code to suppress the job control commands, which I believe is the intended behavior) This also explains why it was hard to find these commands in PCL references.
|
|
#
?
May 27, 2008 22:02
|
|
|
6174 posted:Now this does mean that the program didn't correctly function earlier since the constant would need to be \033, not \33, I've started looking at '\0' in a whole new light since I found out it's a second-class octal zero and not a good and proper decimal zero.
|
|
#
?
May 28, 2008 09:22
|
|
|
TSDK posted:Nope, the '33' is taken to be octal. You can only specify numeric escape sequences as either octal or hexadecimal. Interesting. I guess I was too quick to assume the old guy made a mistake. I'm just too used to weird bugs or weird practices in his code. Like that C program I was working on yesterday was in K&R C, despite being up updated every couple years (though it was started in 1990, so being K&R C isn't too odd).
|
|
#
?
May 28, 2008 14:31
|
|
|
Hi, I'm having some problems with linker errors when compiling a small test program. I'm using C++, with SDL, and whenever I try to use a vector I get the errorquote:Main.obj : error LNK2001: unresolved external symbol __imp___CrtDbgReportW quote:vector <int> i_vec; quote:vector <int> i_vec; SDL on it's own is fine, and vectors on their own are fine, but the two don't seem to want to mix. I'm using Visual C++ 2008 Express Edition, and I've seen various 'solutions' to this problem. However, they are all way over my head, and I can't work out what I'm supposed to be changing to solve it. Some talk about different library versions, and 'Debug vs. Release' settings, but I have no idea what these amount to. Can anyone help? I can provide project settings on request. I apologise for the low-level of the problem.
|
|
#
?
May 29, 2008 21:17
|
|
|
Staggy posted:Can anyone help? I can provide project settings on request. Yes, please do that. The base problem is that, when compiled in "Debug" mode (which contains lots of extra debug info, so it's slow and bloated but lets you use the debugger) Visual Studio adds extra error checking and stats gathering behind the scenes in its vectors (so vector<T>::push_back calls CrtDbgReportW as well as doing all its regular work). For some reason you're compiling in debug mode but not linking to the version of the library that contains the extra debug report functions.
|
|
#
?
May 29, 2008 21:52
|
|
|
Staggy posted:Hi, I'm having some problems with linker errors when compiling a small test program. I'm using C++, with SDL, and whenever I try to use a vector I get the error
|
|
#
?
May 29, 2008 21:54
|
|
|
C++->Code Generation->RunTime Library: Multi-threaded DLL Linker->Input->Additional Dependencies: SDL.lib SDLmain.lib sdlgfx.lib Linker->Debugging->Generate Debug info: Yes Those are the settings that ring a bell, if there's anything specific, or some way for me to post the settings file, please just ask. EDIT: http://www.filefactory.com/file/f6f853/ That's the source code so far, but as far as I understand this is more of a settings problem than a code problem. (?) Staggy fucked around with this message at 22:31 on May 29, 2008 |
|
#
?
May 29, 2008 22:17
|
|
|
I believe you need to change "Multi-threaded DLL" to "Multi-threaded debug DLL". Although it may do that for you, in which case I'll have to reboot to Windows and look closer.
|
|
#
?
May 29, 2008 22:41
|
|
|
With that change the errors change to quote:Linking...
|
|
#
?
May 29, 2008 23:06
|
|
|
Ok, sanity check: This is the Debug profile, right? So everything should be debug. If you're building in the Release profile, you need to do the opposite: put it back to just "Multi-threaded DLL" and then turn "Generate Debug Info" off. Also, go to C++->Code Generation and make sure that, if it's the Debug profile, the DEBUG symbol is defined and NDEBUG is not, and vice versa if it's the Release profile.
|
|
#
?
May 29, 2008 23:20
|
|
|
Does anyone have some good "first project" introductory programs that someone first starting C++ could cut their teeth on? I took an introductory CSE course at my school (Java) and I'm familiar with the basic concepts of OOP but I'm still trying to understand the way you do things in C++. I'm not interested in learning an "easier" language: I've been turned down several physics internships because they needed C++ programming experience, so I want to learn C++. All I've done so far is write a program that determines if a number is prime or not/prints out a list of primes from one number to another and I've done a few Euler challenges but nothing that hard. I've read through all of these C++ tutorials and I've done some of their examples. Something along the lines of these projects for Java. Also, some more general questions: When should you use cout as opposed to printf? And scanf as opposed to cin? When you use std::function is that just calling the function in std without having to put "using namespace std;" at the top?
|
|
#
?
May 30, 2008 00:25
|
|
|
Insurrectum posted:When should you use cout as opposed to printf? And scanf as opposed to cin? Always and never, respectively. There's no reason to use C I/O functions in C++ when there are C++ I/O functions that do everything the C functions do. quote:When you use std::function is that just calling the function in std without having to put "using namespace std;" at the top? Yes. The :: is the scope-resolution operator. You know how when you declare a local variable in a function that variable is not accesible outside the function, so you can re-use the name in other places? Namespaces work kind of the same way, except that you can explicitly refer to a variable inside a namespace from outside that namespace by using namespace::variable. For example, cout is a variable inside the std namespace. "using namespace std;" means "import ALL of the variable names from the std namespace into the current namespace". You can of course refer to any variable in the current namespace without ::, so this allows you to write cout instead of std::cout. (Note that if you have not declared a namespace, you are working in a default unnamed namespace, which is usually fine) In some respects "using namespace" is poor style because you're polluting your current namespace with lots of variables that you may not really need. You can be more restrictive by writing "using std::cout;" and "using std::endl;", etc, to import specific variables from another namespace. If you are familiar with Java, "using namespace foo" is like "import foo.*" and "using foo::bar" is like "import foo.bar". However unlike Java, namespaces are not necessarily associated with a class (although every class is also a namespace). Smackbilly fucked around with this message at 00:44 on May 30, 2008 |
|
#
?
May 30, 2008 00:37
|
|
|
Smackbilly posted:Always and never, respectively. There's no reason to use C I/O functions in C++ when there are C++ I/O functions that do everything the C functions do. Alright, those things make a bit more sense now. Thanks!
|
|
#
?
May 30, 2008 00:48
|
|
|
Smackbilly posted:Always and never, respectively. There's no reason to use C I/O functions in C++ when there are C++ I/O functions that do everything the C functions do. One big reason to avoid C++ I/O functions is that they add an implicit dependency on exception handling mechanisms which isn't always an acceptable option. Smackbilly posted:In some respects "using namespace" is poor style because you're polluting your current namespace with lots of variables that you may not really need. You can be more restrictive by writing "using std::cout;" and "using std::endl;", etc, to import specific variables from another namespace. In practice there's nothing wrong with "using namespace ...", in fact as someone who used to work in QA I greatly encourage people to use it because seeing fully qualified names littered throughout code is ugly as sin and in an individual translation unit there's no real danger regarding namespace pollution. The exception to this is in public header files -- people who import namespaces in public headers need to be shot.
|
|
#
?
May 30, 2008 03:23
|
|
|
ehnus posted:One big reason to avoid C++ I/O functions is that they add an implicit dependency on exception handling mechanisms which isn't always an acceptable option. Okay but if you're eschewing all forms of exceptions, then you're also tossing out STL and basically working in C-with-classes. I suppose some people do that, though. quote:In practice there's nothing wrong with "using namespace ...", in fact as someone who used to work in QA I greatly encourage people to use it because seeing fully qualified names littered throughout code is ugly as sin and in an individual translation unit there's no real danger regarding namespace pollution. The exception to this is in public header files -- people who import namespaces in public headers need to be shot. I wasn't advocating using fully qualified names, I was advocating the middle ground of using "using" statements that specify exactly which symbols you wish to import.
|
|
#
?
May 30, 2008 03:39
|
|
|
ehnus posted:One big reason to avoid C++ I/O functions is that they add an implicit dependency on exception handling mechanisms which isn't always an acceptable option.
|
|
#
?
May 30, 2008 03:39
|
|
|
Smackbilly posted:Okay but if you're eschewing all forms of exceptions, then you're also tossing out STL and basically working in C-with-classes. I suppose some people do that, though. What are you talking about? The STL throws exceptions in only a few places.
|
|
#
?
May 30, 2008 04:54
|
|
|
Smackbilly posted:Always and never, respectively. There's no reason to use C I/O functions in C++ when there are C++ I/O functions that do everything the C functions do. Except the C++ I/O functions are much more verbose and heavyweight. Also, good luck using C++ I/O for binary I/O.
|
|
#
?
May 30, 2008 04:55
|
|
|
Basically, I/O streams is poo poo. It's, by far, the worst aspect of the C++ standard libraries, and my greatest wish is to see them replaced with a halfway decent I/O library in the next-next standard.
|
|
#
?
May 30, 2008 05:37
|
|
|
Mustach posted:That's not a big reason for any beginner. I didn't see the "for the beginner" qualification in the post I was responding to, just a blanket qualification that there's no reason to ever choose standard C I/O over C++ I/O. Smackbilly posted:Okay but if you're eschewing all forms of exceptions, then you're also tossing out STL and basically working in C-with-classes. I suppose some people do that, though. A language isn't its standard library. floWenoL posted:Except the C++ I/O functions are much more verbose and heavyweight. Also, good luck using C++ I/O for binary I/O. Yeah, they're not that intuitive. Compare code:code:code:instead? Why do I manually have to remember and reset the fill and width parameters for the next field I want to output? Needless complexity bugs me and the C++ standard library unfortunately is full of it (vector<bool>, I'm looking at you).
|
|
#
?
May 30, 2008 05:59
|
|
|
ehnus posted:Why can't I do something like Because they are called setfill and setw respectively. quote:Why do I manually have to remember and reset the fill and width parameters for the next field I want to output? Personally I find a set of member functions or iostream manipulators to define formatting much more intuitive than a formatting "DSL" that is interpreted by *printf at runtime. We all hate DSLs, no? iostreams are also probably more flexible than having to generate format strings at runtime, if you want more dynamic formatted output, and of course printf cannot be used to print user-defined types. Is there any existing alternative to iostreams that could be incorporated into the next standard?
|
|
#
?
May 30, 2008 08:23
|
|
|
|
| # ? May 18, 2024 07:51 |
|
|
JoeNotCharles posted:Ok, sanity check: If I build in Debug I get that error, but if I switch to Release to build I get quote:MSVCRT.lib(crtexew.obj) : error LNK2001: unresolved external symbol _WinMain@16
|
|
#
?
May 30, 2008 09:04
|
|