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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)