Thursday, April 30, 2015

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

Doug Mika <dougmmika@gmail.com>: Apr 30 09:45AM -0700

I have the following short program:
 
#include<algorithm>
#include<iostream>
#include<vector>
#include<list>
 
using namespace std;
 
template<typename T>
void FuncDisplayElement(const T& element){
cout<<element<<' ';
}
 
template<typename T>
struct DisplayElement{
void operator()(const T& element) const{
cout<<element<<' ';
}
};
 
 
int main(int argc, char** argv) {

//The Program
vector<int> vecIntegers;

for(int nCount=0;nCount<10; ++nCount)
vecIntegers.push_back(nCount);

list<char> listChars;

for(char nChar='a'; nChar<'k'; ++nChar)
listChars.push_back(nChar);

DisplayElement<int> de;

cout<<"Displaying the vector of integers"<<endl;
for_each(vecIntegers.begin(),vecIntegers.end(),de);
cout<<endl<<endl;

cout<<"Displaying the vector of integers again"<<endl;
for_each(vecIntegers.begin(),vecIntegers.end(),FuncDisplayElement<int>);
cout<<endl<<endl;

cout<<"Displaying the list of characters"<<endl;
for_each(listChars.begin(),listChars.end(),DisplayElement<char>());


return 0;
}
 
My question is, why do I need to include the brakets "()" in:
DisplayElement<char>()
 
when I don't include them in:
de
???
 
DisplayElement<char> creates an rvalue object of that type, so it is now similar to de, so why the brackets in one but not the other?
"Öö Tiib" <ootiib@hot.ee>: Apr 30 10:05AM -0700

On Thursday, 30 April 2015 19:46:07 UTC+3, Doug Mika wrote:
> }
 
> My question is, why do I need to include the brakets "()" in:
> DisplayElement<char>()
 
Because 'DisplayElement<char>' is type while 'DisplayElement<char>()'
makes temporary object of that type.
 
> when I don't include them in:
> de
> ???
 
The 'de' in your code is named object of type 'DisplayElement<int>'.
 
If you want it to be type 'DisplayElement<int>' then you have
to declare it like:
 
typedef DisplayElement<int> de;
 
or in C++11
 
using de = DisplayElement<int>;

On such cases you need to have brackets with de as well.
 
> DisplayElement<char> creates an rvalue object of that type, so it
> is now similar to de, so why the brackets in one but not the other?
 
Where you take that? Not in C++. 'DisplayElement<char>' is just a
type-id like 'int'. You can't use type where object is expected. The
'FuncDisplayElement<int>' is a pointer to function (so object),
'de' is also already existing object and so you need
'DisplayElement<char>()' to create object if you want to pass it
where object belongs in C++.
legalize+jeeves@mail.xmission.com (Richard): Apr 30 05:22PM

[Please do not mail me a copy of your followup]
 
Doug Mika <dougmmika@gmail.com> spake the secret code
 
>My question is, why do I need to include the brakets "()" in:
>DisplayElement<char>()
 
DisplayElement<char> is a type.
 
DisplayElement<char>() is an anonymous temporary instance of the type.
 
>when I don't include them in:
>de
 
This is a named instance of the type.
--
"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>
Doug Mika <dougmmika@gmail.com>: Apr 30 10:33AM -0700

well, that's what I thought, but then how can I explain it with the fact that when we have a class with a default (parameterless) constructor, say the class name is Human, I instantiate the class Human on the stack without the use of brackets:
 
Human someHoman;
 
NOT
Human someHuman();
Victor Bazarov <v.bazarov@comcast.invalid>: Apr 30 01:41PM -0400

On 4/30/2015 1:33 PM, Doug Mika wrote:
> well, that's what I thought, but then how can I explain it with the
fact that when we have a class with a default (parameterless)
constructor, say the class name is Human, I instantiate the class Human
on the stack without the use of brackets:
 
> Human someHoman;
 
> NOT
> Human someHuman();
 
Read up on "most vexing parse".
 
You *declare* a variable of type T by writing
 
T <nameofthevariable>;
 
That's a declaration statement. Depending on the scope in which it
appears it can also be a definition. Definition of an object implies
initialization. Parentheses shift the meaning of the declaration a tiny
bit (again, read up on declaration parsing and it's actually in the FAQ).
 
V
--
I do not respond to top-posted replies, please don't ask
Doug Mika <dougmmika@gmail.com>: Apr 30 11:00AM -0700

On Thursday, April 30, 2015 at 12:42:09 PM UTC-5, Victor Bazarov wrote:
 
> V
> --
> I do not respond to top-posted replies, please don't ask
 
That sort of clears things up. But then, when I declare the anonymous object using:
DisplayElement<int>()
 
am I declaring it on the stack or the heap? And when and by whom is it deleted?
"Öö Tiib" <ootiib@hot.ee>: Apr 30 11:03AM -0700

On Thursday, 30 April 2015 20:33:49 UTC+3, Doug Mika wrote:
> well, that's what I thought, but then how can I explain it with the fact that when we have a class with a default (parameterless) constructor, say the class name is Human, I instantiate the class Human on the stack without the use of brackets:
 
> Human someHoman;
 
If 'Human' is aggregate (without constructors like DisplayElement<int> is)
then function-local 'someHoman' will be uninitialized variable, it won't
be default constructed. Since 'DisplayElement<int>' is stateless (does not
have non-static data members) it does not matter to it, but generally it
matters.
 
> NOT
> Human someHuman();
 
That is function declaration in C++.
When Human is of aggregate type then you need to write:
 
Human someHaman = Human();
 
or:
 
Human someHeman = {};
 
or since C++11:
 
Human someHiman{};
 
to get it default-initialized.
"Öö Tiib" <ootiib@hot.ee>: Apr 30 11:15AM -0700

On Thursday, 30 April 2015 21:00:42 UTC+3, Doug Mika wrote:
 
> That sort of clears things up. But then, when I declare the anonymous object using:
> DisplayElement<int>()
 
> am I declaring it on the stack or the heap? And when and by whom is it deleted?
 
C++ standard does say "automatic storage" (that is usually stack) and
"dynamic storage" (that is usually heap). It does not specify if
temporaries are stored in either (but usually it is stack as well).
Temporary will be destroyed at the end of full expression unless you
initialize reference variable with it. If you initialize reference
variable with it then it will be destroyed when that variable leaves
scope.
legalize+jeeves@mail.xmission.com (Richard): Apr 30 03:05PM

[Please do not mail me a copy of your followup]
 
David Brown <david.brown@hesbynett.no> spake the secret code
 
>No, MSVC has always been notoriously bad at standard C. It barely
>implements the language parts of C99, and until only a couple of years
>ago, it was missing substantial parts of the C99 library.
 
OK, I'll take your word for it on that. Honestly, I haven't written
*C* code since the early 1990s and I really don't want to go back to
writing C code having used C++ all this time.
 
>For C++, I
>believe it is only a few years behind the mainstream (gcc, llvm, Intel)
>- but I haven't used it myself for quite some time.
 
VS2013 is quite current and VS2015 is filling in more of the C++11/14
gaps, certainly when compared to the gcc that ships with enterprise
linux distributions. (I know, you can always build your own gcc to get
around that, but at a big linux shop where I worked for the past 4 years
we were stuck with the lowest common denominator among all distributions
which left us with gcc 4.2.1 and the irony that our Windows build had
access all the modern features, but our linux build did not.)
 
The whole compiler landscape has changed with C++11/14; compiler
implementations are not only keeping up with the standard, they are
often ahead of the standard by implementing C++14/17 features from
working drafts before they are officially adopted. Things are moving
much faster now than they have previously.
 
I believe this table is a pretty accurate comparison:
<http://en.cppreference.com/w/cpp/compiler_support>
If it's not, please edit the table to be more accurate :-).
--
"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>
David Brown <david.brown@hesbynett.no>: Apr 30 05:19PM +0200

On 30/04/15 17:05, Richard wrote:
 
> OK, I'll take your word for it on that. Honestly, I haven't written
> *C* code since the early 1990s and I really don't want to go back to
> writing C code having used C++ all this time.
 
I write C all the time, but for embedded systems rather than PC's. But
comp.lang.c has plenty of unpleasant things to say about MSVC for C.
 
> we were stuck with the lowest common denominator among all distributions
> which left us with gcc 4.2.1 and the irony that our Windows build had
> access all the modern features, but our linux build did not.)
 
Since I work with cross-compilers most of the time, I don't see such
issues - I don't make much use of native compilers. But some shops have
very restrictive rules on the tools that developers are allowed to use -
for good reasons or for bad reasons.
 
> often ahead of the standard by implementing C++14/17 features from
> working drafts before they are officially adopted. Things are moving
> much faster now than they have previously.
 
It makes a nice change - especially since C++11 brought in so many
useful features, and C++14 improves them.
 
legalize+jeeves@mail.xmission.com (Richard): Apr 30 03:21PM

[Please do not mail me a copy of your followup]
 
David Brown <david.brown@hesbynett.no> spake the secret code
 
>Or mingw-w64 and an IDE (Eclipse, Code Blocks, JEdit, etc. - or even
>emacs or vim).
 
emacs? If I want to time travel to 1990, it's fine. I used it from
1988 through 1998. It's an editor with a keyboard shortcut to invoke
a build, not really an IDE.
 
vim? Some people swear by it with the multiple windows and whatnot
that are in vim (not classic vi). It might be usable with all the
doodads and extensions on top, but a good IDE is much more than an
editor. I haven't tried a vim-ified experience, but if you're using
it only as classic vi experience, then it's only good for small
projects in my opinion. I used it for editing code from 1978-ish
through 1988. I still use daily for editing email. I don't use it
for editing anything other than small "will this compile?" type
programs.
 
JEdit seems to be an editor and not an IDE.
 
Eclipse? God no, please don't. Go use CLion from JetBrains instead.
In fact, always prefer something from JetBrains over Eclipse. For
Java it simply blows Eclipse out of the water. Yes, JetBrains IDEs
are commercial, but if you're working on open source, ask for a free
license and you'll probably get one.
 
Code Blocks (Code::Blocks?) is on my list of IDEs to try, but I
haven't yet.
 
If your environment doesn't actually parse C++ to give you
semantically meaningful navigation (oops, that cuts out ctags and
therefore vim and emacs as well), refactoring (oops, that cuts out any
editor), an intelligent debugger (oops, that cuts out editors) and
so-on, then it's not an IDE. It's an editor with keyboard shortcuts
to invoke other programs to make up for its deficiencies as an IDE.
The "I" (integrated) in IDE really is important.
--
"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>
Christopher Pisz <nospam@notanaddress.com>: Apr 30 11:23AM -0500

On 4/30/2015 10:21 AM, Richard wrote:
SNIP
 
> Java it simply blows Eclipse out of the water. Yes, JetBrains IDEs
> are commercial, but if you're working on open source, ask for a free
> license and you'll probably get one.
 
How does CLion measure up to Msvc if one intends to solely write code on
Windows? Is there any advantage to it? Is it difficult to find all the
common windows libs and such, like the winsock lib? Come with them?
 
I see the price tag is lower for an individual license and Intellisense
has really been pissing me off lately.
 
Or would it be more for a person who is writing code for multiple platforms?
 
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
"Öö Tiib" <ootiib@hot.ee>: Apr 30 09:50AM -0700

On Thursday, 30 April 2015 18:21:45 UTC+3, Richard wrote:
> Code Blocks (Code::Blocks?) is on my list of IDEs to try, but I
> haven't yet.
 
From general purpose IDEs NetBeans understands and highlights C++ lot
better than Code Blocks and tools seem also easier to integrate to it.
 
If you want to design for iPad or iPhone then you need Apple Xcode
that is otherwise not too good IDE. If you want to try Qt then it
is easiest with Qt Creator that is passable for IDE.
Paavo Helde <myfirstname@osa.pri.ee>: Apr 30 01:12PM -0500

legalize+jeeves@mail.xmission.com (Richard) wrote in news:mhth9u$11t$2
 
> Code Blocks (Code::Blocks?) is on my list of IDEs to try, but I
> haven't yet.
 
IMO you have not lost anything. My list of complaints about C::B is so long
I cannot even start.
Doug Mika <dougmmika@gmail.com>: Apr 30 10:38AM -0700

When I ran the following program:
#include<algorithm>
#include<iostream>
#include<vector>
using namespace std;
 
template<typename T>
struct DisplayElementKeepCount{
int Count;

DisplayElementKeepCount():Count(0){}

void operator()(const T& element){
++Count;
cout<<element<<' ';
}
};
 
int main(int argc, char** argv) {
 
//The Program
vector<int> vecIntegers;

for(int nCount=0;nCount<10; ++nCount)
vecIntegers.push_back(nCount);

DisplayElementKeepCount<int> Result;

cout<<"Displaying the vector of integers again"<<endl;
for_each(vecIntegers.begin(),vecIntegers.end(),Result);
cout<<endl<<endl;

cout<<"The Result count this time is: "<<Result.Count<<endl;


return 0;
}
 
the result of Result.Count is 0!!!, WHY isn't it 10????? Afterall, I call the oprator() 10 times!
Victor Bazarov <v.bazarov@comcast.invalid>: Apr 30 01:47PM -0400

On 4/30/2015 1:38 PM, Doug Mika wrote:
 
> DisplayElementKeepCount<int> Result;
 
> cout<<"Displaying the vector of integers again"<<endl;
> for_each(vecIntegers.begin(),vecIntegers.end(),Result);
 
Right here the 'Result' is not used directly, but *copied* into the
argument of 'for_each' function. Inside you're incrementing the 'Count'
member of the copy. The outside object is unchanged.
 
 
> return 0;
> }
 
> the result of Result.Count is 0!!!, WHY isn't it 10????? Afterall, I call the oprator() 10 times!
 
Yes, but for which object? Display the 'this' pointer in your
'operator()' and compare it to the address of 'Result' variable.
 
V
--
I do not respond to top-posted replies, please don't ask
legalize+jeeves@mail.xmission.com (Richard): Apr 30 05:49PM

[Please do not mail me a copy of your followup]
 
Doug Mika <dougmmika@gmail.com> spake the secret code
>}
 
>the result of Result.Count is 0!!!, WHY isn't it 10????? Afterall, I
>call the oprator() 10 times!
 
The functor is copied around by for_each, so the one it uses is not
the one that you declared locally, it's a copy. This is implied by
the signature of for_each which takes the functor by value. To get
what you want, you have to use a referring wrapper like boost::ref, or
have your functor reference the count held elsewhere:
 
#include<algorithm>
#include<iostream>
#include<vector>
using namespace std;
 
template<typename T>
struct DisplayElementKeepCount{
int &Count;
 
DisplayElementKeepCount(int &Storage):Count(Storage){}
 
void operator()(const T& element){
++Count;
cout<<element<<' ';
}
};
 
int main(int argc, char** argv) {
 
//The Program
vector<int> vecIntegers;
 
for(int nCount=0;nCount<10; ++nCount)
vecIntegers.push_back(nCount);
 
int Count = 0;
DisplayElementKeepCount<int> Result(Count);
 
cout<<"Displaying the vector of integers again"<<endl;
for_each(vecIntegers.begin(),vecIntegers.end(),Result);
cout<<endl<<endl;
 
cout<<"The Result count this time is: "<<Result.Count<<endl;
 
 
return 0;
}
 
--
"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>
Joseph Hesse <joeh@gmail.com>: Apr 30 12:03PM -0500

Hello,
 
In C++ 11, why can't I write:
 
enum class Values = {1, 2, 3};
 
Thank you,
Joe
Joseph Hesse <joeh@gmail.com>: Apr 30 12:05PM -0500

Hello,
 
In C++ 11, why can't I write:
 
enum class Values = {1, 2, 3};
 
I want to treat 1 as a symbol with no meaning.
 
Thank you,
Joe
"Öö Tiib" <ootiib@hot.ee>: Apr 30 10:14AM -0700

On Thursday, 30 April 2015 20:05:17 UTC+3, Joseph Hesse wrote:
 
> In C++ 11, why can't I write:
 
> enum class Values = {1, 2, 3};
 
> I want to treat 1 as a symbol with no meaning.
 
Unfortunately to you C++ language has already given a meaning
to 1. It is integer constant that is often named "one" in English.
You are not allowed to modify that meaning by C++ language rules.
legalize+jeeves@mail.xmission.com (Richard): Apr 30 05:23PM

[Please do not mail me a copy of your followup]
 
Joseph Hesse <joeh@gmail.com> spake the secret code
 
>I want to treat 1 as a symbol with no meaning.
 
1 is not a symbol; it is an integer literal.
 
A symbol is an identifier and must follow the rules for identifiers in C++.
--
"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>
Juha Nieminen <nospam@thanks.invalid>: Apr 30 02:27PM

Consider this:
 
//------------------------------------------------------------------------
template<typename T> void foo(const T&) { std::printf("Generic\n"); }
template<> void foo(const char* const&) { std::printf("const char*\n"); }
 
int main()
{
foo(12);
foo("abc");
const char* str = "abc";
foo(str);
}
//------------------------------------------------------------------------
 
It prints:
 
Generic
Generic
const char*
 
What would be the best way to specialize a template for string literals?
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
simont <s_j_turner@yahoo.co.uk>: Apr 30 08:24AM -0700

On Thursday, April 30, 2015 at 3:27:49 PM UTC+1, Juha Nieminen wrote:
> Generic
> const char*
 
> What would be the best way to specialize a template for string literals?
 
You could just stop trying to pass them by reference, so pointer decay works normally:
 
template<typename T> void foo(T) { std::printf("Generic\n"); }
template<> void foo(const char*) { std::printf("const char*\n"); }
 
or add
 
template<size_t N> void foo(const char (&)[N]) { std::printf("const char [%u]\n", N); }
 
if you want to differentiate between arrays and const char *.
I don't think there's a bulletproof way to distinguish between literals and
copy-initialized arrays, though.
 
Victor Bazarov <v.bazarov@comcast.invalid>: Apr 30 11:25AM -0400

On 4/30/2015 10:27 AM, Juha Nieminen wrote:
> Generic
> const char*
 
> What would be the best way to specialize a template for string literals?
 
String literals are arrays of char, which do decay to pointers but not
for the purpose of type deduction. I think you should be able to make
this work:
 
template<typename T> void foo(const T&) { std::printf("Generic\n"); }
template<int n> void foo(const char(&)[n])
{ std::printf("array of const char\n"); }
 
int main()
{
foo(12);
foo("abc");
const char* str = "abc";
foo(str);
}
 
The problem, of course, is that literals of different lengths the
compiler will instantiate all different 'foo<n>' variations. You could
try to involve inheritance to unify those.
 
V
--
I do not respond to top-posted replies, please don't ask
guinness.tony@gmail.com: Apr 30 08:31AM -0700

On Thursday, 30 April 2015 15:27:49 UTC+1, Juha Nieminen wrote:
> Generic
> const char*
 
> What would be the best way to specialize a template for string literals?
 
template<size_t N>
void foo(const char(&)[N]) { std::printf("const char(&)[]\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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)