Sunday, December 11, 2016

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

ruben safir <ruben@mrbrklyn.com>: Dec 10 08:16PM -0500

What is the difference between these two statements
 
unsigned char * &index(unsigned char * value){
index_ = value;
return index_;
};
 
and without the reference:
 
unsigned char * index(unsigned char * value){
index_ = value;
return index_;
};
Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Dec 10 06:37PM -0700

On Sat, 10 Dec 2016 20:16:52 -0500, ruben safir <ruben@mrbrklyn.com>
wrote:
 
> index_ = value;
> return index_;
> };
 
They're not statements, they're function declarations, and it's hard
to say what the difference is since as far as I can tell neither one
compiles.
 
Do you have examples that do compile?
 
Louis
Barry Schwarz <schwarzb@dqel.com>: Dec 10 06:29PM -0800

On Sat, 10 Dec 2016 20:16:52 -0500, ruben safir <ruben@mrbrklyn.com>
wrote:
 
> index_ = value;
> return index_;
> };
 
After you fix the errors so that the functions can compile cleanly:
 
The first invokes undefined behavior (or is it a constraint
violation) because it returns a reference to an object that will
disappear as soon as the function ends.
 
The second returns the value of that object and that will survive
the destruction of index_ with no problem.
 
--
Remove del for email
Popping mad <rainbow@colition.gov>: Dec 11 03:53AM

On Sat, 10 Dec 2016 18:29:06 -0800, Barry Schwarz wrote:
 
> disappear as soon as the function ends.
 
> The second returns the value of that object and that will survive
> the destruction of index_ with no problem.
 
right. index_ is actually a data member of the object which this
function is a member of.
 
it points to a member of allocated memory which contains an image.
 
the second returns the address to a char within that memory which index_
points to.
 
The second one returns an lvalue reference of a pointer to char.
 
What practical difference is there in this case?
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 11 05:39AM +0100

On 11.12.2016 04:53, Popping mad wrote:
> points to.
 
> The second one returns an lvalue reference of a pointer to char.
 
> What practical difference is there in this case?
 
The "right" sounds like you're grading the answer on correctness, while
the "What practical difference?" sounds like you now want the answer to
yet another part of a homework assignment.
 
These signals are contradictory and both are baffling: you're not (yet)
competent to grade answers given here other than for clarity, and we do
not usually do people's homework in a way that could be successfully
submitted to the OP's teacher or professor. If someone answers a
homework question for real, then it's by accident. This is ¹a FAQ.
 
Not in the FAQ: it's been a long tradition in this group to sometimes
answer a homework question with technically correct but extremely
impractical and usually advanced code. These answers would reveal the
dishonest student as such to his or her professor or teacher. Just don't
ask for homework answers, please.
 
 
Cheers & hth.,
 
- Alf
 
PS: You probably wanted to write "second" and "first" rather than
"second" and "second".
 
Links:
¹ <url: https://isocpp.org/wiki/faq/how-to-learn-cpp#help-with-homework>
ruben safir <ruben@mrbrklyn.com>: Dec 11 04:10AM -0500

On 12/10/2016 11:39 PM, Alf P. Steinbach wrote:
> The "right" sounds like you're grading the answer on correctness, while
> the "What practical difference?" sounds like you now want the answer to
> yet another part of a homework assignment.
 
I don't post HW assignments Alf....
Boink again
ruben safir <ruben@mrbrklyn.com>: Dec 11 04:13AM -0500

On 12/10/2016 11:39 PM, Alf P. Steinbach wrote:
> Not in the FAQ: it's been a long tradition in this group
 
really... Not that you represent the group, but is there any rules of
restricting replies to the topic?
 
Evidently not, which is why your posts are not of much value....ever.
 
I doubt you know the answer anyway. It would require deeper
understanding of the languages use and behaviors then you demonstrate
any knowledge in.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 11 10:55AM +0100

On 11.12.2016 10:13, ruben safir wrote:
>> Not in the FAQ: it's been a long tradition in this group
 
> really... Not that you represent the group, but is there any rules of
> restricting replies to the topic?
 
For clc++ there are only generally agreed on rules of conduct, e.g. as
in the FAQ, because this group lacks a charter.
 
The FAQ's requirement on questions was, and perhaps still is after the
migration to ISO CPP, that any question should be answerable with
reference only to the C++ standard. That was probably in order to limit
the number of questions concerning the Windows API, which once was a
major reason for the creation of the moderated sister group clc++m
(which does have a charter, but is now defunct).
 
 
 
> I doubt you know the answer anyway. It would require deeper
> understanding of the languages use and behaviors then you demonstrate
> any knowledge in.
 
Personal attacs (which you're doing here), multiple nicks (as you're
using in this group), inane assertions and apparent evaluations of the
correctness of other's answers to your questions, as if you asked while
knowing an answer, shows the regulars that you're trolling.
 
That wastes your time, as well as ours.
 
Unless you're into negative sum games I suggest you change your ways,
e.g. ask some real questions, with copy and pasted code examples.
 
 
Cheers & hth.,
 
- Alf
ruben safir <ruben@mrbrklyn.com>: Dec 11 05:26AM -0500


> Unless you're into negative sum games I suggest you change your ways,
> e.g. ask some real questions, with copy and pasted code examples.
 
You have permission to not read my posts or to write back. Its too bad
thunderbird doesn't have a dev null. You are already /dev/nulled in the
other client.
 
Everything you post is a troll or a waste of time.
 
 
 
 
Ralf Goertz <me@myprovider.invalid>: Dec 11 11:13AM +0100

Am Sat, 10 Dec 2016 09:13:26 -0800 (PST)
 
> It is called implicit conversion constructor from int to X.
> Experienced C++ programmers tend to avoid implicit conversions
> like the plague.
 
It might look like an implicit conversion constructor but actually it is
meant to be a regular contructor. In the context of my original question
it is clear why I need this constructor. How else am I supposed to
initialise a constant reference cr in my class?
ruben safir <ruben@mrbrklyn.com>: Dec 10 08:06PM -0500

On 12/10/2016 01:48 PM, Öö Tiib wrote:
> unsigned char* t = t_; // can't do that either
 
 
right, hence the error message
ruben safir <ruben@mrbrklyn.com>: Dec 10 08:06PM -0500

On 12/10/2016 05:39 PM, Jerry Stuckle wrote:
> No, Paavo is correct. It breaks encapsulation and smells of a bad design
 
not really, but I'm sick of discussing that since 1998 when Java came
out with the mantra of OO design.
ruben safir <ruben@mrbrklyn.com>: Dec 10 08:15PM -0500

On 12/10/2016 05:39 PM, Jerry Stuckle wrote:
> The purpose of encapsulation is to ensure the integrity of the object.
 
The purpose is to make a coherent API. You do not always want to
prevent access to private data and to only pass data by value,
especially if it s a lot of data in big memory heaps.
 
Then I might want to assign big data to a reference to an internal
pointer to a new heap object.
ruben safir <ruben@mrbrklyn.com>: Dec 10 08:21PM -0500

On 12/10/2016 05:39 PM, Jerry Stuckle wrote:
> and smells of a bad design.
 
 
I think that what bothers me here is this. Designs don't smell and that
Axiomatic jargon that a cadre of young coders learned when Sun pushed
Java on them in the late 1990's was wrong.
 
The first purpose of OO coding is to create easy to debug, maintainable
and documentable code. It is about the human coders. the computer
software could care less. It is about project management and development.
ruben safir <ruben@mrbrklyn.com>: Dec 10 08:22PM -0500

On 12/10/2016 05:39 PM, Jerry Stuckle wrote:
> No, Paavo is correct.
 
he is not even on the topic.
Paavo Helde <myfirstname@osa.pri.ee>: Dec 11 10:16AM +0200

On 11.12.2016 3:15, ruben safir wrote:
>> The purpose of encapsulation is to ensure the integrity of the object.
 
> The purpose is to make a coherent API. You do not always want to
> prevent access to private data
 
Agreed. It seems you have overlooked the words "in general" in my
previous post. There are exceptions to any rules.
ruben safir <ruben@mrbrklyn.com>: Dec 11 04:09AM -0500

On 12/11/2016 03:16 AM, Paavo Helde wrote:
> Agreed. It seems you have overlooked the words "in general" in my
> previous post.
 
 
wow - you don't read that often on usenet ;)
kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Dec 10 09:21PM -0800

thanx i was testing the behaviour of threads and accordingly did trial and error and i fixed some of the bugs of the program.THe only thing i am facing is the time to input in the console is less available.I have put a sleep in the console thread but still its somewhat fast (the speed decreased to some extent).What should i implement now in order to have a sober pace between other threads spawned within the console(while loop where console input thread is created) and the console thread
Paavo Helde <myfirstname@osa.pri.ee>: Dec 11 10:34AM +0200

On 11.12.2016 7:21, kushal bhattacharya wrote:
> thanx i was testing the behaviour of threads and accordingly did trial and error and i fixed some of the bugs of the program.THe only thing i am facing is the time to input in the console is less available.I have put a sleep in the console thread but still its somewhat fast (the speed decreased to some extent).What should i implement now in order to have a sober pace between other threads spawned within the console(while loop where console input thread is created) and the console thread
 
In a proper multithreaded program there is no place for a simple sleep
as you cannot wake another thread easily from sleep easily when needed,
and also because it is a very inefficient method for thread
synchronization, as you have discovered.
 
Instead, you should use std::mutex, std::unique_lock and
std::condition_variable classes. All calls to sleep() should be replaced
by calls of std::condition_variable::wait() or its cousins.
 
hth
Paavo
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 11 08:13AM +0100

This tutorial, if it works (it's an experiment), is intended to work
this way:
 
* I post some working code.
* Learner(s) study it and ask about things.
* Others answer questions and post critique or get bogged down in long
sub-threads about sausages and swearing.
 
The following code augments the basic sorted binary tree code in part 1
with a difference of subtree heights in each node, which will be needed
for balancing, and debug/exploration output of the tree structure, ditto
-- since we're getting closer to some awesome complexity.
 
When tree balancing is added (in part 3?) the subtree height differences
will naturally reduce to the range -1 ... +1, since as soon as a
difference of magnitude 2 occurs it will be balanced away. And then
there can possibly be some good optimizations due to that. I have yet to
read up on balancing in e.g. Wikipedia, so I only have vague
recollections of "red black" trees etc., but hopefully there's nothing
more to it than optimizing the representation, updating and use of the
differences for a guaranteed tiny three-value range.
 
[code]
#include <stack> // std::stack
#include <stdlib.h> // abs(int)
#include <string> // std::(string, to_string)
#include <utility> // std::move
 
namespace cppx {
using std::stack;
using std::string;
using std::to_string;
 
struct No_copy_or_move
{
auto operator=( No_copy_or_move const& ) -> No_copy_or_move& =
delete;
auto operator=( No_copy_or_move&& ) -> No_copy_or_move& = delete;
 
No_copy_or_move() = default;
No_copy_or_move( No_copy_or_move const& ) = delete;
No_copy_or_move( No_copy_or_move&& ) = delete;
};
 
template< class Item >
inline auto popped_top_of( stack<Item>& st )
-> Item
{
Item result = move( st.top() );
st.pop();
return result;
}
 
inline auto repeated( int const n, string const& s )
-> string
{
string result;
for( int i = 1; i <= n; ++i ) { result += s; }
return result;
}
 
inline auto string_from( string const& s )
-> string const&
{ return s; }
 
inline auto string_from( char const* const s )
-> string
{ return s; }
 
template< class Type >
inline auto string_from( Type const& o )
-> string
{ return to_string( o ); }
 
template< class Type >
inline auto operator<<( string& s, Type const& o )
-> string&
{ return s.append( string_from( o ) ); }
} // namespace cppx
 
namespace my {
using cppx::popped_top_of;
using cppx::repeated;
using cppx::operator<<;
using std::stack;
using std::string;
using std::move;
 
using Value = double;
 
class Tree
: public cppx::No_copy_or_move
{
private:
struct Node
{
Node* left;
Node* right;
Value value;
int height_diff; // right subtree height - left
subtree height
};
 
Node* root_ = nullptr;
 
template< class Func >
static void apply_in_infix_order( Node* root, Func const& f )
{
if( root != nullptr )
{
apply_in_infix_order( root->left, f );
f( root );
apply_in_infix_order( root->right, f );
}
}
 
// Called after a new node, the `p_new_child`, has been inserted:
void update_height_differences(
Node* const p_new_child,
stack<Node*> parent_nodes
)
{
Node* p_child = p_new_child;
while( not parent_nodes.empty() )
{
Node* const p_parent = popped_top_of(
parent_nodes );
int& height_diff = p_parent->height_diff;
int const old_height_diff = height_diff;
 
height_diff += (p_parent->right == p_child? +1 : -1);
 
bool const this_height_increased =
(abs( height_diff ) > abs( old_height_diff ));
if( not this_height_increased )
{
break;
}
p_child = p_parent;
}
}
 
// Structure inspection for debugging & exploration:
static void add_internal_structure_to(
string& s,
Node* const root,
int const level
)
{
string const indentation = repeated( level, "| " );
if( root == nullptr )
{
s << indentation << "()\n";
}
else
{
add_internal_structure_to( s, root->left, level + 1 );
s << indentation
<< root->value << " [height diff " <<
root->height_diff << "]"
<< "\n";
add_internal_structure_to( s, root->right, level + 1 );
}
}
 
public:
void add( Value const& value )
{
stack<Node*> parent_nodes;
Node** p_ptr = &root_;
while( *p_ptr != nullptr )
{
Node*& ref_ptr = *p_ptr;
parent_nodes.push( ref_ptr );
p_ptr = &(value < ref_ptr->value? ref_ptr->left :
ref_ptr->right);
}
*p_ptr = new Node{ nullptr, nullptr, value, 0 };
update_height_differences( *p_ptr, move( parent_nodes ) );
}
 
template< class Func >
void for_each( Func const& f )
{
apply_in_infix_order( root_, [&f]( Node* p ){ f( p->value
); } );
}
 
auto internal_structure() const
-> string
{
string result;
add_internal_structure_to( result, root_, 0 );
return result;
}
 
Tree() = default;
};
} // my
 
#include <iostream>
using namespace std;
auto main()
-> int
{
my::Tree t;
for( int const v : {3, 1, 4, 1, 5, 9, 2, 6, 5, 4} )
{
t.add( v );
}
 
t.for_each(
[]( double x ) { cout << x << ' '; }
);
cout << endl;
 
cout << endl;
cout << t.internal_structure() << endl;
}
[/code]
 
---------------------------------------------------------------------------
[output]
1 1 2 3 4 4 5 5 6 9
 
| | ()
| 1.000000 [height diff 2]
| | | ()
| | 1.000000 [height diff 1]
| | | | ()
| | | 2.000000 [height diff 0]
| | | | ()
3.000000 [height diff 2]
| | ()
| 4.000000 [height diff 4]
| | | | ()
| | | 4.000000 [height diff 0]
| | | | ()
| | 5.000000 [height diff 2]
| | | | | | ()
| | | | | 5.000000 [height diff 0]
| | | | | | ()
| | | | 6.000000 [height diff -1]
| | | | | ()
| | | 9.000000 [height diff -2]
| | | | ()
[/output]
 
Cheers, & enjoy,
 
- Alf
woodbrian77@gmail.com: Dec 10 09:20PM -0800

Shalom
 
I tried calling std::string::append with a string_view, but the
compiler rejected it. It seems like there should be support
for that. I wound up having to call the data() and size()
functions on string_view and pass that on to append. Maybe
support for that has been added, but is only available in newer
compilers? G-d willing a new version of TrueOS -- trueos.org --
\will land soon...
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
Melzzzzz <mel@zzzzz.com>: Dec 11 06:25AM +0100

On Sat, 10 Dec 2016 21:20:29 -0800 (PST)
 
> Brian
> Ebenezer Enterprises - In G-d we trust.
> http://webEbenezer.net
 
How to solve mouse wheel up scrolling and making back action in firefox
in TrueOS? Also in thunderbird mouse wheel up does not scrolls smooth
rather goes immediately in beginning of article. I have found question
in google but no answer.
 
--
press any key to continue or any other to quit...
kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Dec 10 09:00PM -0800

hi,
I am nearly new to c++,so i dont know how to build a configuration file for parsing json or xml.Could you guys please recommend me the best way to do that
Thanks,
Kushal
kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Dec 10 09:16PM -0800

to put it in a correct way this config file will have xml and json
woodbrian77@gmail.com: Dec 10 06:26PM -0800

Shalom
 
I have clang 3.8.1 installed here and it has the string_view
header in an experimental directory. Has that file been
moved out of that directory in newer compilers?
 
I want to add support for string_view to the C++ Middleware
Writer. Having support for string_view will allow me to simplify
some of the messages I build. Thanks in advance.
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
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)