Thursday, November 10, 2016

Digest for comp.lang.c++@googlegroups.com - 12 updates in 5 topics

"Christopher J. Pisz" <cpisz@austin.rr.com>: Nov 10 01:25PM -0600

I did a Google search to see how to check if a given path is valid,
preferably using boost.
 
It brought me here:
 
http://stackoverflow.com/questions/10426671/how-to-check-if-path-is-valid-in-boostfilesystem
 
Great! I say to myself.
I then Google up the boost doc here:
http://www.boost.org/doc/libs/1_62_0/libs/filesystem/doc/portability_guide.htm
 
I then write myself a test:
 
 
 
#include <iostream>
#include <sstream>
 
#include <boost/filesystem.hpp>
 
int main()
{
const std::string test1 = "D:\\Programing Projects\\Git
Workspace\\Common\\x64\\Debug";
const std::string test2 = "D:\Programing Projects\\Git
Workspace\\Common\\x64\\Debug\\";
const std::string test3 = "D:/Programing Projects/Git
Workspace/Common/x64/Debug";
const std::string test4 = "D:/Programing Projects/Git
Workspace/Common/x64/Debug/";
 
if (!boost::filesystem::native(test1))
{
std::cout << "Boost says the following path is not valid
for the native operating system: " << test1 << std::endl;
}
 
if (!boost::filesystem::native(test2))
{
std::cout << "Boost says the following path is not valid
for the native operating system: " << test2 << std::endl;
}
 
if (!boost::filesystem::native(test3))
{
std::cout << "Boost says the following path is not valid for
the native operating system: " << test3 << std::endl;
}
 
if (!boost::filesystem::native(test4))
{
std::cout << "Boost says the following path is not valid
for the native operating system: " << test4 << std::endl;
 
}
 
return 0;
}
 
The Test's Output:
 
Boost says the following path is not valid for the native operating
system: D:\Programing Projects\Git Workspace\Common\x64\Debug
Boost says the following path is not valid for the native operating
system: D:Programing Projects\Git Workspace\Common\x64\Debug\
Boost says the following path is not valid for the native operating
system: D:/Programing Projects/Git Workspace/Common/x64/Debug
Boost says the following path is not valid for the native operating
system: D:/Programing Projects/Git Workspace/Common/x64/Debug/
 
What is wrong with that path that it says it is not valid for my native
Windows 10 operating system?
Paavo Helde <myfirstname@osa.pri.ee>: Nov 11 12:02AM +0200

On 10.11.2016 21:25, Christopher J. Pisz wrote:
 
> Great! I say to myself.
> I then Google up the boost doc here:
> http://www.boost.org/doc/libs/1_62_0/libs/filesystem/doc/portability_guide.htm
 
All this page appears to talk about names, not paths. I.e. these
functions are meant for checking the path elements, not the full paths.
"Git workspace" is a valid file or directory name, for example.
 
hth
Paavo
"Christopher J. Pisz" <cpisz@austin.rr.com>: Nov 10 04:07PM -0600

On 11/10/2016 4:02 PM, Paavo Helde wrote:
> "Git workspace" is a valid file or directory name, for example.
 
> hth
> Paavo
 
Wow that would be both misleading and somewhat worthless.
Does boost have anything to check if the entire path would be a valid,
where valid means it could be used to create a file or directory, but
does not necessarily point to one?
 
If not, I guess it's regex time?
"Christopher J. Pisz" <cpisz@austin.rr.com>: Nov 10 04:47PM -0600

On 11/10/2016 4:02 PM, Paavo Helde wrote:
> "Git workspace" is a valid file or directory name, for example.
 
> hth
> Paavo
 
I am not conviced that is the problem is we consider this test on Windows:
 
#include <iostream>
#include <sstream>
 
#include <boost/filesystem.hpp>
 
 
// Just a garbage console application to do some manual testing.
int main()
{
std::cout << boost::filesystem::native("C://PATH") << std::endl;
std::cout << boost::filesystem::native("C:/PATH") << std::endl;
std::cout << boost::filesystem::native("C:\\PATH") << std::endl;
std::cout << boost::filesystem::native("\\PATH") << std::endl;
std::cout << boost::filesystem::native("/PATH") << std::endl;
std::cout << boost::filesystem::native("//PATH") << std::endl;
 
std::cout << boost::filesystem::native(reinterpret_cast<char
*>(L"C://PATH")) << std::endl;
std::cout << boost::filesystem::native(reinterpret_cast<char
*>(L"C:/PATH")) << std::endl;
std::cout << boost::filesystem::native(reinterpret_cast<char
*>(L"C:\\PATH")) << std::endl;
std::cout << boost::filesystem::native(reinterpret_cast<char
*>(L"\\PATH")) << std::endl;
std::cout << boost::filesystem::native(reinterpret_cast<char
*>(L"/PATH")) << std::endl;
std::cout << boost::filesystem::native(reinterpret_cast<char
*>(L"//PATH")) << std::endl;
 
return 0;
}
 
 
It seems to report the first 3 of the wide string paths are valid.
This set of boost functions are really confusing.
"Öö Tiib" <ootiib@hot.ee>: Nov 10 03:04PM -0800

On Friday, 11 November 2016 00:47:44 UTC+2, Christopher J. Pisz wrote:
> This set of boost functions are really confusing.
 
It is not confusing. The assholes making OS X, Windows and Linux
are far more confusing. WTF do they want? To screw everybody? Why?

Did you for now sort out "getting error info"?
"Christopher J. Pisz" <cpisz@austin.rr.com>: Nov 10 05:13PM -0600

On 11/10/2016 5:04 PM, Öö Tiib wrote:
 
> It is not confusing. The assholes making OS X, Windows and Linux
> are far more confusing. WTF do they want? To screw everybody? Why?
 
> Did you for now sort out "getting error info"?
 
hehe. Yea I was able to sort out the error codes.
red floyd <dont.bother@its.invalid>: Nov 10 01:47PM -0800

On 11/8/2016 11:22 PM, red floyd wrote:
>> }
>> ]
> Your syntax is off. Look up the syntax for initializer lists.
 
Further hint. Move the initializer list OUTSIDE the braces, thus
 
 
template<class unk>
NODE<unk>::NODE( std::string xt, const unk &x, NODE<unk> *xcl ,
NODE<unk> *xcr, NODE<unk> *xp ) :
states(x),
trait(xt),
cl(xcl),
cr(xcr),
p(xp)
{
std::cout << trait() << " node " << "has the following states => "
<< std::endl;
}
Wouter van Ooijen <wouter@voti.nl>: Nov 10 08:14AM +0100

Op 09-Nov-16 om 9:58 AM schreef David Brown:
>> space, so you can't have a pointer that can point to ROM or RAM. This
>> makes consexpr much less effecitive.
 
> It is more of a problem for const than constexpr.
 
You are technically correct (although in C++14 constexpr implies const),
and constexpr has widened the opportunity for const tremendously.
 
> becomes quite inefficient compared to code using static variables. This
> applies to C as well, but in C++ you regularly have a "*this" pointer as
> well.
 
True, but not a problem for me. My preferred small-system coding style
avoids indirection.
 
> standard C++ classes, no new and delete, no exceptions. But you still
> get strong typing, templates, namespaces, constexpr, classes, etc. (I
> wonder if lambdas work?)
 
I'll have to check. I use AVR only to check whether what I do is
portable to 8 bit.
 
My guess is that std::function doesn't work, but passing a lambda and
using it directly will work.
 
> Or LTO, as it is now - "-fwhole-program" is out of fashion. LTO has its
> challenges with debugging, however.
 
Samll real-time systems are difficult to debug anyway.
 
> People often mistakenly believe that templates mean code bloat. When
> used correctly, and with good tool support, templates can reduce code size.
 
spread the word!
 
> global/static object's constructor refers to another global/static
> object, then the referred-to object should be ordered earlier in the
> constructor list. Then it should all be safe.
 
I wasn't clear, I meant global ctors.
 
Wouter "Objects? No Thanks" van Ooijen
David Brown <david.brown@hesbynett.no>: Nov 10 10:59AM +0100

On 10/11/16 08:14, Wouter van Ooijen wrote:
 
>> It is more of a problem for const than constexpr.
 
> You are technically correct (although in C++14 constexpr implies const),
> and constexpr has widened the opportunity for const tremendously.
 
constexpr implies const in many cases (though in C++14, non-static
constexpr member functions are no longer implicitly const). But there
are many cases of const objects that are not constexpr.
 
>> well.
 
> True, but not a problem for me. My preferred small-system coding style
> avoids indirection.
 
Fair enough. Certainly when programming on the AVR (something I haven't
done much for quite a while, and never in C++) I minimise my pointers.
On an ARM, however, pointers are often more efficient than direct
addressing.
 
It is just something to be aware of if you are looking for the most
efficient code.
 
 
>> Or LTO, as it is now - "-fwhole-program" is out of fashion. LTO has its
>> challenges with debugging, however.
 
> Samll real-time systems are difficult to debug anyway.
 
If this job were easy, anyone could do it!
 
>> object, then the referred-to object should be ordered earlier in the
>> constructor list. Then it should all be safe.
 
> I wasn't clear, I meant global ctors.
 
OK - then I (mostly) agree with you. Global constructors can be nice,
but the ordering problem is a pain. gcc's init_priority __attribute__
can help.
"Öö Tiib" <ootiib@hot.ee>: Nov 09 11:01PM -0800

On Wednesday, 9 November 2016 22:45:18 UTC+2, Christopher J. Pisz wrote:
 
> It appears to be these codes
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=vs.85).aspx
 
> but I want to make sure. IT doesn't mention it in the docs at all.
 
Yep, it seems weakly documented so I started to wonder why it works
in my projects as platform agnostic. :D Appears that it depends on error
category and different error codes of different categories may be
converted or may compare equal. My bots found such mock/hacking tool
from internet somewhere:
 
#include <iostream>
#include <boost/asio/error.hpp>
#include <boost/filesystem.hpp>
#include <boost/system/error_code.hpp>
 
int main()
{
// Two different error codes.
boost::system::error_code code1 = make_error_code(
boost::system::errc::no_such_file_or_directory);
boost::system::error_code code2 = make_error_code(
boost::asio::error::host_not_found_try_again);
 
// That have different error categories.
assert(code1.category() != code2.category());
assert(code1.default_error_condition().category() !=
code2.default_error_condition().category());
 
// Yet have the same value.
assert(code1.value() == code2.value());
assert(code1.default_error_condition().value() ==
code2.default_error_condition().value());
 
// Use the comparision operation to check both value
// and category.
assert(code1 != code2);
assert(code1.default_error_condition() !=
code2.default_error_condition());
 
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// Test with Boost.Filesytem
try
{
boost::filesystem::canonical("bogus_file");
}
catch(boost::filesystem::filesystem_error& error)
{
if (error.code() ==
make_error_code(boost::system::errc::no_such_file_or_directory))
{
std::cout << "No file or directory" << std::endl;
}
if (error.code() ==
make_error_code(boost::asio::error::host_not_found_try_again))
{
std::cout << "Host not found" << std::endl;
}
}
}
Popping mad <rainbow@colition.gov>: Nov 10 04:41AM

On Wed, 09 Nov 2016 16:17:20 +0000, Scott Lurndal wrote:
 
> {
> do stuff here
> }
 
 
 
that is exactly right and beautifully explained. Thank You!!
Popping mad <rainbow@colition.gov>: Nov 10 04:42AM

On Wed, 09 Nov 2016 18:28:20 +0100, Bo Persson wrote:
 
 
> Otherwise you ARE actually defining new functions outside of the
> namespace.
 
> Bo Persson
 
 
 
thank you. That cleared up about 6 hours of my trying to figure that
out!!
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)