Code doesn't do anything useful. It's just try & error code to figure out what's going on:
fs::path path("e:\\Σtest");
cout<<path << " exsits="<< fs::exists(path) << " is dir=" << fs::is_directory(path) << std::endl;
fs::path pathL(L"e:\\Σtest");
cout<<pathL << " exsits="<< fs::exists(pathL) << " is dir=" << fs::is_directory(pathL) << std::endl;
fs::path pathu(u"e:\\Σtest");
cout<<pathu << " exsits="<< fs::exists(pathu) << " is dir=" << fs::is_directory(pathu) << std::endl;
Output:
e:\Σtest exsits=0 is dir=0
e:\Σtest exsits=0 is dir=0
e:\Σtest exsits=0 is dir=0
I sure that folder Σtest exists. I guess there is encoding involve somehow. I can't figure out what sophisticated problem we have encounter here, someone can explain output?
EDIT:
Following #cpplearner advice to pass /utf-8 to compiler output changes (also code page for console was changed to utf-8 by chcp 65001):
e:\Σtest exsits=0 is dir=0
e:\?test exsits=1 is dir=1
e:\?test exsits=1 is dir=1
Question remain the same, what magic happen here?
Related
I had been seeing some code snippet from someone as shown below:
before changed:
void pal::type3_message::debug_print(std::ostream & out) const
{
out << "### type3_message:" << '\n'
<< pal::as_hex_dump(as_bytes())
<< "lm_response = " << pal::as_hex_string(lm_response_)
<< "\nnt_response = " << pal::as_hex_string(nt_response_)
<< "\ndomain = " << domain_
<< "\nuser = " << user_
<< "\nworkstation = " << workstation_
<< "\nsession_key = " << pal::as_hex_string(session_key_)
<< std::hex << std::setw(8) << std::setfill('0')
<<"\nssp_flags = " << ssp_flags_;
}
after changed:
std::string pal::type3_message::debug_print() const
{
std::ostringstream buf;
buf << "### type3_message:" << '\n'
<< pal::as_hex_dump(as_bytes())
<< "lm_response = " << pal::as_hex_string(lm_response_)
<< "\nnt_response = " << pal::as_hex_string(nt_response_)
<< "\ndomain = " << domain_
<< "\nuser = " << user_
<< "\nworkstation = " << workstation_
<< "\nsession_key = " << pal::as_hex_string(session_key_)
<< std::hex << std::setw(8) << std::setfill('0')
<<"\nssp_flags = " << ssp_flags_;
return buf.str();
}
I am not very sure of the change above, is anyone can tell me how that should happened and the deep significance of it ? look forward for response and appreciate of it.
I'm not exactly sure what you are asking, so I'm just explaining what the code sample does and what the major difference between both functions is:
void pal::type3_message::debug_print(std::ostream & out) const
This function writes a message to an output stream that is referenced by the out parameter. It has no return value.
std::string pal::type3_message::debug_print() const
This function seems to output the same message but instead of writing it to a stream, it stores the message in a string. This string is returned by the function.
The implementation of both functions looks very similar because the 2nd function uses a temporary std::ostringstream internally. This is a stream that exist in memory only. In contrast, you could pass a file stream like std::ofstream to the 1st function.
Please clarify your question if you want to know more.
can tell me how that should happened and the deep significance of it?
The first method receives an std::ostream& parameter, and streams more than 10 different chunks of text into it.
The second method streams the same 10 chunks of text into a locally created (automatic var) std::ostringstream. This concatenates the chunks prior to returning the string.
Possible usage examples (to achieve same output on std::cout):
pal::type3_message::debug_print(std::cout);
std::cout << std::endl;
and
std::cout << pal::type3_message::debug_print() << std::endl;
I prefer the std::stringstream approach, but I have used both.
In the first method, the thread can be 'interrupted' in more places (between the 10) with possible impact to the not private stream effort. Does this cause an issue? I have not investigate on a desktop.
The second method completes the concatenation, then returns a string. All the previous interruption points are still there, but none affect the delivery to std::cout, a shared stream destination. Note there is still 1 (or maybe 2) interruptions places in this path (to append the string). Still, this is probably less likely to produce visible issues.
In an embedded system I once worked on, because of drivers it had, the second method was clearly better (in terms of thread interruptions during use) and appeared it did not need mutex guard on the out channel.
On Ubuntu, I have added mutex guard's to access std::cout ... to avoid the 'inter-mixed' text, though I did not confirm that the change-described-in-this-post could have been sufficient.
I have an in-ram-log with a round-robin-buffer, and that shared resource has a mutex guard. Never any problems with multiple threads contributing to the same log.
Note: Per the post Question, I see no difference in either stream effort with respect to std::hex or std::setw, both are used identically.
update per July 2, comment
I agree that 'after' is what I prefer.
I do not recognize the phrase "do not mess with borrowed things". I looked and decided Google's report on this phrase had no software relevance.
But it reminded me of a possibly related caution I have heard, "code is like an onion". The guy who repeated this to me (obsessively) resisted 'fixing' things (a crash for example) because, I surmise, he worried that any changes might break 'behaviour' in an undetectable manner. Thus, he worked through 'all the onion layers' until he was sure nothing bad would happen, before he committed a code change. 'Paralysis by analysis' comes to mind.
I am, apparently, much more tolerant to trying something else (and test, test, test...) That crash was easy to fix, and the crash certainly held up progress on understanding the deeper layers of the onion.
I don't know exactly how to define what I am searching, but, here I go:
Since the library libjsoncpp exists and lets us hold a value in an object that is "json based", which means, an integer, an unsigned number, double, string or null... (also arrays and objects that can be seen -or I perceive- as pointer based objects to other objects),
... is there any kind of library in which we could operate with those data, more or less as we do in javascript?
#include "somemagiclib.h"
magicnamespace::jsonlike_o value1=10;
int integervalue=15;
magicnamespace::jsonlike_o value2="hello_world";
std::string anything="anything";
magicnamespace::jsonlike_o value3="10.3";
magicnamespace::jsonlike_b result;
value3=value2+value1;
std::cout << "value3 is: " << value3.asString() << std::endl;
/*value3 is: 21*/
std::cout << (value2+value1).asString() << std::endl;
/*hello_world10*/
std::cout << (value1+value3).asString() << std::endl;
/*20*/
std::cout << (value3+value1).asString() << std::endl;
/*10.310*/
std::cout << (value1<value3).asString() << std::endl;
/*true*/
std::cout << (value1+integervalue).asString() << std::endl;
/*25*/
std::cout << (value1+anything).asString() << std::endl;
/*18*/
std::cout << (value1>=integervalue).asString() << std::endl;
/*false*/
std::cout << (value2+integervalue).asString() << std::endl;
/*hello_world15*/
std::cout << (value2+anything).asString() << std::endl;
/*hello_worldanything*/
We could easily reach to the ask "what for?" (...or even "wtf for?"). In fact, I am working on a project that requires a part of json processing to compare values that are obtained from part based ports transmitting in serial protocols, compared with values that are obtained from json based configured files.
Being able to code or preview the future scenarios is becoming difficult, since we also have to preview incoming values from JsonRPC based objects, so the code may become expensive to generate or to maintain.
Do you know if there's any kind of library that implements this kind of "non-typed" type in C++?
In case of not knowing, do you think that this kind of library deserves the efforts to be created?
Thank you very much for your attention.
Look into crow c++. its not just json stuff, its pretty much flask for c++. might be useful. it's also just a header file, so no installation etc is needed
Well i was creating a program in c++ .Then i noticed that there were some error due to which my program was not functioning correctly
compiler used:- Dev c++
Error was this:-
Suppose n1=274877906944 which is 2^38. so log(n1) should be 38 which is correct. now let n2=274877906942 which is smaller than n1.
So that means if we calculate log(n2) then it must give me less than log(n1).But log(n2) gave me the same result as log(n1) which is 38.
Which is wrong!!!
Someone please explain this stuff..
You see the result that you do because of rounding. If you increase your precision, it'll be okay (note that the log2 function in <cmath> will cast your integers to double):
std::cout << std::fixed;
std::cout << std::setprecision(16);
std::cout << static_cast<double>(274877906944) << std::endl;
std::cout << static_cast<double>(274877906942) << std::endl;
std::cout << static_cast<double>(274877906948) << std::endl;
std::cout << log2(274877906944) << std::endl;
std::cout << log2(274877906942) << std::endl;
std::cout<< log2(274877906948) << std::endl;
Produces:
274877906944.0000000000000000
274877906942.0000000000000000
274877906948.0000000000000000
38.0000000000000000
37.9999999999895053
38.0000000000209965
Demo
I am relatively new to CLang and Libtooling. I want to display a Line from the source code on the terminal. I have a *VisitFunctionDecl(FunctionDecl func) in the RecursiveASTVisitor. For every function I get the SourceRange and from that the SourceLocation. But I dont understand how to display that. I has something to do
You need the FullSourceLoc:
FullSourceLoc functionDeclFullLocation = Context->getFullLoc(func.getLocStart());
if (functionDeclFullLocation.isValid())
llvm::outs() << "Found FunctionDecl at "
<< functionDeclFullLocation.getManager().getFilename(functionDeclFullLocation) << ":"
<< functionDeclFullLocation.getSpellingLineNumber() << ":"
<< functionDeclFullLocation.getSpellingColumnNumber() << "\n";
I am using Qt, and I have an unsigned char *bytePointer and want to print out a number-value of the current byte. Below is my code, which is meant to give the int-value and the hex-value of the continuous bytes that I receive from a machine attached to the computer:
int byteHex=0;
byteHex = (int)*bytePointer;
qDebug << "\n int: " //this is the main issue here.
<< *bytePointer;
std::cout << " (hex: "
<< std::hex
<< byteHex
<< ")\n";
}
This gives perfect results, and I get actual numbers, however this code is going into an API and I don't want to use Qt-only functions, such as qDebug. So when I try this:
int byteHex=0;
byteHex = (int)*bytePointer;
std::cout << "\n int: " //I changed qDebug to std::cout
<< *bytePointer;
std::cout << " (hex: "
<< std::hex
<< byteHex
<< ")\n";
}
The output does give the hex-values perfectly, however the int-values return symbols (like ☺, └, §, to list a few).
My question is: How do I get std::cout to give the same output as qDebug?
EDIT: for some reason the symbols only occur with a certain Qt setting. I have no idea why it happened but it's fixed now.
As others pointed out in comment, you change the outputting to hex, but you do not actually set it back here:
std::cout << " (hex: "
<< std::hex
<< byteHex
<< ")\n";
You will need to apply this afterwards:
std::cout << std::dec;
Standard output streams will output any character type as a character, not a numeric value. To output the numeric value, convert to a non-character integer type:
std::cout << int(*bytePointer);