Saturday, October 31, 2015

Digest for comp.lang.c++@googlegroups.com - 1 update in 1 topic

"Öö Tiib" <ootiib@hot.ee>: Oct 30 06:41PM -0700

On Friday, 30 October 2015 22:47:35 UTC+2, Daniel wrote:
> > be your strongest side. Build upon it.
 
> If you are interested in the context, you can look at the section "Converting CSV files to json" in
 
> https://github.com/danielaparker/jsoncons
 
Indeed I was interested in context. Context here seems to be that it is a
deserializer? I actually still don't know why the object to deserialize
is a data member (component) of the deserializer. It seems that it is
so for achieving that deserialization and transfer of deserialization
results can then happen as separate steps/calls. May be that is useful
but it is not immediately apparent why.
 
Parsers typically produce/allocate the objects during parsing and
transfer ownership right as result (return value) of parsing. Less
popular alternative is to pass the object as IN-OUT parameter to parser.
 
You deserialize into 'basic_json' that looks somewhat like 'boost::variant'.
Real 'boost::variant' does some more tricks to reduce levels of indirection;
it may perform slightly better (less news/deletes). Also it does some
tricks to achieve more compile-time optimizations and type-safety but that
all is perhaps beyond the point.
 
 
> But I don't think that that context matters very much. Yes, some things you can build up with T:T(...), and other things you can't. My question had to do with the latter, and there's not much else to be said about it.
 
Context can always matter since we have no silver bullets that are
equally good in every context. If you want to keep your deserialization as
two steps and result of it as by-value data member then you may want
to consider:
 
T t = builder.give_result(); // returns r-value reference to result
 
instead of:
 
T t = std::move(builder.result); // result is public data member
 
Both technically move from data member but former is simpler to
extend or to change.
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.

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

fl <rxjwg98@gmail.com>: Oct 31 09:52AM -0700

Hi,
 
As I remember that the friendship of a class is not inherited, in the
following code, I don't understand the comment:
// these operators need access to the Query_base* constructor
 
I do see Query constructor:
Query(const Query &c)
 
but I do not see Query_base constructor.
 
BTW, this code snippet is from a C++ book.
Could you tell me how to understand the above comment?
Thanks,
 
............
class Query_base {
friend class Query;
protected:
typedef TextQuery::line_no line_no;
virtual ~Query_base() { }
private:
// eval returns the |set| of lines that this Query matches
virtual std::set<line_no>
eval(const TextQuery&) const = 0;
// display prints the query
virtual std::ostream&
display(std::ostream& = std::cout) const = 0;
};
 
 
// handle class to manage the Query_base inheritance hierarchy
class Query {
// these operators need access to the Query_base* constructor
friend Query operator~(const Query &);
friend Query operator|(const Query&, const Query&);
friend Query operator&(const Query&, const Query&);
public:
Query(const std::string&); // builds a new WordQuery
 
// copy control to manage pointers and use counting
Query(const Query &c): q(c.q), use(c.use) { ++*use; }
~Query() { decr_use(); }
Query& operator=(const Query&);
 
// interface functions: will call corresponding Query_base operations
std::set<TextQuery::line_no>
eval(const TextQuery &t) const { return q->eval(t); }
std::ostream &display(std::ostream &os) const
{ return q->display(os); }
"Öö Tiib" <ootiib@hot.ee>: Oct 31 01:43PM -0700

On Saturday, 31 October 2015 18:52:55 UTC+2, fl wrote:
 
> I do see Query constructor:
> Query(const Query &c)
 
> but I do not see Query_base constructor.
 
I have feeling that it can be typo in comment. Comment tries
to explain why these operators are made 'friend' of 'Query' but the
given reason is confusing. Most easy to find out why these actually
are made friends is perhaps to make these not friends (remove
friend declarations from class) and try to compile.
 
 
> BTW, this code snippet is from a C++ book.
 
C++ is quite infamous for hundreds of books about it that have low
quality and may mislead more than help.
fl <rxjwg98@gmail.com>: Oct 31 01:53PM -0700

On Saturday, October 31, 2015 at 4:43:43 PM UTC-4, Öö Tiib wrote:
 
> > BTW, this code snippet is from a C++ book.
 
> C++ is quite infamous for hundreds of books about it that have low
> quality and may mislead more than help.
Thanks.
Yes, I have tried to comment out 'friend' keyword. It cannot pass compiling.
In class Query, there is a private member q, which points to Query_base:
 
// interface functions: will call corresponding Query_base operations
std::set<TextQuery::line_no>
eval(const TextQuery &t) const
{ return q->eval(t); }
private:
Query(Query_base *query): q(query),
use(new std::size_t(1))
{}
Query_base *q;
 
 
 
 
I check below a derived class. There is a constructor:
BinaryQuery(Query left, Query right, std::string op)
 
Is it a derived class constructor?
 
There is operator (|: or, &: and etc.) on it.
The original code may not comment accurately.
 
 
........
class BinaryQuery: public Query_base {
protected:
BinaryQuery(Query left, Query right, std::string op):
lhs(left), rhs(right), oper(op) { }
 
// abstract class: BinaryQuery doesn't define eval
std::ostream& display(std::ostream &os) const
{ return os << "(" << lhs << " " << oper << " "
<< rhs << ")"; }
 
const Query lhs, rhs; // right- and left-hand operands
const std::string oper; // name of the operator
};
"Öö Tiib" <ootiib@hot.ee>: Oct 31 02:09PM -0700

On Saturday, 31 October 2015 22:53:18 UTC+2, fl wrote:
 
> Is it a derived class constructor?
 
> There is operator (|: or, &: and etc.) on it.
> The original code may not comment accurately.
 
 
It may be that the comment that you talk about wanted to say something
like: "the operators need access to Query::Query(Query_base*) that is
private and so are made friend.".
asetofsymbols@gmail.com: Oct 31 12:38AM -0700

is it possible define operator% as
m<t> operator%(m<t>& a, t (f)(t))
where the 2th arg of operator% is one function
f:t->t?
or
m<t> operator%(m<t> a, t operator f(t))
when the function for apply in one
unary operator f:t->t
asetofsymbols@gmail.com: Oct 31 12:51AM -0700

is it all ok in
a=b*c+k
where
m<t> a,b,c,k;
m<t> operator+(const m<t>& x, const m<t>& y)
{m<t> result;
....
return result;
}
 
m<t> operator*(const m<t>& x, const m<t>& y)
{m<t> result;
....
return result;
}
 
if one consider memory allocation
Thank you
asetofsymbols@gmail.com: Oct 31 01:57AM -0700

> m<t> operator%(m<t> a, t operator f(t))
> when the function for apply in one
> unary operator f:t->t
 
is possible one operator% as this
<template Q> m<Q> operator%(m<t> a, Q operator f(t))
where f is a function f:t->Q
one operator that has result one matrix
of one other type in template
asetofsymbols@gmail.com: Oct 31 03:14AM -0700

Above i mean
template <class q>
m<q> operator%(m<t> x, q (f)(t) )
 
Where f is a function t->q
In practice
get one matrix of element type t [x]
Create a matrix of element type q
has the same number elements
Matrix x and the same sizes
Apply to each element of x
f and fill the matrix result
Is possible in that way?
y=x%f
asetofsymbols@gmail.com: Oct 31 03:54AM -0700

template <class q>
m<q> operator%(m<t> x, q (f)(t) )
 
 
If f is one operator for me that
is not possible in C++
m<u32> y(2,3), x(2,3);
 
y=x%~;
Seem ugly
possibly better
y=~%x;
 
template <class q>
m<q> operator%( q (f)(t), m<t> a)
 
with f operator or function...
but in the case of operator
=~%
sound strange...
Paavo Helde <myfirstname@osa.pri.ee>: Oct 31 11:47AM -0500

asetofsymbols@gmail.com wrote in news:593ee2f2-a0cb-44c4-9778-
> f and fill the matrix result
> Is possible in that way?
> y=x%f
 
Yes this is possible (ssuming I have interpreted your mumbling
correctly):
 
#include <vector>
#include <cassert>
#include <cstdlib>
 
template<typename T>
std::vector<T> operator%(const std::vector<T>& v, T (*f)(T)) {
std::vector<T> result;
for(auto x: v) result.push_back((*f)(x));
return result;
}
 
int main() {
std::vector<int> v = {1, -2, 3, -4};
std::vector<int> w = v % std::abs;
assert(w[3]==4);
}
asetofsymbols@gmail.com: Oct 31 10:20AM -0700

Thank you
I wrote until now only something as
u32 f(u32 x){return 2*x;}
 
M<u32> x(2,3);
x.i(); x.apply(f);
asetofsymbols@gmail.com: Oct 31 11:18AM -0700

I wrote:
u32 f(u32 x){return 2*x;}
 
M<u32> x(2,3);
x.i(); x.apply(f);
-------
I have seen in matlab anonymous
functions something as
x.apply( @(z) 2*z);
are there anonymous function in C++?
Wouter van Ooijen <wouter@voti.nl>: Oct 31 10:04PM +0100

> functions something as
> x.apply( @(z) 2*z);
> are there anonymous function in C++?
 
google "c++ lambda"
 
Wouter
Paul <pepstein5@gmail.com>: Oct 31 01:46PM -0700

The code pasted below is a fairly standard implementation of a fairly standard problem -- finding the mth-to-last value in a linked list. I omitted the memory management aspects.
I don't understand why the destructor is never called. For example, a local copy of the linked list is created in the constructList() function. I thought the destructor would be called when it goes out of scope.
 
Thank you very much for your help.
 
Paul
 
#include <cmath>
#include <cstdio>
#include <vector>
#include <iostream>
#include <algorithm>
using namespace std;
 
struct linkedList
{
int val;
linkedList* next;
 
linkedList(int Val):val(Val), next(0)
{
 
}
 
~linkedList()
{
cout << "destructor called"; // This never executes.
 
}
 
};
 
// Construct a linked list from stdin
const linkedList* constructList( )
{
linkedList* headList;
linkedList* buildList;
 
int listItems;
bool first = true;
while(cin >> listItems)
{
if(first)
{
buildList = new linkedList(listItems);
headList = buildList;
first = false;
}
 
else
{
buildList->next = new linkedList(listItems);
buildList = buildList->next;
}
 
}
return headList;
}
 
void mth_to_last(const linkedList* const& list, int m)
{
if(m <= 0)
{
cout << "NIL";
return;
}
 
const linkedList* fast = list;
const linkedList* slow = list;
 
for(int i = 0; i < m; ++i)
{
if(fast)
fast = fast->next;
else
{
cout << "NIL";
return;
}
}
 
while(fast)
{
fast = fast->next;
slow = slow->next;
}
 
cout << slow->val;
}
 
int main() {
 
int m;
cin >> m;
cin.clear();
const linkedList* list = constructList();
mth_to_last(list, m);
 
return 0;
}
bartekltg <bartekltg@gmail.com>: Oct 31 10:01PM +0100

On 31.10.2015 21:46, Paul wrote:
> list is created in the constructList() function. I thought the
> destructor would be called when it goes out of scope.
 
> Thank you very much for your help.
 
Dynamically allocated object do not have a scope!
A pointer to linkedList does have a scope, but is is not
tidied to life of an objetc.
If you want to create a dynamic allocated object which life
is equal to the life of a pointer to this object, use smart
pointers. unique_ptr or shared_ptr (and then look to the
manual to see, how to construct pointers,; avoid new).
 
If you allocate something with new, you (in most cases)
have to delete is manually!
 
BTW, do not keep linked list as a pointer. You want to
wrap it into an object, a container. Then your container
have a destructor, where you can manually clean everything.
 
bartekltg
 
 
Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 31 05:22PM

On Fri, 2015-10-30, Geoff wrote:
>>in seeing the languages listed in chronological order?
>>There doesn't seem to be any order to the listing now.
 
> Alphabetical would be more logical.
 
However, what matters is what rules Wikipedia has around
such things.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
fl <rxjwg98@gmail.com>: Oct 31 08:09AM -0700

Hi,
 
I notice that the return value 'ret_lines' definition has no scope 'TextQuery'
as the internal variable 'has_val'. Is there any rule on such usage?
 
 
Thanks,
 
 
..........
// returns lines not in its operand's result set
set<TextQuery::line_no>
NotQuery::eval(const TextQuery& file) const
{
// virtual call through the Query handle to eval
set<TextQuery::line_no> has_val = query.eval(file);
 
set<line_no> ret_lines;
 
// for each line in the input file, check whether that line is in has_val
// if not, add that line number to ret_lines
for (TextQuery::line_no n = 0; n != file.size(); ++n)
if (has_val.find(n) == has_val.end())
ret_lines.insert(n);
return ret_lines;
}
"Öö Tiib" <ootiib@hot.ee>: Oct 31 08:51AM -0700

On Saturday, 31 October 2015 17:09:20 UTC+2, fl wrote:
 
> I notice that the return value 'ret_lines' definition has no scope 'TextQuery'
> as the internal variable 'has_val'. Is there any rule on such usage?
 
> Thanks,
 
 
You posted a slice of code that does not compile with C++ compiler
and what it means depends on code that you did not post.
We do not know what type names 'line_no' and 'TextQuery::line_no'
represent; seems these are aliases to some integer type.
 
 
Paavo Helde <myfirstname@osa.pri.ee>: Oct 31 11:31AM -0500

fl <rxjwg98@gmail.com> wrote in
> // virtual call through the Query handle to eval
> set<TextQuery::line_no> has_val = query.eval(file);
 
> set<line_no> ret_lines;
 
As far as we know from this excerpt, the names TextQuery::line_no and
line_no may refer to different types, or they may not. For example, if
TextQuery is a class and NotQuery is inherited from TextQuery, they would
most probably refer to the same type.
 
A decent programming IDE would provide you with a 'go to definition'
feature which would help you to see (with some confidence) if they are
the same or not.
 
hth
Paavo
fl <rxjwg98@gmail.com>: Oct 31 09:58AM -0700

On Saturday, October 31, 2015 at 12:32:19 PM UTC-4, Paavo Helde wrote:
> the same or not.
 
> hth
> Paavo
 
Thanks both of you. Both types have its respective typedef's. They are
different.
fl <rxjwg98@gmail.com>: Oct 31 07:13AM -0700

Hi,
 
I know cin is standard input. I see the following code, but I don't know when
the return value of cin is '0'.
 
Could you tell me that?
 
Thanks,
 
 
 
 
bool get_word(string &s1)
{
cout << "enter a word to search for, or q to quit: ";
cin >> s1;
if (!cin || s1 == "q") return false;
else return true;
}
Richard Damon <Richard@Damon-Family.org>: Oct 31 10:54AM -0400

On 10/31/15 10:13 AM, fl wrote:
> if (!cin || s1 == "q") return false;
> else return true;
> }
 
cin is a istream.
 
istreams define a member operator!() which is the equivalent to calling
fail() to see if something has gone wrong with the stream (like it
couldn't extract a string s1)
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 31 01:10PM +0100

On 10/31/2015 11:59 AM, Stefan Ram wrote:
 
> #include <iostream>
> #include <ostream>
 
> int main() { constexpr auto num{ 11 }; ::std::cout << num << '\n'; }
 
My gut feeling: None of these involve initializer_list, even though
they syntactically involve initializer-list (oh, the difference of a
hyphen: reminds me of Latin 1 versus Latin-1, not sure what that was).
 
They look like formally direct initializations.
 
And as far as I can recall the syntax
 
int x = {42};
 
(copy initialization, but with the braces so that it looks like an
initialization_list) has always been valid, from original C and onward.
 
So, my gut feeling is that you need something like
 
auto x = {42};
 
and then you'd be in initializer_list-land.
 
 
Cheers & hth.,
 
- Alf
Victor Bazarov <v.bazarov@comcast.invalid>: Oct 31 08:44AM -0400

On 10/31/2015 6:59 AM, Stefan Ram wrote:
 
> #include <iostream>
> #include <ostream>
 
> int main() { constexpr auto num{ 11 }; ::std::cout << num << '\n'; }
 
How do you know that the header <initializer_list> is NOT included by
some directive in <iostream>, <ostream> or any headers they include? If
it's included, it's not "implicit use", is it?
 
V
--
I do not respond to top-posted replies, please don't ask
ram@zedat.fu-berlin.de (Stefan Ram): Oct 31 10:59AM

The following program looks innocuous.
 
#include <iostream>
#include <ostream>
 
int main() { constexpr int num{ 11 }; ::std::cout << num << '\n'; }
 
Does the above constitute an »implicit use of the template
»std::initializer_list«? I am thinking of 8.5.4p2:
 
»The template std::initializer_list is not predefined; if the
header <initializer_list> is not included prior to a use of
std::initializer_list --- even an implicit use in which the
type is not named (7.1.6.4) --- the program is ill-formed.«
 
Or would only the following be such an implicit use?
 
#include <iostream>
#include <ostream>
 
int main() { constexpr auto num{ 11 }; ::std::cout << num << '\n'; }
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.

Friday, October 30, 2015

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

Daniel <danielaparker@gmail.com>: Oct 29 07:46PM -0700

Consider a class TBuilder that builds a value of type T, which it holds as a data member.
 
Now suppose a user of TBuilder wants to efficiently extract the T value, assuming T has move constructor and move assignment. What would be the most natural interface for accomplishing that?
 
TBuilder builder;
 
// supply an accessor that returns an l-value and support std::move
T t = std::move(builder.get_t())
 
// make T value a public member and support std::move
T t = std::move(builder.t);
 
// provide a swap_t method
 
T t;
builder.swap_t(t);
 
Other?
 
Thanks,
Daniel
"Öö Tiib" <ootiib@hot.ee>: Oct 30 02:32AM -0700

On Friday, 30 October 2015 04:47:06 UTC+2, Daniel wrote:
> Consider a class TBuilder that builds a value of type T, which it holds as a data member.
 
What is that T and why it has a builder/factory object (instead
of constructor)? IOW ... why 'TBuilder::TBuilder()' is better place
for building that sole T member of it up than 'T::T()'?
 
 
> TBuilder builder;
 
> // supply an accessor that returns an l-value and support std::move
> T t = std::move(builder.get_t())
 
How can we return l-value? Functions return r-values. Did you mean
that the accessor returns l-value *reference*?
 
 
> T t;
> builder.swap_t(t);
 
> Other?
 
Just remove 'TBuilder' from the design. Without explanation
it feels like unneeded overengineering.
Daniel <danielaparker@gmail.com>: Oct 30 06:25AM -0700

On Friday, October 30, 2015 at 5:33:09 AM UTC-4, Öö Tiib wrote:
 
> What is that T and why it has a builder/factory object (instead
> of constructor)? IOW ... why 'TBuilder::TBuilder()' is better place
> for building that sole T member of it up than 'T::T()'?
 
I don't have a question about that. My question was about how to transfer the data member once constructed, what would be the most natural from the point of view of the user of the class.
 
> > T t = std::move(builder.get_t())
 
> How can we return l-value? Functions return r-values. Did you mean
> that the accessor returns l-value *reference*?
 
Yes, sorry, T& get_t()
 
> Just remove 'TBuilder' from the design. Without explanation
> it feels like unneeded overengineering.
 
It may, but how you feel is irrelevant, that wasn't my question :-)
 
I decided to go with the public member access.
 
Thanks,
Daniel
"Öö Tiib" <ootiib@hot.ee>: Oct 30 11:37AM -0700

On Friday, 30 October 2015 15:26:05 UTC+2, Daniel wrote:
> > of constructor)? IOW ... why 'TBuilder::TBuilder()' is better place
> > for building that sole T member of it up than 'T::T()'?
 
> I don't have a question about that. My question was about how to transfer the data member once constructed, what would be the most natural from the point of view of the user of the class.
 
Who said these were your questions? Why only your questions deserve
an answer? I choose to forgive to you since being pathetic seems to
be your strongest side. Build upon it.
Daniel <danielaparker@gmail.com>: Oct 30 01:47PM -0700

On Friday, October 30, 2015 at 2:37:44 PM UTC-4, Öö Tiib wrote:
 
> Who said these were your questions? Why only your questions deserve
> an answer? I choose to forgive to you since being pathetic seems to
> be your strongest side. Build upon it.
 
If you are interested in the context, you can look at the section "Converting CSV files to json" in
 
https://github.com/danielaparker/jsoncons
 
But I don't think that that context matters very much. Yes, some things you can build up with T:T(...), and other things you can't. My question had to do with the latter, and there's not much else to be said about it.
 
Be well,
Daniel
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 30 10:18PM +0100

On 10/30/2015 3:46 AM, Daniel wrote:
 
> T t;
> builder.swap_t(t);
 
> Other?
 
Maybe you can think of the T value as an /object/, that is just
referenced by the TBuilder.
 
Then you can pass references to that object about.
 
Maybe shared_ptr.
 
 
Cheers & hth.,
 
- Alf
woodbrian77@gmail.com: Oct 30 01:48PM -0700

> the ID in code generation requests, thereby giving
> tier-1 users an advantage over those who are slower
> to start using the CMW.
 
On this page
 
https://en.wikipedia.org/wiki/Serialization
 
Java has 404 words of description but C++ only has 90.
And Java is listed before C++. Are others interested
in seeing the languages listed in chronological order?
There doesn't seem to be any order to the listing now.
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
Geoff <geoff@invalid.invalid>: Oct 30 02:17PM -0700

>And Java is listed before C++. Are others interested
>in seeing the languages listed in chronological order?
>There doesn't seem to be any order to the listing now.
 
Alphabetical would be more logical.
Juha Nieminen <nospam@thanks.invalid>: Oct 30 09:42AM

> Replacing the return type entirely with auto has the same pros and cons
> as using auto in general. It is convenient for complicated types, but
> omits information that might be useful to the programmer and reader.
 
That depends.
 
The 'auto' variable declaration type is most useful in generic code,
especially templates and functions with 'auto' parameters.
 
"What, you mean there's other kind of 'generic code' than templates?"
Well, kind of. There are certain situations where it's actually useful
that 'auto' adapts to any changes to a type. The kind of situations where
if you change a type somewhere, then you would need to go through thousands
of lines of code to change the usage of that type. Of course traditionally
this has been circumvented by abstracting the type away with typedef
(which is still a completely valid technique, of course), but in some
situations 'auto' may be a more fluent solution.
 
In the same vein, there may be situations where we don't actually care
what a type is exactly, because we are not interested in it. A typical
example is something like:
 
auto x = std::bind(&some_function, _2, _1, some_object);
 
Here we don't actually care what the type returned by std::bind() is.
We only care about what it does.
 
And then of course there are situations where 'auto' shortens the code
and makes it cleaner without sacrificing undestandability. The typical
example is:
 
auto iter = container.begin();
 
The type of that iterator may sometimes be very long and superfluous.
'auto' is perfect in this situation, and is quite clear what it does.
 
Of course if abused, like anything else, it can lead to bad code.
You should always know your tools.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
scott@slp53.sl.home (Scott Lurndal): Oct 30 01:13PM

>name.
 
>However, some people use a formatting convention where the function name
>has fixed placement also with the old syntax.
 
Indeed, as Dennis Richie's convention was
 
name_of_type
foo(name_of_type)
 
which meant /^foo in vi would always take one to the
implementation of 'foo'.
 
Works fine in C++ as well.
 
e.g. from the version 6 C compiler (circa 1975): c00.c
 
/*
* Read an expression and return a pointer to its tree.
* It's the classical bottom-up, priority-driven scheme.
* The initflg prevents the parse from going past
* "," or ":" because those delimiters are special
* in initializer (and some other) expressions.
*/
struct tnode *
tree()
{
...
legalize+jeeves@mail.xmission.com (Richard): Oct 30 04:26AM

[Please do not mail me a copy of your followup]
 
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> spake the secret code
>with code that uses unqualified "strcpy" (for example) compiling nicely
>with the original compiler, and then failing with some other compiler.
>So, use "<string.h>".
 
While I agree with your analysis, I don't agree that <cstring> has
negative utility. I *want* those C-style library calls pushed off
into namespace std and that's why I use <cstring>. A proper
implementation will put those names only in namespace std and not dump
them anywhere else. Additionally, there are some changes to the
signatures of these C library functions mandated by the C++ standard
when they are included as <cstring> that are not present when included
as <string.h>. See 21.7 [c.strings] in the C++11 standard, for
instance.
 
Furthermore, things that are declared as macros when including the C
style header are mandated to be declared as functions when including
the C++ header. Look at how table 74 describes things like isalnum
and tolower in the standard. It refers to them as functions, not as
macros. This is reasonable in C++ because it has inline functions,
but in C this would traditionally be done with a macro. So when using
<cctype>, I should get fewer preprocessor surprises because something
was declared as a macro instead of being declared as a proper inline
function.
 
I'm not sure how conforming actual implementations are to this wording,
however. For a long time people took shortcuts that lead to the kinds
of problems you describe. However, I would rather be clear about my
intent -- including the C++ version of a C library header with
<cstring> -- and deal with the occasional compile error because I
forgot the std:: prefix.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 30 05:50AM +0100

On 10/30/2015 5:26 AM, Richard wrote:
> when they are included as <cstring> that are not present when included
> as <string.h>. See 21.7 [c.strings] in the C++11 standard, for
> instance.
 
You're missing that the C++ "<string.h>" header is defined in terms of
C++ "<cstring>", which in turn is defined in terms of the C "<string.h>".
 
I.e. those requirements on C++'s "<cstring>" automatically apply also to
the C++ "<string.h>".
 
In the C++11 standard that's in §D.5/2,
 
<quote>
Every C header, each of which has a name of the form `name.h`, behaves
as if each name placed in the standard library namespace by the
corresponding /cname/ header is placed within the global namespace
scope. It is unspecified whether these names are first declared or
defined within namespace scope (3.3.6) of the namespace std and are then
injected into the global namespace scope by explicit using-declarations
(7.3.3).
</quote>
 
Btw. that might sound as if "<string.h>" assuredly also provides the
identifiers in the std namespace, but a following example makes clear
that it doesn't need to.
 
 
> <cctype>, I should get fewer preprocessor surprises because something
> was declared as a macro instead of being declared as a proper inline
> function.
 
Nope, the requirements are the same, except for namespaces.
 
 
> intent -- including the C++ version of a C library header with
> <cstring> -- and deal with the occasional compile error because I
> forgot the std:: prefix.
 
 
Cheers & hth.,
 
- Alf
Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 30 08:34AM

On Fri, 2015-10-30, Richard wrote:
 
> While I agree with your analysis, I don't agree that <cstring> has
> negative utility. I *want* those C-style library calls pushed off
> into namespace std and that's why I use <cstring>.
 
Agree. I don't want a distinction between "function I use which
originated in C" and "function that's new for C++".
 
It gets trickier when you're e.g. writing Unix code, and something
POSIX-specific is defined to live in one of the C header files. Then
I use <foo.h> rather than <cfoo>.
 
...
> intent -- including the C++ version of a C library header with
> <cstring> -- and deal with the occasional compile error because I
> forgot the std:: prefix.
 
Especially since there are other such sources of errors, like
accidentally relying on foo.h to pull in bar.h, even if the standard
doesn't guarantee that it does.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Juha Nieminen <nospam@thanks.invalid>: Oct 30 09:50AM

> As evident from the all uppercase name, INT_MIN is a macro.
 
The standard does not always follow that naming convention. Counter-examples:
 
assert()
std::FILE
 
(We may blame C for this, but it is there in the C++ standard nevertheless.)
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
ram@zedat.fu-berlin.de (Stefan Ram): Oct 30 03:10AM

>T t = std::move(builder.get_t())
 
I'd put the move into the looter:
 
::std::string && loot_t(){ return ::std::move( t ); }
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.

Thursday, October 29, 2015

Digest for comp.lang.c++@googlegroups.com - 13 updates in 4 topics

Victor Bazarov <v.bazarov@comcast.invalid>: Oct 29 08:04AM -0400

On 10/28/2015 5:36 PM, Paul wrote:
> Is there any way of ascertaining (other than looking it up) whether
objects are in the standard namespace? For example, INT_MIN from the
<climits> header is not in the std namespace but cout from <iostream> is
in the std namespace.
> How could one deduce that beforehand to avoid compile errors from
writing std::INT_MIN?
 
> Is the rule that functions from header files are in the std namespace
> but variables from header files are not in the std namespace? Or is
> it subtler? Or something else I haven't thought of?
 
If you know that it's a macro you can only use #ifdef {macroname},
otherwise when the compiler gets to it, the name has already been
substituted with its meaning.
 
If it's an object (like 'cout'), you could try taking its address and
wrap it in a SFINAE definition/declaration (nothing on the top of my
head, though).
 
V
--
I do not respond to top-posted replies, please don't ask
Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 29 12:40PM

On Wed, 2015-10-28, Paul wrote:
> namespace but variables from header files are not in the std
> namespace? Or is it subtler? Or something else I haven't thought
> of?
 
What problem are you trying to solve? To mistype and have the
compiler correct you, that's not such a great burden[0].
 
"assert" and anything in CAPITALS are macros, the rest is in std --
I think that's a pretty good rule of thumb.
 
/Jorgen
 
[0] Gone are the days of batch programming where you'd get the
compilation error on paper the next morning ...
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Vir Campestris <vir.campestris@invalid.invalid>: Oct 29 09:28PM

On 28/10/2015 21:36, Paul wrote:
> Is there any way of ascertaining (other than looking it up) whether objects are in the standard namespace? For example, INT_MIN from the <climits> header is not in the std namespace but cout from <iostream> is in the std namespace.
> How could one deduce that beforehand to avoid compile errors from writing std::INT_MIN?
 
> Is the rule that functions from header files are in the std namespace but variables from header files are not in the std namespace? Or is it subtler? Or something else I haven't thought of?
 
I know no rule. But in this case couldn't you use
std::numeric_limits<int>::min() ?
 
Andy
"Öö Tiib" <ootiib@hot.ee>: Oct 29 04:03AM -0700

On Wednesday, 28 October 2015 17:01:11 UTC+2, David Brown wrote:
 
> auto get_fun(int arg) {
> return make_function_pointer(arg);
> }
 
The feature is not that great since implicit return value type is allowing
us to omit important property. That is somewhat like implicit int of C was.
Also we often want to declare functions before defining those (in header)
and there what Juha wrote looks best:
 
auto get_fun(int arg) -> double (*)(double);
David Brown <david.brown@hesbynett.no>: Oct 29 01:43PM +0100

On 29/10/15 12:03, 嘱 Tiib wrote:
> Also we often want to declare functions before defining those (in header)
> and there what Juha wrote looks best:
 
> auto get_fun(int arg) -> double (*)(double);
 
Replacing the return type entirely with auto has the same pros and cons
as using auto in general. It is convenient for complicated types, but
omits information that might be useful to the programmer and reader. It
makes code more flexible (especially for templates), but reduces the
possibilities for type-based error checking. And clearly it can't work
without the function definition (i.e., it will not work in non-defining
declarations).
 
It's a feature - you can use it if it helps, and avoid it if it does not
help.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 29 10:04PM +0100

On 10/28/2015 2:25 PM, Juha Nieminen wrote:
 
[snip]
 
> auto get_fun(int arg) -> double (*)(double)
 
> vs. the old way:
 
> double (*get_fun(int))(double)
 
Also, old way
 
Longwinded_class_name::name_of_type Longwinded_class_name::foo(
name_of_type arg
)
{
...
}
 
versus
 
auto Longwinded_class_name::foo( name_of_type arg )
-> name_of_type
{
...
}
 
One less qualification (of the return type), which is also more
consistent, plus more easily recognized fixed placement of the function
name.
 
However, some people use a formatting convention where the function name
has fixed placement also with the old syntax.
 
 
Cheers,
 
- Alf
"Öö Tiib" <ootiib@hot.ee>: Oct 29 02:13AM -0700

> You want to say is not possible
> define operator as one of these
> symbols?
 
It is simple. If you are programmer then anything is possible to do.
It does not matter what others want or don't want to say.
 
C++ standard defines only usage of most of the ASCII characters
but that does not matter for programmer. Lets say you have code:
 
auto a = white_chess_rook( x, y );
 
With some operator overloading tricks you can turn it into:
 
auto a = x *white_chess_rook* y;

Then you can change the text editor to automatically show/use '♖'
instead of '*white_chess_rook*' like that:
 
auto a = x ♖ y;
 
As result compiler still gets what is required by standard and you get
to see and to use your odd characters that you want and we do not
need to modify the programming language.
 
From my keyboard it is not too convenient to type characters like
that white chess rook character and the whole eye-candy leaves me
indifferent so I do not want your editor.
asetofsymbols@gmail.com: Oct 29 02:24AM -0700

You not think enough...
asetofsymbols@gmail.com: Oct 29 02:27AM -0700

Yes I not think enough too
asetofsymbols@gmail.com: Oct 29 03:54AM -0700

Öö Tiib wrote:
 
> You want to say is not possible
> define operator as one of these
> symbols?
 
 
It is simple. If you are programmer then anything is possible to do.
It does not matter what others want or don't want to say.
 
C++ standard defines only usage of most of the ASCII characters
but that does not matter for programmer. Lets say you have code:
 
auto a = white_chess_rook( x, y );
 
With some operator overloading tricks you can turn it into:
 
auto a = x *white_chess_rook* y;

Then you can change the text editor to automatically show/use '♖'
instead of '*white_chess_rook*' like that:
 
auto a = x ♖ y;
 
As result compiler still gets what is required by standard and you get
to see and to use your odd characters that you want and we do not
need to modify the programming language.
 
From my keyboard it is not too convenient to type characters like
that white chess rook character and the whole eye-candy leaves me
indifferent so I do not want your editor.
_________
Excuse me you are right
I think is possible modify
the macro sys to handle
a=x♖y;
case
asetofsymbols@gmail.com: Oct 29 04:11AM -0700

%operatorDefine ♖ f
Possibly a=x♖(z♖z); case too in
 
a=f(x, (f(z,z)))
too
David Brown <david.brown@hesbynett.no>: Oct 29 01:33PM +0100

On 29/10/15 10:13, Öö Tiib wrote:
 
> auto a = white_chess_rook( x, y );
 
> With some operator overloading tricks you can turn it into:
 
> auto a = x *white_chess_rook* y;
 
One can do even better than that. Make the operator overloading tricks
so that you are using "* do_white_chess_rook *", and then have:
 
#define white_chess_rook * do_white_chess_rook *
 
Then you can write:
 
auto a = x white_chess_rook y;
 
 
> From my keyboard it is not too convenient to type characters like
> that white chess rook character and the whole eye-candy leaves me
> indifferent so I do not want your editor.
 
#include <cmath>
#include <iostream>
 
template<class T>
class DoPowerer {
T x_;
public :
constexpr DoPowerer(T x) : x_(x) {};
template<class U>
friend constexpr U operator*(const DoPowerer<U> dp, const U y);
};
 
class Powerer {
template<class T>
friend constexpr DoPowerer<T> operator*(const T x, const Powerer p);
};
 
template<class T>
constexpr DoPowerer<T> operator*(const T x, const Powerer p
__attribute__((unused)) {
return DoPowerer<T>(x);
}
 
template<class T>
constexpr T operator*(const DoPowerer<T> dp, const T y) {
return std::pow(dp.x_, y);
}
 
static constexpr const Powerer powerer;
#define power *powerer*
 
int main() {
std::cout << "6 power 3 = " << (6 power 3) << std::endl;
std::cout << "2.0 power 0.5 = " << (2.0 power 0.5) << std::endl;
}
 
So now "power" is somewhat like a new operator. And once gcc gets
extended identifiers (clang has them from 3.3 onwards), you can write:
 
#define ↑ *powerer*
 
and then you get to write 2 ↑ 10 instead of std::pow(2, 10).
 
 
Whether or not you think this is a good thing, is a different matter.
bleachbot <bleachbot@httrack.com>: Oct 25 07:33PM +0100

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.

Fwd: SIMPLY TOO SPECIAL



Sent from my iPad

Begin forwarded message:

From: Hsiao-Hung <k6hsi@aol.com>
Date: October 28, 2015 at 9:15:46 PM CDT
Subject: Fwd: SIMPLY TOO SPECIAL


Subject: Fwd: SIMPLY TOO SPECIAL

 

 
 

                                    

https://funstuffpeoplesendme.files.wordpress.com/2015/03/simplytoospecial019.jpg

https://funstuffpeoplesendme.files.wordpress.com/2015/03/simplytoospecial018.jpg

https://funstuffpeoplesendme.files.wordpress.com/2015/03/simplytoospecial017.jpg

https://funstuffpeoplesendme.files.wordpress.com/2015/03/simplytoospecial016.jpg

https://funstuffpeoplesendme.files.wordpress.com/2015/03/simplytoospecial015.jpg

https://funstuffpeoplesendme.files.wordpress.com/2015/03/simplytoospecial014.jpg

https://funstuffpeoplesendme.files.wordpress.com/2015/03/simplytoospecial013.jpg

https://funstuffpeoplesendme.files.wordpress.com/2015/03/simplytoospecial012.jpg

https://funstuffpeoplesendme.files.wordpress.com/2015/03/simplytoospecial011.jpg

https://funstuffpeoplesendme.files.wordpress.com/2015/03/simplytoospecial010.jpg

https://funstuffpeoplesendme.files.wordpress.com/2015/03/simplytoospecial009.jpg

https://funstuffpeoplesendme.files.wordpress.com/2015/03/simplytoospecial008.jpg

https://funstuffpeoplesendme.files.wordpress.com/2015/03/simplytoospecial007.jpg

https://funstuffpeoplesendme.files.wordpress.com/2015/03/simplytoospecial006.jpg

https://funstuffpeoplesendme.files.wordpress.com/2015/03/simplytoospecial005.jpg

https://funstuffpeoplesendme.files.wordpress.com/2015/03/simplytoospecial004.jpg

https://funstuffpeoplesendme.files.wordpress.com/2015/03/simplytoospecial003.jpg

https://funstuffpeoplesendme.files.wordpress.com/2015/03/simplytoospecial002.jpg

https://funstuffpeoplesendme.files.wordpress.com/2015/03/simplytoospecial001.jpg

https://funstuffpeoplesendme.files.wordpress.com/2015/03/simplytoospecial020.jpg