I'm trying to get the version number presented in cmd command "winver", which in my case is 20H2. How do i get that with code? I have found no posts covering this topic.
IMHO you maintain a map of build numbers and their strings, like
#include <iostream>
#include <map>
int main() {
std::map<int,std::string> builds = {{19042, "20H2"}, {19043, "21H1"}};
std::cout << builds.at(19042) << std::endl;
return 0;
}
and you would get the build number with GetVersion() or GetVersionEx(). See Wikipedia for a list. Note that the build number may be subject to compatibility settings, i.e. Windows may be lying to you.
IMHO Microsoft recommended to check the version of a system DLL like kernel32.dll with GetFileVersionInfo() to get the real version.
If you don't like any of these, getting the name from the Registry may be the option you're looking for:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DisplayVersion
Related
I use MinGW64 to compile c++ programs. But since I upgraded to Windows 10, I found my c program output Chinese will be garbled code.
I follow the online method, adding a code in the program header: SetConsoleOutputCP(65001);, then it fixes. but I think it's so troublesome to do this for each c++ program. What should I do?
I think this is my system's problem, the same code in Windows 7 is not a problem, I just want to find a more convenient solution instead of adding the same code to every file
There's the code:
#include <iostream>
#include <windows.h>
using namespace std;
int main()
{
SetConsoleOutputCP(65001);
cout << "文本" ; //Output will be garbled code if there's no line above
return 0;
}
The console in most operating systems only expects ASCII character input. In order to show some other char set you have to specify that in your code. The SetConsoleOutputCP command sets the "code page" windows should read from. By the way not all versions of windows have the same code for this command.
Please refer to the documentation found here.
The documentation suggests using EnumSystemCodePages to make sure the code for that language exists on that system.
P.S.
Your English is very good :)
EDIT
I tested your code on my computer with Visual Studio 2019 and got the following
Warning C4566 character represented by universal-character-name '\u6587' cannot be represented in the current code page (1255)
even with the SetConsoleOutputCP command you added. I assume you need to have chines installed for this to work. The problem is that I don't have the relevant code page for the windows console to look in for the char set. see this answer and this answer.
According to microsoft's documentation, GetAsyncKeyState() supposedly
Determines whether a key is up or down at the time the function is called
I've been building a UI automation library and the issue boils down to this
#include <Windows.h>
#include <iostream>
#include <chrono>
#include <thread>
using namespace std;
bool IsKeydownAsync(int key) {
return GetAsyncKeyState(key) & 0x8000;
}
int main(){
while (1) {
if (IsKeydownAsync('A')) {
cout << "triggered" << endl;
}
this_thread::sleep_for(chrono::milliseconds(10));
}
}
So my understanding is that it should not matter if my application is in focus or not, the GetAsyncKeyState() should always return whether the physical keys are up or down at the time of being called.
I have tested this over various applications and for most time it behaves as it is described. However, in some games this behavior breaks and it no longer reports whether the key is up or down. cout << "triggered" << endl doesn't get called when the key is held.
Is there something I overlooked?
It has been a while since I worked with native input in Windows, but from experience the Windows API functions only report key-states that are also reported using the synchronzied Windows API functionality, which is to say the normal application message/event input.
Some older games use previous versions of DirectX and alternative ways to capture input, e.g. using a library called the XInput(2) that has been deprecated since Windows 8.1 / 10. While both polling and events/msgs were supported, the input was caught using the DirectX thread and handled entirely differently compared to the Windows API. The main reason for this is that the OS tries to cater to all manufacturers, where the DirectX API did not specificcally address that issue for input.
I want to debug this code segment:
#include <iostream>
#include <queue>
#include <random>
#include <time.h>
using namespace std;
int main()
{
cout << "Hello, World!" << endl;
queue<int> q;
srand(time(NULL));
for(int i = 0; i < 10; i++)
{
q.push(rand() % 100);
}
int a = q.front();
q.pop();
int b = q.front();
q.pop();
cout << "a: " << a << ", b: " << b << endl;
return 0;
}
I tried to debug it on 2 IDEs - CLion (my personal favorite) and VS2015. However, both of those did not show the queue items (as they would if I'd use an array, for instance):
CLion
VS2015
As I continued investigating, I noticed that if I remove the upper breakpoint in CLion, it does show the queue elements:
CLion - good version
Any ideas about why does it happen, and if there's a way to see the queue elements in the "bad" cases?
Removing the upper break point and switching between 32 and 64 bit compilations won't affect this. The 32/64 bits have to do with the generated assembly code. Once the code compiles correctly, the 32 and 64 bit assembly codes won't be the same but the program itself will still retain equivalent functionality. That is, 64 bit programs can't "do more" than 32 big programs. This is an ultra watered-down definition of Turing-completeness, but the upshot here is that it doesn't matter for the purposes of what you're trying to do right now whether you set your build target to 32 or 64 bits.
The IDE that you use will have a minimal effect here though, because they use different Debuggers. Since both debuggers did the same thing in your case, I'd say we can safely chalk it up to user error (see below), but like I said in my afterword, if you will, keep working with the debugger. It's an absolutely essential skill to master. Props to you for getting started early.
As for your debug problem, here is my debug of your program. Notice the breakpoints I used. Like Jesus Christ said before me, the debug worked correctly for both of us. The usual suspect in these cases is trying to debug the release build. When you compile a debug build, the compiler does not perform as many optimizations to allow you to trace your code through the variables and see exactly what's going on. Once your code functions correctly, you can switch to the release version and your compiler will optimize away a lot of the variables for maximum performance.
If you did debug under the Debug build as you said, then I'd say just chalk it up to debugger error. If you're a C++ newbie, there's a chance you just might not be experienced enough to navigate the intricacies of the debugger. No disrespect intended, but debugging is just as much an art as it is a science, and a new developer would not be faulted for not knowing how exactly to maneuver the tool.
I found a solution for the CLion problem - simply press on the variable in the variables tab, then press on Duplicate Watch (marked in red circle bellow, hotkey: ctrl+D) and you're done:
Did you compile with debug selected in the project?
I can clearly see queue values.
Make sure that
1) you are debugging Debug build (that is debug information is present and no optimization is done)
Project Properties -> C/C++ -> General -> Debug information format is set to "Program Database"
Project Properties -> Linker -> Generate Debug info is set to "/DEBUG")
2) raw structure mode is disabled
Tools -> Options -> Debugging -> Show raw structure of objects is not checked
I have written some basic c++ programs in one of my classes for school. I was wondering if it was possible to somehow virtually run the program in a broswer. I would like to post the program to my website. Once its posted, a person could access the program, run the program, and, interact with the program. I'm not trying to write C++ for my website, it would be more for an interactive portfolio.
Is this possible?
Use codepad, a website which lets you compile and share code online.
#include <iostream>
int main(int argc, char** argv) {
std::cout << "Hello, Stack Overflow!" << std::endl;
return 0;
}
There is also Google Native Client SDK that allows C++ code to run in browser. Microsoft Active X is also a viable option. I am only saying it is possible not recommended.
You can only run the program on your server, not on the client's machine.
At least not without downloading and manually executing it. Anything else would be an open door for malware...
I see two options, but both very overkill:
Write (or find) a C++ interpreter in JavaScript
Use a VM running an operating system (e.g. jslinux and demonstrate your programs there.
The sensible option is to just give people a way to view and download the source code, I guess.
Google chrome supports this: http://www.readwriteweb.com/cloud/2011/08/google-officially-announces-cc.php
But it's by no means "mainstream" or standards-based.
Another solution (codepad like) would be to use https://ideone.com/ which seems much nicer to use than codepad, more user-friendly, but does the same:
Allow you to write C++ (60 languages possibles) directly from the browser and compile it and render result in the browser (I tried using printf and it worked fine). Possibility of forking source code.
https://ideone.com/baYzfe
The following two programs are quite useful :
1) Ideone
2) Codepad
You can compile, run, and share code online in any browser.
You can use Emscripten to compile C++ to Javascript. Emscripten can compile LLVM bitcode to Javascript. Some demos of Emscripten can be found here, including a raytracer and a text-to-speech engine that was compiled from C++ to Javascript.
To run x86 binaries in a web browser, you could also use an emulator such as v86. This is one possible way to compile and run C++ programs in a browser.
One of the best sites for running C++ and other multiple languages online is Repl.it
This example: repl.it/#abranhe/stackoverflow
#include <iostream>
int main() {
std::cout << "Hello Stackoverflow\n";
return 0;
}
One of the biggest pros it has is that you can work with multiple files, working with header (header.h) files etc. None of the below websites provide this option:
Codepad.org
JSLinux
IDEone
I really recommend it! You will love it!
Also wanted to add Google Colab here as an option:
Cell 1:
%%writefile hello.cpp
#include <iostream>
int main(int argc, char** argv) {
std::cout << "Hello, Stack Overflow!" << std::endl;
return 0;
}
Cell 2:
%%script bash
g++ hello.cpp -o test
ls -laX
./test
I've been tasked with going through a database and checking all of the links, on a weekly schedule. I normally work in PHP, but doing this in PHP would be very slow (it actually would timeout the page after about 100 URLs), so I decided to make a quick C++ app.
Admitidly, I haven't used C++ since college, so I'm a bit rusty.
I found the ShellExecute function, and that it would open the page no problem. Here is what I have so far:
#include <shlobj.h>
#include <iostream>
using namespace std;
int main()
{
if( ShellExecute(NULL,"find","http://example.com/fdafdafda.php",NULL,NULL,SW_SHOWDEFAULT) )
{
cout << "Yes";
} else {
cout << "No";
}
cout << endl;
system("PAUSE");
return 0;
}
The problem is that it always returns true, whether it is opening a valid page or not. It appears to be checking if the associated app (a browser in this case) is able to open the document with no problems, then returns true. It isn't looking to see if the browser is getting a 404 or not, it simply sees it open and run and is fine.
Is there a better way to do this? Am I missing a step?
As an aside, I have attempted to use the cURLcpp stuff, but can't seem to figure it out. All of the examples point to header files that don't exist in the download. I have a feeling cURLcpp is the better way to do this.
Thanks for any help.
I think you answered your own question. ShellExecute is really not appropriate for this task, and something like CURL would be better.
or if you don't want to use an external library you can check directly with InternetOpen, InternetOpenURL etc.
Documentation on the return value of ShellExecute :
If the function succeeds, it returns a value greater than 32. If the function fails, it returns an error value that indicates the cause of the failure. The return value is cast as an HINSTANCE for backward compatibility with 16-bit Windows applications. It is not a true HINSTANCE, however. It can be cast only to an int and compared to either 32 or the following error codes below.
See ShellExecute documentation.
And yes, CURL would be better.