Thursday, January 28, 2016

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

Paavo Helde <myfirstname@osa.pri.ee>: Jan 28 07:31PM +0200

On 28.01.2016 18:43, Scott Lurndal wrote:
 
> On any modern system, it's not really significantly slower (at least on linux and
> unix systems) because the common header files will end up cached in memory after
> the first couple of compiles.
 
I believe the speed depends very much on how many templates these common
header files contain.
 
Cheers
Paavo
Ian Collins <ian-news@hotmail.com>: Jan 29 08:03AM +1300

Paavo Helde wrote:
> files can be significantly slower than recompiling a couple of large
> files (especially if precompiled header support is not working well for
> any reason).
 
I agree with Scott. Being able to perform parallel or distributed
builds is a big win for more smaller files.
 
--
Ian Collins
4ndre4 <4ndre4@4ndre4.com.invalid>: Jan 28 07:15PM

On 28/01/2016 11:21, JiiPee wrote:
[...]
> I guess its faster to compile if there are a lot of small files as only
> that file needs to be compiled if changed?
 
One class per file. That's the principle I adopt, borrowed from other
languages that I use (Java in primis). I don't really care about the
number of files in a project. I can always organize them in different
folders, grouped by functionality. Concurrency also leads to less
conflicts/dependencies between developers, if the code is more fragmented.
 
--
4ndre4
"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense." (E. Dijkstra)
4ndre4 <4ndre4@4ndre4.com.invalid>: Jan 28 07:15PM

On 28/01/2016 11:21, JiiPee wrote:
 
[...
> I guess its faster to compile if there are a lot of small files as only
> that file needs to be compiled if changed?
 
...also, don't forget that for unit testing reasons, having one class
per file is a convenient solution.
 
--
4ndre4
"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense." (E. Dijkstra)
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 28 08:01PM

On Thu, 2016-01-28, JiiPee wrote:
>> Generally, I have one header file and one source file per class.
 
> Even if the classes are small and there are a lot of classes? say you
> have 30 small classes, would you still put them to a separate files?
 
It depends on what they do. If they are closely related, perhaps
siblings, perhaps they need the same helper functions which noone else
needs, perhaps they will change together ... then I'll probably put
them in one .h file and one .cc file.
 
But small size is not enough reason.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 28 08:40PM

On Thu, 2016-01-28, 4ndre4 wrote:
>> that file needs to be compiled if changed?
 
> ...also, don't forget that for unit testing reasons, having one class
> per file is a convenient solution.
 
Why? I don't see any connection or limitation there. Seems pretty
orthogonal to me.
 
The only thing would be, if a source file containing test cases starts
with a '#include <foo.h>', you'd expect the tests to cover all of the
functionality exposed via foo.h. But if the classes (and functions)
are so closely related that I want them all in foo.h, I probably want
to keep the tests together, too ...
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Ian Collins <ian-news@hotmail.com>: Jan 29 09:50AM +1300

Jorgen Grahn wrote:
>> per file is a convenient solution.
 
> Why? I don't see any connection or limitation there. Seems pretty
> orthogonal to me.
 
Mocking.
 
If you are testing class A which depends on class B you don't want the
definition of A an B in the same file.
 
--
Ian Collins
scott@slp53.sl.home (Scott Lurndal): Jan 28 09:03PM

>> any reason).
 
>I agree with Scott. Being able to perform parallel or distributed
>builds is a big win for more smaller files.
 
A very valid point, if your tools support parallel builds.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 28 10:22PM

On Thu, 2016-01-28, Ian Collins wrote:
 
> Mocking.
 
> If you are testing class A which depends on class B you don't want the
> definition of A an B in the same file.
 
That could be a reason in some cases I guess, although for me classes
in the same file tend to be siblings with similarities rather than
dependencies.
 
I still would like to see "4ndre4"'s argument, too.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Rosario19 <Ros@invalid.invalid>: Jan 28 06:35AM +0100

On Wed, 27 Jan 2016 14:16:23 -0600, Christopher Pisz wrote:
 
>is making some bold sweeping claims about C++ and C#, which I have to
>disagree with. It's lighthearted and for fun. I wonder what others say
>on the topic.
 
i never had find a problem where it is need "virtual" until now
Vir Campestris <vir.campestris@invalid.invalid>: Jan 28 09:17PM

On 28/01/2016 13:27, Zaphod Beeblebrox wrote:
 
> [...]
>> beautifully written code. :) easy to read...
 
> A code that doesn't do anything is always easy to read :D
 
Have you never seen the Obfuscated C contest?
 
Andy
4ndre4 <4ndre4@4ndre4.com.invalid>: Jan 28 10:06PM

On 28/01/2016 21:17, Vir Campestris wrote:
 
[...]
> Have you never seen the Obfuscated C contest?
 
The difference is that in the Obfuscated C contest, the code does
something in an incomprehensible way. My code does not really do
anything :)
 
--
4ndre4
"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense." (E. Dijkstra)
Lynn McGuire <lmc@winsim.com>: Jan 28 02:56PM -0600

On 1/28/2016 2:48 PM, Stefan Ram wrote:
> which is usually called just »Java«.
 
> So, in »in C++« »in« does not mean the same as
> in »in Java«.
 
You are just illustrating my argument that C++ needs a standard graphics (2D and 3D) library and a standard user interface toolkit.
 
Lynn
"Öö Tiib" <ootiib@hot.ee>: Jan 28 01:30PM -0800

On Thursday, 28 January 2016 22:57:02 UTC+2, Lynn McGuire wrote:
 
> > So, in »in C++« »in« does not mean the same as
> > in »in Java«.
 
> You are just illustrating my argument that C++ needs a standard graphics (2D and 3D) library and a standard user interface toolkit.
 
That has to be separate standard since "graphics" means few LEDs
for lot of devices where C++ runs.
 
Should C++ committee standardize something like OpenGL API or
like Qt or like Unreal Engine?
Lynn McGuire <lmc@winsim.com>: Jan 28 03:38PM -0600

On 1/28/2016 3:30 PM, Öö Tiib wrote:
> for lot of devices where C++ runs.
 
> Should C++ committee standardize something like OpenGL API or
> like Qt or like Unreal Engine?
 
Not sure what you mean by "few LEDs" ?
 
Or a uitk like wxWidgets.
 
A standard in both of these items would solve a lot of problems.
 
Lynn
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 28 10:47PM +0100

On 1/28/2016 10:30 PM, Öö Tiib wrote:
 
> Should C++ committee standardize something like OpenGL API or like Qt
> or like Unreal Engine?
 
There is a proposal, with Herb Sutter as co-author, for adding an
essentially cleaned up version of Cairo to the standard library.
 
<url: https://isocpp.org/blog/2014/01/n3888>
 
It would not surprise if that's what Microsoft used to create the
Minecraft game in C++, considering that Herb is chief architect of
Visual C++.
 
And if so, then it was probably done to verify that the proposal is
complete in a real-world sense, that it can actually be used for and is
sufficient for something non-trivial.
 
 
Cheers & hth.,
 
- Alf
ram@zedat.fu-berlin.de (Stefan Ram): Jan 28 08:48PM

>new Minecraft Education Edition - written in C++
 
One can write Minecraft in Java.
 
One can't write it in C++, except when one would use
non-standard libraries.
 
But with Java one can write it
with only the standard library »Java SE«
which is usually called just »Java«.
 
So, in »in C++« »in« does not mean the same as
in »in Java«.
Lynn McGuire <lmc@winsim.com>: Jan 28 02:35PM -0600

"Microsoft's new Minecraft Education Edition - written in C++ - will outrun the Java version"
http://www.zdnet.com/article/minecrafts-new-education-edition-written-in-c-will-outrun-the-java-version/
 
Lynn
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 28 07:24PM +0100

Not sure whether this code is formally correct (it doesn't compile with
g++):
 
 
<code>
#include <stdio.h>
 
template< class... Args >
auto format_for( Args... args, int last_arg )
-> char const*
{
// using Specifier = char const [3];
// static Specifier const s[] = { {'%', 'f'+(0*args), ' '}...,
{'%', 'f', 0} };
return reinterpret_cast<char const*>( "" );
}
 
auto main() -> int
{
printf( "'%s'\n", format_for( 5, 2, 1 ) );
}
</code>
 
 
Anyway it crashes Visual C++ 2015 update 1:
 
 
<example>
C:\my\forums\so\081> cl printf.cpp /Feb
printf.cpp
printf.cpp(14): fatal error C1001: An internal error has occurred in the
compiler.
(compiler file 'f:\dd\vctools\compiler\cxxfe\sl\p1\cxx\dymto.c', line 6771)
To work around this problem, try simplifying or changing the program
near the locations listed above.
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
 
C:\my\forums\so\081> g++ printf.cpp
printf.cpp: In function 'int main()':
printf.cpp:14:43: error: no matching function for call to
'format_for(int, int, int)'
printf( "'%s'\n", format_for( 5, 2, 1 ) );
^
printf.cpp:4:6: note: candidate: template<class ... Args> const char*
format_for(Args ..., int)
auto format_for( Args... args, int last_arg )
^
printf.cpp:4:6: note: template argument deduction/substitution failed:
printf.cpp:14:43: note: candidate expects 1 argument, 3 provided
printf( "'%s'\n", format_for( 5, 2, 1 ) );
^
</example>
 
 
I've posted an SO question about it, and I will probably post a bug
report to Microsoft Connect if or when I learn what to expect as correct
behavior, or after waiting some resonable time for that.
 
 
Cheers,
 
- Alf
Ian Collins <ian-news@hotmail.com>: Jan 29 08:10AM +1300

Alf P. Steinbach wrote:
 
> template< class... Args >
> auto format_for( Args... args, int last_arg )
> -> char const*
 
I thought the parameter pack had to be the last parameter?
 
--
Ian Collins
"Öö Tiib" <ootiib@hot.ee>: Jan 28 11:31AM -0800

On Thursday, 28 January 2016 21:10:54 UTC+2, Ian Collins wrote:
> > auto format_for( Args... args, int last_arg )
> > -> char const*
 
> I thought the parameter pack had to be the last parameter?
 
Yes, if you want it to be deduced by compiler (that Alph's code attempts).
 
[temp.deduct.type]/p5:
The non-deduced contexts are:
[...]
* A function parameter pack that does not occur at the end of the parameter-declaration-list.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 28 08:45PM +0100

On 1/28/2016 8:31 PM, Öö Tiib wrote:
> The non-deduced contexts are:
> [...]
> * A function parameter pack that does not occur at the end of the parameter-declaration-list.
 
Yes, thanks.
 
That's also what I learned on SO now.
 
Funny, I've been using variadic templates but evidently, by chance,
always with the parameter pack at the end, or explicitly specified.
 
 
Cheers!,
 
- Alf
scott@slp53.sl.home (Scott Lurndal): Jan 28 01:57PM


>Two simple rules:
>i) use an unsigned type when dealing with unsigned values
>ii) there are (almost) no unsigned values
 
I must disagree with (ii). Most of what I do[*] operates on
unsigned values.
 
[*] Operating systems, Hypervisors, SoC simulation - all in C++.
Ian Collins <ian-news@hotmail.com>: Jan 28 10:17PM +1300

> argc is an artifact of ancient lazier times: if we were to reinvent
> main today we would do it differently.
 
Three times differently :)
 
Too many sausages?
 
--
Ian Collins
Bo Persson <bop@gmb.dk>: Jan 28 02:24PM +0100

On 2016-01-27 22:50, Mr Flibble wrote:
 
> ii) and iii) are in conflict as you cannot eat a negative number of
> sausages.
 
> /Flibble
 
What about
 
unsigned yesterdays_sausages = 6;
unsigned todays_sausages = 5;
 
unsigned difference = todays_sausages - yesterdays_sausages;
 
 
Doesn't really work, does it?
 
 
 
Bo Persson
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)