Monday, May 16, 2016

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

woodbrian77@gmail.com: May 16 11:19AM -0700

On Tuesday, May 10, 2016 at 1:17:36 AM UTC-5, Juha Nieminen wrote:
 
> Out of wood. With stone age technology. We can't build a seaworthy ship
> out of wood even with modern technology and modern materials because
> it's just not physically feasible.
 
What about the ships the Pilgrims used to escape from
Europe? They were made out of wood and seaworthy
enough to get them across the Atlantic. The ark
didn't have to last for a long time, but it had to
be strong enough to endure a lot for a few months.
Maybe Noah and company had to patch up a few spots
on a daily basis. Bug fixes to the ark.
 
 
> other culture or religion. You give this particular myth special
> treatment because of your own religion and your own biases, and
> you are incapable of seeing it in a more level-headed context.
 
I'm following in the footsteps of people like William Bragg
 
http://www.britannica.com/biography/William-Bragg
 
He said, "Religion and science are opposed, but only in the
same way that my thumb and forefinger are opposed, and between
them, I can grasp everything."
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
Gareth Owen <gwowen@gmail.com>: May 16 10:04PM +0100

>> out of wood even with modern technology and modern materials because
>> it's just not physically feasible.
 
> What about the ships the Pilgrims used to escape from Europe?
 
If you're going to elide 4000 years of developments in vehicle
technology[0], why not go the whole hog just have Noah build a
gopher-wood space shuttle.
 
[0] assuming that the flood was in 2304BCE, as I dutifully and
unquestioningly believe, having just read it on creation.com
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 15 04:31PM +0200

On 15.05.2016 16:12, Stefan Ram wrote:
 
> One can see in line 22 that there is a spurious »\n«
> that my news server seems to have inserted into your
> post.
 
That's called "flowed format": a space before the line ending signifies
a logical line continuation when you have
 
Content-Type: text/plain; charset=windows-1252; format=flowed
 
It's just one of the dangers of a DIY news client (assuming that's what
you're using), that there's no team to keep it up with the evolving de
facto standards.
 
Not sure of which RFC or whatever, sorry. I did know about 10 years ago
or so.
 
 
Cheers & hth. :),
 
- Alf
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 15 05:06PM +0200

On 15.05.2016 17:04, Stefan Ram wrote:
> with »/*« because they are more robust should the program
> ever be transferred across a medium where spaces and
> line-break characters might be exchanged.
 
lols. :)
 
 
Cheers!,
 
- Alf
asetofsymbols@gmail.com: May 16 01:20PM -0700

For me there is too much complexity
For me all is already easy
with assembly + C + classes from
Compilers 1990
ram@zedat.fu-berlin.de (Stefan Ram): May 15 02:54PM

>That's called ''flowed format'': a space before the line ending signifies
>a logical line continuation
 
I looked this up and used »RFC 2646« of the standards track.
 
It does not speak of »logical lines« but of »paragraphs«.
 
Paragraphs are units of natural-language prose, such as
English. In English paragraphs, the meaning of a space
usually is the same as the meaning of a new-line character.
In C++, it is not, e. g.:
 
a = 2;
// a = 3; a = 4;
 
has another effect than
 
a = 2;
// a = 3;
a = 4;
 
. And the RC 2646 therefore (because in English paragraphs
the distinction does not matter) says:
 
»A value of Flowed indicates that the definition of flowed text (as
specified in this memo) was used on generation, and MAY be used on
reception.«
 
. I did not uppercase the word »MAY«; it was uppercased in
the RFC already.
 
This regulation is appropriate for Englisch because an
English-language paragraph that contains some line breaks in
other positions still has the same meaning. So, when the
definition of flowed text is /not/ used on reception, it
does not change the meaning of an English language
paragraph.
 
Using »Format=Flowed« by this RFC indicates that the sender
agrees that on reception the definition of flowed text may
be used or may be used not (because the RFC says »MAY«).
This is appropriate for English prose, but not for C++
source code, where the difference matters.
ram@zedat.fu-berlin.de (Stefan Ram): May 15 03:04PM

>a = 2;
>// a = 3;
>a = 4;
...
>be used or may be used not (because the RFC says »MAY«).
>This is appropriate for English prose, but not for C++
>source code, where the difference matters.
 
And what does this have to do with C++?
 
As I already wrote before: The lesson is:
 
When writing C++ source code, prefer comments that start
with »/*« because they are more robust should the program
ever be transferred across a medium where spaces and
line-break characters might be exchanged. Because
 
a = 2
/* a = 3; a = 4; */
 
still /does/ have the same meaning as
 
a = 2;
/* a = 3;
a = 4; */
 
.
bleachbot <bleachbot@httrack.com>: May 13 12:35AM +0200

Ramine <ramine@1.1>: May 13 01:50PM -0700

Hello...
 
 
My C++ synchronization objects library was updated again..
 
After i have included the 32 bit and 64 bit C++Builder makefiles
 
and after i have made my library follow the ISO C++ standard.
 
Now i have changed my SemaMonitor C++ implementation, because
since C++ allow the conversion from signed to unsigned , i
have made the paramaters of wait() and signal() methods and
also the constructors parameters to not accept negative values.
 
So now i have made my C++ synchronization objects library a
great library, and i think you can be confident because it is more
stable now.
 
You can download my new updated C++ synchronization objects library from:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 13 05:13PM -0700

Hello....
 
 
One last touch...
 
My C++ synchronization objects library was updated again..
 
I have corrected something in the C++ code of my SemaMonitor
so that it compiles without warning with C++Builder.
 
So now i have made my C++ synchronization objects library a
great library, and i think you can be more confident because it is more
stable now.
 
You can download my new updated C++ synchronization objects library from:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
 
Thank you,
Amine Moulay Ramdane.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 16 06:39AM +0200

I just coded up this and I wonder if there's much wrong with this code,
and/or improvements to the design, and/or kind words about my hairdo?
 
I don't have any test cases for this, at all.
 
And that's another thing I wonder about: how would one go about testing
code like this? I'm not even sure of requirements on template param.
 
 
<file Optional_.hpp>
#pragma once
// Copyright © 2016 Alf P. Steinbach
 
#include "type_builders.hpp" // cppx::(Ref_, Rvref_, Ptr_)
#include "hopefully_and_fail.hpp" // cppx::(hopefully, fail)
 
#include <memory> // std::align
#include <new> // ::operator new( size_t, void* )
#include <type_traits> // std::aligned_union_t
 
namespace cppx {
struct None {};
 
// The Optional_ class is intended to be an optimization of this
spec, modulo
// the kinds of execptions thrown, so that Optional_<Some_builtin_type>
// doesn't incur unacceptable overhead:
# if 0 // SPEC:
template< class Type >
class Optional_
{
private:
std::vector<Type> item_;
public:
auto has_object() const -> bool { return item_.size() > 0; }
auto object() -> Ref_<Type> { return item_.at( 0 ); }
auto object() const -> Ref_<const Type> { return item_.at(
0 ); }
auto operator=( Ref_<Optional_> other ) -> Ref_<Optional_>
{ item_ = other.item_; }
auto operator=( Rvref_<Optional_> other ) ->
Ref_<Optional_> { item_ = move( other.item_ ); }
Optional_( None = None() ) {}
Optional_( Type o ) { item_.push_back( move( o ) ); }
Optional_( Ref_<const Optional_> other ): item_(
other.item_ ) {}
Optional_( Rvref_<Optional_> other ): item_( move(
other.item_ ) ) {}
};
# endif
 
template< class Type >
class Optional_
{
private:
using Alignment_info = std::aligned_union<0, Type>;
using Storage = typename Alignment_info::type;
static constexpr int alignment = Alignment_info::alignment_value;
 
Storage storage_;
Ptr_<Type> p_object_ = nullptr;
 
auto aligned_storage()
-> Ptr_<void>
{
Ptr_<void> p_storage = &storage_;
size_t size = sizeof( storage_ );
 
return std::align( alignment, sizeof( Type ), p_storage,
size );
}
 
public:
auto has_object() const
-> bool
{ return !!p_object_; }
 
auto object()
-> Ref_<Type>
{
hopefully( has_object() )
|| fail( "Optional_: no object" );
return *p_object_;
}
 
auto object() const
-> Ref_<const Type>
{
hopefully( has_object() )
|| fail( "Optional_: no object" );
return *p_object_;
}
 
auto operator=( Ref_<const Optional_> other )
-> Ref_<Optional_>
{
if( other.has_object() )
{
if( has_object() )
{
*p_object_ = *other.p_object_;
}
else
{
p_object_ = ::new( aligned_storage() ) Type(
*other.p_object_ );
}
}
else
{
if( has_object() )
{
p_object_->Type::~Type();
p_object_ = nullptr;
}
}
return *this;
}
 
auto operator=( Rvref_<Optional_> other )
-> Ref_<Optional_>
{
if( other.has_object() )
{
if( has_object() )
{
*p_object_ = move( *other.p_object_ );
}
else
{
p_object_ = ::new( aligned_storage() ) Type( move(
*other.p_object_ ) );
}
}
else
{
if( has_object() )
{
p_object_->Type::~Type();
p_object_ = nullptr;
}
}
return *this;
}
 
~Optional_()
{
if( has_object() )
{
p_object_->Type::~Type();
}
}
 
Optional_( None = None() ) {}
 
Optional_( Type o )
: p_object_( ::new( aligned_storage() ) Type( move( o ) ) )
{}
 
Optional_( Ref_<const Optional_> other )
{
if( other.has_object() )
{
p_object_ = ::new( aligned_storage() ) Type(
*other.p_object_ );
}
}
 
Optional_( Rvref_<Optional_> other )
{
if( other.has_object() )
{
p_object_ = ::new( aligned_storage() ) Type( move(
*other.object_ptr() ) );
}
}
};
} // namespace cppx
</file>
 
 
Cheers!,
 
- Alf
"Öö Tiib" <ootiib@hot.ee>: May 15 11:49PM -0700

On Monday, 16 May 2016 07:40:19 UTC+3, Alf P. Steinbach wrote:
> I just coded up this and I wonder if there's much wrong with this code,
> and/or improvements to the design, and/or kind words about my hairdo?
 
Seems fine on first glance. Why you decided to write another 'optional'
(AKA 'fallible' and 'nullable')? Would be more worth of it if you tried
to achieve constexprness of it. Maybe go full way and use a bool instead
of pointer. It will result with tiniest optional being 2 bytes instead of
16 on lot of platforms.
 
> I don't have any test cases for this, at all.
 
> And that's another thing I wonder about: how would one go about testing
> code like this? I'm not even sure of requirements on template param.
 
Easiest might be to install boost and get some unit tests for rather
similar thing (IIRC in $(boost_root)/libs/optional/test).
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)