Friday, March 24, 2017

Digest for comp.lang.c++@googlegroups.com - 25 updates in 11 topics

aminer68@gmail.com: Mar 24 01:14PM -0700

Hello,
 
More psychology about this C++ forum
 
When you are managing more larger projects like you are doing Bonita
and Stuckle and Fibble etc. of this C++ forum, you get angry and frustrated
because your life is getting bad, so you are also like escaping
your living conditions by coming to this forum, this is understandable,
so this is why you are less tolerant with my posts and less tolerant with my code, because look at Bonita she is dimishing my projects and telling that my projects are just toys because they are not large projects,
you have to understand this hate by understanding the living conditions
of those individuals on this forum, this is why i am explaining it to you.
 
 
Thank you,
Amine Moulay Ramdane.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 24 01:23PM -0700

> of those individuals on this forum, this is why i am explaining it to you.
 
> Thank you,
> Amine Moulay Ramdane.
 
That's not the reason, Amine. It is because you post in a style
that takes up vertical inches of screen space, and you basically
say nothing other than to release your new product, or a new
version of a prior release, and add your philosophy.
 
You don't come here and answer other people's posts. You don't
participate. You just broadcast ... and you do so in a way that
is offensive and rude within the general definitions of Usenet
etiquette.
 
That's why people get frustrated with you. And that is the only
reason.
 
Thank you,
Rick C. Hodgin
ram@zedat.fu-berlin.de (Stefan Ram): Mar 24 08:13PM

I read a question in a newsgroup today about adjusting columns.
So I wanted to implement this in C++ as a small exercise.
 
I wanted to get from
 
::std::string source = R"(
Alpha Beta Gamma Delta Epsilon
Zeta Eta Theta Iota Kappa
Lambda My Ny Xi Omikron
Pi Rho Sigma Tau Ypsilon
Phi Chi Psi Omega
)";
 
to
 
Alpha Beta Gamma Delta Epsilon
Zeta Eta Theta Iota Kappa
Lambda My Ny Xi Omikron
Pi Rho Sigma Tau Ypsilon
Phi Chi Psi Omega
 
. I finally managed to do it, but it was /very/ tiresome.
I did everything myself. I worked on a very low level of
abstraction. There was not a "shortcut" I could find to
let C++ do more of the work. Maybe someone can see such
a shortcut?

I also read a book recently about programming style. It
suggested to write small functions with readable names
and to prefer functions with no parameters. Therefore,
the style of my solution was partially influenced by
this book. (I did not spend time to optimize the code
for run-time efficiency.)
 
#include <iostream>
#include <ostream>
#include <vector>
#include <string>
 
struct program
{
::std::string source = R"(
Alpha Beta Gamma Delta Epsilon
Zeta Eta Theta Iota Kappa
Lambda My Ny Xi Omikron
Pi Rho Sigma Tau Ypsilon
Phi Chi Psi Omega
)";
 
/* a position within the source or
one past the end of the source */
size_t pos { 0 };
 
char current_char()
{ return source.at( pos ); }
 
bool in_text()
{ return pos < source.length(); }
 
bool is_trimmable( char const c )
{ return c == ' '; }
 
bool is_trimmable_or_eol( char const c )
{ return is_trimmable( c )|| c == '\r' || c == '\n'; }
 
void erase_front()
{ size_t const pos { 0 };
size_t const len { 1 };
source.erase( pos, len ); }
 
void erase_back()
{ size_t const pos { source.length() - 1 };
size_t const len { 1 };
source.erase( pos, len ); }
 
void erase_char_at_pos()
{ size_t const len { 1 };
source.erase( pos, len ); }
 
void trim_start_of_source()
{ while( is_trimmable_or_eol( source.front() ))erase_front(); }
 
void trim_end_of_source()
{ while( is_trimmable_or_eol( source.back() ))erase_back(); }
 
void normalize_line_separators()
{ pos = 0; while( pos < source.length() )
{ if( source.at( pos ) == '\r' )erase_char_at_pos();
else ++pos; }
source += '\n'; }
 
void goto_start_of_source()
{ pos = 0; }
 
void trim_at_pos()
{ while( is_trimmable( source.at( pos ) ))erase_char_at_pos(); }
 
void move_pos_to_end_of_line()
{ while( true )
{ if( pos >= source.length() )return;
if( source.at( pos ) == '\n' )return;
if( pos < source.length() )++pos; }}
 
bool previous_char_is_trimmable()
{ return pos > 0 && is_trimmable( source.at( pos - 1 )); }
 
void remove_previous_char()
{ --pos;
size_t len { 1 };
source.erase( pos, len ); }
 
void trim_at_end_of_line()
{ while( previous_char_is_trimmable() )remove_previous_char(); }
 
void move_pos_to_next_line()
{ while( pos < source.length())
if( source.at( pos++ )== '\n' )return; }
 
bool pos_is_in_a_line()
{ return pos < source.length(); }
 
void debug_print()
{ for( size_t i = 0; i < source.length(); ++i )
{ if( i == pos )::std::cout << '[' << source.at( i )<< ']';
else ::std::cout << source.at( i ); }}
 
void trim_each_line()
{ goto_start_of_source();
while( pos_is_in_a_line() )
{ trim_at_pos();
move_pos_to_end_of_line();
trim_at_end_of_line();
move_pos_to_next_line(); }}
 
void trim_source()
{ trim_start_of_source();
trim_end_of_source();
normalize_line_separators();
trim_each_line(); }
 
::std::vector<size_t> width{};
 
bool in_line_body()
{ return in_text() && current_char() != '\n'; }
 
void move_to_end_of_word( size_t & p )
{ while( source.at( p )!= ' ' && source.at( p )!= '\n' )++p; }
 
void move_to_end_of_spaces( size_t & p )
{ while( source.at( p )== ' ' && source.at( p )!= '\n' )++p; }
 
size_t cell_width()
{ size_t p = pos;
move_to_end_of_word( p );
return p - pos; }
 
void goto_next_column()
{ move_to_end_of_word( pos );
move_to_end_of_spaces( pos ); }
 
bool width_recorded( size_t const col )
{ return col < width.size(); }
 
void record_width( size_t const col, size_t const w )
{ while( !width_recorded( col ))width.push_back( 0 );
width.at( col ) = w; }
 
void record_widths_of_columns_for_current_line()
{ size_t col = 0;
while( in_line_body() )
{ size_t const w = cell_width();
if( !width_recorded( col ) || w > width.at( col ))
record_width( col, w );
goto_next_column();
++col; }
if( pos < source.length() )++pos; }
 
void record_widths_of_columns()
{ goto_start_of_source();
while( pos_is_in_a_line() )
{ record_widths_of_columns_for_current_line(); }}
 
void trim_spaces_here()
{ size_t const next = pos + 1;
while
( pos < source.length() && source.at( pos )== ' ' &&
next < source.length() && source.at( next )== ' ' )
erase_char_at_pos(); }
 
void insert_spaces_here( size_t const n )
{ for( size_t i = 0; i < n; ++i )
source.insert( pos, 1, ' ' ); }
 
void adjust( size_t const current, size_t const target )
{ trim_spaces_here();
insert_spaces_here( target - current ); }
 
void align_columns_for_current_line()
{ size_t col = 0;
while( in_line_body() )
{ size_t const w = cell_width();
move_to_end_of_word( pos );
if( w < width.at( col ))adjust( w, width.at( col ) );
move_to_end_of_spaces( pos );
++col; }
if( pos < source.length() )++pos; }
 
void align_columns()
{ goto_start_of_source();
while( pos_is_in_a_line() )
{ align_columns_for_current_line(); }}
 
void align_source()
{ record_widths_of_columns();
align_columns(); }
 
void run()
{ trim_source();
align_source();
::std::cout << source << '\n'; ::std::cout.flush(); }};
 
int main() { ::program{}.run(); }
 
transcript
 
Alpha Beta Gamma Delta Epsilon
Zeta Eta Theta Iota Kappa
Lambda My Ny Xi Omikron
Pi Rho Sigma Tau Ypsilon
Phi Chi Psi Omega
aminer68@gmail.com: Mar 24 12:56PM -0700

Hello,
 
Don't get mad and frustrated...
 
I am just posting very very few posts about my new updates of my C++ libraries, that's all, so be sure that i don't want to participate to
discussions in this C++ forum.
 
 
Thank you,
Amine Mouly Ramdane.
"Chris M. Thomasson" <invalid@invalid.invalid>: Mar 24 01:08PM -0700


> Don't get mad and frustrated...
 
> I am just posting very very few posts about my new updates of my C++ libraries, that's all, so be sure that i don't want to participate to
> discussions in this C++ forum.
 
Imvvho, you should really go ahead and consider creating a special
thread dedicated to your updates. All updates go into this thread with
proxy headings...
 
Update [subid:seqnum:userid] ...
__________________________
I have found something interesting about [subid:[seqnum]]...
__________________________
 
All of these would go under the same thread with a unique sequence
number, or some other form of database logic to create and track proxy
subjects contained within this single thread of updates to your source
code...
 
Mimic a tree within a tree. Just a thought.
 
Try to think about minimizing creation of new threads, and think more
about adding on to existing threads. Or funnel updates through a
dedicated thread.
Ramine <toto1@toto1.net>: Mar 24 10:30AM -0400

Hello....
 
 
My Scalable Parallel C++ Conjugate Gradient Linear System Solver Library
was updated to version 1.62
 
Author: Amine Moulay Ramdane
 
Description:
 
This library contains a Scalable Parallel implementation of
Conjugate Gradient Dense Linear System Solver library that is
NUMA-aware and cache-aware, and it contains also a Scalable
Parallel implementation of Conjugate Gradient Sparse Linear
System Solver library that is cache-aware.
 
Please download the zip file and read the readme file inside the
zip to know how to use it.
 
Language: GNU C++ and Visual C++ and C++Builder
 
Operating Systems: Windows, Linux, Unix and Mac OS X on (x86)
 
 
You can download it from:
 
https://sites.google.com/site/aminer68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library
 
 
Thank you,
Amine Moulay Ramdane.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 24 03:14PM

On 24/03/2017 14:30, Ramine wrote:
> Hello....
[snip]
 
I thought you weren't going to post in this newsgroup again?
 
/Flibble
Jerry Stuckle <jstucklex@attglobal.net>: Mar 24 12:58PM -0400

On 3/24/2017 11:14 AM, Mr Flibble wrote:
> [snip]
 
> I thought you weren't going to post in this newsgroup again?
 
> /Flibble
 
He's just a liar as well as an idiot. How many times has he said he
wouldn't post here any more? I've lost count.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 24 11:11AM -0700

On Friday, March 24, 2017 at 12:58:58 PM UTC-4, Jerry Stuckle wrote:
> He's just a liar as well as an idiot. How many times has he said he
> wouldn't post here any more? I've lost count.
 
You should be careful on how you regard other people, Jerry. Not
everybody is where they should be, or doing what they should be
doing. It's our place in this world to guide them and lift them
up, not knock them down.
 
Thank you,
Rick C. Hodgin
Jerry Stuckle <jstucklex@attglobal.net>: Mar 24 03:15PM -0400

On 3/24/2017 2:11 PM, Rick C. Hodgin wrote:
> up, not knock them down.
 
> Thank you,
> Rick C. Hodgin
 
Rick, I wasn't talking to you. And I don't need your "holier than thou"
attitude. So just take it and stick it where the sun doesn't shine.
That way it can be right next to your head.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 24 12:55PM -0700

On Friday, March 24, 2017 at 3:15:53 PM UTC-4, Jerry Stuckle wrote:
 
> Rick, I wasn't talking to you. And I don't need your "holier than thou"
> attitude. So just take it and stick it where the sun doesn't shine.
> That way it can be right next to your head.
 
It's not "holier than thou," Jerry. It's standard operating procedure
for born again Christians. It's what we're called to (Hebrews 12:14).
 
The spirit you're following with your hateful demeaning replies is the
anti-Christ spirit, and it will lead you to only one place: your
eternal destruction in Hell. I would advise you stop listening to it,
and listen to God's Holy Spirit instead (John 4:24).
 
Thank you,
Rick C. Hodgin
aminer68@gmail.com: Mar 24 12:47PM -0700

Hello,
 
I understand more about this C++ forum, Bonita and Stuckle
and Fibble etc. are managing large software projects, and managing
large software projects get you angry and frustrated, and your
frustrations are showing when you respond to my posts, this
is understandable.
 
But read this:
 
About my C++ libraries..
 
I think that Bonita and Stuckle are not getting it right, i have invented
algorithms like my C++ synchronization objects library and also i have written my C++ scalable conjugate gradient linear system solver libraries, it is not about beautifulness of the code, and it is not about the size of
the code. Bonita is not getting it right, she is still speaking of the size
of the code and telling me that my projects are not large projects, she
is thinking stupidly.
 
 
Thank you,
Amine MoulAy RAMDANE.
aminer68@gmail.com: Mar 24 12:35PM -0700

Hello,
 
About my C++ libraries..
 
I think that Bonita and Stuckle are not getting it right, i have invented
algorithms like my C++ synchronization objects library and also i have written my C++ scalable conjugate gradient linear system solver libraries, it is not about beautifulness of the code, and it is not about the size of
the code. Bonita is not getting it right, she is still speaking of the size
of the code and telling me that my projects are not large projects, she
is thinking stupidly.
 
 
Thank you,
Amine MoulAy RAMDANE.
aminer68@gmail.com: Mar 24 12:10PM -0700

Hello,
 
Please download again my C++ synchronization objects library for Windows and Linux that was updated, i have forgot to update some of the readme files,
so i have just done it.
 
You can download it from:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
Thank you,
Amine Moulay Ramdane.
aminer68@gmail.com: Mar 24 12:15PM -0700

> Hello,
 
> Please download again my C++ synchronization objects library for Windows and Linux that was updated, i have forgot to update some of the readme
 
 
I correct: we write "i have forgotten" in english.
 
files,
Daniel <danielaparker@gmail.com>: Mar 23 07:53PM -0700

On Thursday, March 23, 2017 at 3:09:07 PM UTC-4, Christopher Pisz wrote:
> The following comparison fails for an error whom outputs "asio.misc" for errorCode.category().name() and "end of file" for errorCode.message()
 
> If it claims to be in category asio.misc, then why does the if condition of (errorCode.category() == boost::asio::error::misc_category ) evaluate to false?
 
Apart from the category issues, if you're getting "end of file" for
errorCode.message(), I don't think you'll get any more information by
examining the error code. The misc_errors enum value corresponding to that
message is misc_errors::eof.
 
What version of boost are you using? At one time (v 1.4) there actually was a
boost::system::misc_category, now (v 6.2) there's this for backwards
compatibility:
 
static const boost::system::error_category& misc_category
= boost::asio::error::get_misc_category();
 
I believe all the error codes are now covered by
boost::system::error_category.
 
If you're using a recent version of boost, I would not have expected you
would see an error category of "asio.misc". For recent versions, I would
expect (errorCode.category() == boost::asio::error::get_system_category())
 
Daniel
Daniel <danielaparker@gmail.com>: Mar 23 08:47PM -0700

On Thursday, March 23, 2017 at 10:53:59 PM UTC-4, Daniel wrote:
 
> I believe all the error codes are now covered by
> boost::system::error_category.
 
All the error codes required by boost asio, that is.
 
Daniel
Christopher Pisz <christopherpisz@gmail.com>: Mar 24 07:43AM -0700

On Thursday, March 23, 2017 at 9:53:59 PM UTC-5, Daniel wrote:
> would see an error category of "asio.misc". For recent versions, I would
> expect (errorCode.category() == boost::asio::error::get_system_category())
 
> Daniel
 
 
I am using 1.62.0
 
According to what I am reading, anyone is free to create their own error codes and categories. Different boost libraries may use different categories. Just debugging through various network scenarios and see that the error_code::category is sometimes boost::asio::error::misc_category and sometimes boost::system::system_category.
 
I finally got onto another computer that wasn't blocking sites and at least one fella on the boost mailing list claims you should indeed compare category, but the comparison fails when boost is statically linked because one address is from one lib and the other is from the executable. That seems like one silly comparison operator...
Daniel <danielaparker@gmail.com>: Mar 24 08:11AM -0700

On Friday, March 24, 2017 at 10:43:26 AM UTC-4, Christopher Pisz wrote:
 
> Different boost libraries may use different categories. Just debugging
> through various network scenarios and see that the error_code::category is > sometimes boost::asio::error::misc_category and sometimes
> boost::system::system_category.
 
Right, but I'm pretty sure that boost::asio::error::misc_category is
there for backwards compatibility only. Compare error.hpp in 1.62 and 1.43.
There used to be a misc_category that extended boost::system::error_category,
but now there is only boost::system::error_category.
 
> one fella on the boost mailing list claims you should indeed compare
> category, but the comparison fails when boost is statically linked because
> one address is from one lib and the other is from the executable.
 
You should be comparing with boost::asio::error::get_misc_category()
rather than the data member boost::asio::error::misc_category, does it
change anything if you do?
 
Also, note that if errorCode.message() returned a message, it was able to
resolve the category.
 
Daniel
Daniel <danielaparker@gmail.com>: Mar 24 09:45AM -0700

On Friday, March 24, 2017 at 11:11:26 AM UTC-4, Daniel wrote:
 
> You should be comparing with boost::asio::error::get_misc_category()
> rather than boost::asio::error::misc_category, does it
> change anything if you do?
 
Just to note, in 1.62, get_misc_category() is implemented in the boost
library, not the header files, so I would expect it to return a consistent
address.
 
Daniel
Ramine <toto1@toto1.net>: Mar 24 10:23AM -0400

Hello...
 
 
My C++ synchronization objects library was updated..
 
Now it is more stable and fast.
 
You can download it from:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
Thank you,
Amine Moulay Ramdane.
aminer68@gmail.com: Mar 24 09:39AM -0700

On Friday, March 24, 2017 at 10:24:03 AM UTC-4, Ramine wrote:
 
> https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
> Thank you,
> Amine Moulay Ramdane.
 
 
 
Hello...
 
I was aware that memory ordering is not the only issue and that you have to use fences and memory barriers, but my implementation of my algorithms like my MLock and AMLock etc. was already using the correct fences and memory barriers to ensure sequential consistency in the hardware side, but what i have added is that i have switch the optimization off locally in some units to avoid memory reordering of the Delphi and FreePascal compilers, and now my C++ synchronization objects library is more stable and fast.
 
 
 
Thank you,
Amine Moulay Ramdne.
aminer68@gmail.com: Mar 24 09:39AM -0700

On Friday, March 24, 2017 at 10:24:03 AM UTC-4, Ramine wrote:
 
> https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
> Thank you,
> Amine Moulay Ramdane.
 
Hello...
 
I was aware that memory ordering is not the only issue and that you have to use fences and memory barriers, but my implementation of my algorithms like my MLock and AMLock etc. was already using the correct fences and memory barriers to ensure sequential consistency in the hardware side, but what i have added is that i have switch the optimization off locally in some units to avoid memory reordering of the Delphi and FreePascal compilers, and now my C++ synchronization objects library is more stable and fast.
 
 
 
Thank you,
Amine Moulay Ramdne.
gof@somewhere.invalid (Adam Wysocki): Mar 24 09:02AM


> The noise level in clc++ is increasing again.
 
> I use Thunderbird to access the newsgroup. It's not exactly clear to a
> new user how to do that. So, in Windows
 
For completion, here is my filter file for tin.
 
#v+
comment=comp.lang.c attack
group=comp.lang.c
case=0
score=kill
from=*stevecarrollsdog@gmail.com*
 
comment=comp.lang.c attack
group=comp.lang.c
case=0
score=kill
from=*frelwizzen@gmail.com*
 
comment=comp.lang.c attack
group=comp.lang.c
case=0
score=kill
from=*tmelmosfire@gmail.com*
 
comment=comp.lang.c attack
group=comp.lang.c
case=0
score=kill
from=*jonaseklundhsandman@gmail.com*
 
comment=comp.lang.c++ attack
group=comp.lang.c++
case=0
score=kill
from=*toto@toto.net*
 
comment=comp.lang.c++ attack
group=comp.lang.c++
case=0
score=kill
from=*aminer68@gmail.com*
 
comment=comp.lang.c++ attack
group=comp.lang.c++
case=0
score=kill
from=*rick.c.hodgin@gmail.com*
#v-
 
--
http://www.chmurka.net/
fir <profesor.fir@gmail.com>: Mar 24 01:18AM -0700

W dniu czwartek, 23 marca 2017 09:22:21 UTC+1 użytkownik Christian Gollwitzer napisał:
> touched, i.e. copied, used etc. If there are parameters on the stack,
> you will see access to [rsp+xx] or the frame-pointer thingy mov %rsp,
> %rbp and access to [rbp+xx].
 
i dont want tio write automatic analiser i want to
do it more by human eye..
 
if dlls convention is __cdecl and probably this is something callee-cleanning you will see the stack unvind
thus sizes (what exactly is this convention in dll? you are probably wrong speaking on fastcall and 32 bit but
im not sure, maybe system api like kernal32.dll uses this?)
 
ps assume 32 bit and assume c interface
 
harder could be tough reckognize type of the args,
though maybe also possible, at least the basic three
would be nice to reckognize (int, something*, float)
 
now im to tired to try disassebly and look but i wonder
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)