Friday, March 4, 2016

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

Nobody <nobody@nowhere.invalid>: Mar 04 10:50AM

On Thu, 03 Mar 2016 14:43:39 +0000, Juha Nieminen wrote:
 
> (Also, he still seems to live in the early 90's in terms of what he
> knows about C++.)
 
He still seems to live in the early 90's in terms of what he "knows"
about C.
 
The Linux kernel isn't actually written in C. It's written in
"C as implemented by gcc with -fno-strict-aliasing".
 
Compiling the Linux kernel with some random perfectly-conforming
C compiler will probably result in a kernel which doesn't actually work.
Ian Collins <ian-news@hotmail.com>: Mar 04 11:56PM +1300

Nobody wrote:
> "C as implemented by gcc with -fno-strict-aliasing".
 
> Compiling the Linux kernel with some random perfectly-conforming
> C compiler will probably result in a kernel which doesn't actually work.
 
Compiling any kernel with some random perfectly-conforming C compiler
will probably result in a kernel which doesn't actually work!
 
I've yet to com across one that isn't tied to specific versions of one
or more compilers.
 
--
Ian Collins
legalize+jeeves@mail.xmission.com (Richard): Mar 04 03:41PM

[Please do not mail me a copy of your followup]
 
slp53@pacbell.net spake the secret code
>all written in C++.
>[...]
>STL generally not useful.
 
I assume you are referring to containers when you say "STL".
I can't see why the algorithms wouldn't be useful in a constrained
environment.
--
"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>
legalize+jeeves@mail.xmission.com (Richard): Mar 04 03:45PM

[Please do not mail me a copy of your followup]
 
David Brown <david.brown@hesbynett.no> spake the secret code
 
>There are no requirements in C++ to use dynamic memory, though it is
>often used "behind the scenes" - you have to be careful and know what
>you are doing if you want to avoid dynamic memory entirely.
 
You're making it sound harder than it is:
 
- don't dynamically allocate memory yourself
- don't use standard library container classes (string, vector, list,
map, etc.)
 
That pretty much covers it.
--
"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>
legalize+jeeves@mail.xmission.com (Richard): Mar 04 03:47PM

[Please do not mail me a copy of your followup]
 
Ian Collins <ian-news@hotmail.com> spake the secret code
 
>Maybe those of us in this field should be making more noise, if only to
>counter some of the ancient FUD that is still doing the rounds!
 
A good blog post backed up by personal experience would very likely
get promoted on the ISO C++ blog.
--
"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>
Wouter van Ooijen <wouter@voti.nl>: Mar 04 05:19PM +0100

Op 04-Mar-16 om 4:41 PM schreef Richard:
 
> I assume you are referring to containers when you say "STL".
> I can't see why the algorithms wouldn't be useful in a constrained
> environment.
 
Algorithms are usefull once you have containser they can operate on. But
most containers relay on the heap...
 
There are initiatives (from the agme and embedded communities - it is
remarkable how their needs match!) to create a set of fixed-maximum-size
containers.
 
Wouter
Wouter van Ooijen <wouter@voti.nl>: Mar 04 05:20PM +0100

Op 04-Mar-16 om 4:47 PM schreef Richard:
>> counter some of the ancient FUD that is still doing the rounds!
 
> A good blog post backed up by personal experience would very likely
> get promoted on the ISO C++ blog.
 
My attempt: http://www.voti.nl/blog/
 
But I am mainly a teacher (not an practicioner).
 
Wouter "Objecst? No thanks!" van Ooijen
Wouter van Ooijen <wouter@voti.nl>: Mar 04 05:22PM +0100

Op 04-Mar-16 om 4:45 PM schreef Richard:
> - don't use standard library container classes (string, vector, list,
> map, etc.)
 
> That pretty much covers it.
 
It does (when you add exceptions, functors, etc.) , but the second point
is a very large one. And undocumented: there is for instance no hard
requirement that sin() doesn't use the heap.
 
Wouter "Objects? No thanks!" van Ooijen
scott@slp53.sl.home (Scott Lurndal): Mar 04 04:51PM


>I assume you are referring to containers when you say "STL".
>I can't see why the algorithms wouldn't be useful in a constrained
>environment.
 
To be fair, one of those projects predated SGI's work on STL, and
the one of the others was developed _at_ SGI at the same time that
the STL work was being done at SGI/MIPS. The first OS predated templates
(was written using Cfront 2.1 starting in 1988/9). The project at SGI mid 90's
operated under serious memory constraints and templates were avoided due to code footprint
issues (partially resolved in more modern compilers).
David Brown <david.brown@hesbynett.no>: Mar 04 05:59PM +0100

On 04/03/16 16:45, Richard wrote:
> - don't use standard library container classes (string, vector, list,
> map, etc.)
 
> That pretty much covers it.
 
You can use /some/ standard container classes, such as std::array. And
I think you could probably use at least some of the other container
classes with customer allocators, placement new, memory pools, etc., to
use their features without a "dangerous" general purpose heap.
 
But are there any other standard library classes or functions that use
dynamic memory without it being obvious? I don't know, but I suspect
that shared_ptr does (even when managing something that is not a "new"
pointer). The standard does not go out of its way to make this sort of
thing easy to see - after all, most C++ users don't need to think about it.
 
(The same applies to C and its standard libraries or any additional
libraries - the only key difference is that the C++ standard libraries
are a good deal bigger than those of C.)
Gareth Owen <gwowen@gmail.com>: Mar 04 05:14PM


> Algorithms are usefull once you have containser they can operate
> on. But most containers relay on the heap...
 
But one could certainly do --
 
std::array<int,16> foo;
/// fill in values
std::sort(foo.begin(),foo.end());
 
which is a lot easier than calling qsort()
 
And while its common to avoid exceptions (and the standard exception
hierarchies cannot be used with no heap) you can throw/catch and use
RAII to unwind exceptional conditions (strongly typed enums make
excellent projectiles).
 
You may also benefit from some specialised library implementation of
std::accumulate() or std::inner_product() that uses SIMD instructions
appropriately.
legalize+jeeves@mail.xmission.com (Richard): Mar 04 05:25PM

[Please do not mail me a copy of your followup]
 
Wouter van Ooijen <wouter@voti.nl> spake the secret code
>> environment.
 
>Algorithms are usefull once you have containser they can operate on. But
>most containers relay on the heap...
 
Algorithms work on anything that supports the concepts of iterators.
That includes fixed-size arrays or any other fixed-size container you
might want to create.
--
"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>
legalize+jeeves@mail.xmission.com (Richard): Mar 04 05:26PM

[Please do not mail me a copy of your followup]
 
Gareth Owen <gwowen@gmail.com> spake the secret code
 
>std::array<int,16> foo;
>/// fill in values
>std::sort(foo.begin(),foo.end());
 
or:
 
int foo[16];
// fill in values
std::sort(std::begin(foo), std::end(foo));
 
--
"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>
legalize+jeeves@mail.xmission.com (Richard): Mar 04 05:31PM

[Please do not mail me a copy of your followup]
 
Wouter van Ooijen <wouter@voti.nl> spake the secret code
>> map, etc.)
 
>> That pretty much covers it.
 
>It does (when you add exceptions, functors, etc.)
 
I'm talking about his point about avoiding dynamic memory allocation.
Functors and exceptions don't have to do with dynamic memory
allocation unless you start writing calls to new yourself. Since by
definition you're trying to avoid using the heap, then it would be
stupid to write functors that call new. I have to assume some basic
intelligence on behalf of the programmer that doesn't want to use the
heap, so I find it pointless to act as if the programmer that doesn't
want to use the heap is too stupid to understand that writing 'new'
means using the heap.
 
> but the second point is a very large one.
 
If you'r in a constrained environment where you can't use the heap,
then it isn't such a big deal. You're either using statically
allocated data structures or you're using the stack. C style arrays
can live in both places just fine.
 
>And undocumented: there is for instance no hard
>requirement that sin() doesn't use the heap.
 
Sorry, this is either a pointless exercise in pedantry or it is a
straw man argument.
--
"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>
legalize+jeeves@mail.xmission.com (Richard): Mar 04 05:34PM

[Please do not mail me a copy of your followup]
 
David Brown <david.brown@hesbynett.no> spake the secret code
>I think you could probably use at least some of the other container
>classes with customer allocators, placement new, memory pools, etc., to
>use their features without a "dangerous" general purpose heap.
 
Yes, you could do that. However, it is highly likely that the
resulting code would be harder to understand than just using a
fixed-size array. It isn't a question of what is *possible*, it is a
question of how would you do things in practice under a constrained
environment where using the heap is out of the question. Avoiding being
"clever" here is probably the best advice.
 
>But are there any other standard library classes or functions that use
>dynamic memory without it being obvious? I don't know, but I suspect
>that shared_ptr does [...]
 
Again -- shared_ptr is for using the heap. Why would you be
attempting to use shared_ptr when you don't want to use the heap?
 
Seriously folks, let's get real in this discussion instead of
hypothetical crazy shit like "sin(double)" allocating memory from the
heap or insisting on using shared_ptr<> when we don't want to use the
heap.
--
"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>
legalize+jeeves@mail.xmission.com (Richard): Mar 04 05:37PM

[Please do not mail me a copy of your followup]
 
slp53@pacbell.net spake the secret code
>operated under serious memory constraints and templates were avoided due
>to code footprint
>issues (partially resolved in more modern compilers).
 
Oh yeah, I remember Cfront on SGIs :-).
 
In ancient times (aka the late 1980s/early 1990s), C++ compilers
weren't as efficient at generating code of small size and/or from
templates.
 
However, I don't think that's relevant to the discussion today because
things have changed significantly.
--
"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>
Ramine <ramine@1.1>: Mar 04 12:21PM -0800

On 3/2/2016 4:34 PM, Ramine wrote:
> queuing theory does answer the question of what is the waiting time
> of the internet user of the website when the waiting time is dependant
> on the arrival rate that must not go beyond the Kned of the queues, but
 
I correct: Beyond the Knees of the queues.
 
bleachbot <bleachbot@httrack.com>: Mar 04 06:18PM +0100

Robve <engelen@cs.fsu.edu>: Mar 04 07:18AM -0600

Have you tried the JSON and JSONPath implementation at http://www.genivia.com/doc/xml-rpc-json/html that converts JSONPath queries to C++ code? Works quite well and is faster than a library and certainly faster than converting to XML.
 
Robve
--
Christopher Pisz <nospam@notanaddress.com>: Mar 04 09:19AM -0600

On 3/4/2016 7:18 AM, Robve wrote:
 
> Robve
> --
 
I found GSoap to be a pain in my buttocks and have since switched to
using the WinAPI for web services, since I am targeting windows only.
 
Since the oringinal post I made, I have worked out how to implement my
own json path, since the libraries I was using don't offer it. Twas
quite the challenge.
 
 
--
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
---
Ian Collins <ian-news@hotmail.com>: Mar 04 11:54PM +1300

This one bugs me:
 
A parameter for a constexpr function must be a constant expression but..
 
You can't use static_assert to check the value in the function. Defect
in the standard?
 
constexpr unsigned f( unsigned n )
{
static_assert( n < 1000, "Ops" ); return 0;
}
 
g++ -std=c++17 x.cc
 
x.cc:26:38: error: 'n' is not a constant expression
 
--
Ian Collins
David Brown <david.brown@hesbynett.no>: Mar 04 01:10PM +0100

On 04/03/16 11:54, Ian Collins wrote:
> }
 
> g++ -std=c++17 x.cc
 
> x.cc:26:38: error: 'n' is not a constant expression
 
The function f() can be called with n that is not known at compile-time,
in which case the static_assert cannot be evaluated.
 
I suspect the best you can do is something like:
 
extern void __attribute__((error("Compile time check failed")))
compileTimeCheckFailed(void);
 
constexpr unsigned f(unsigned n) {
if (__builtin_constant_p(n)) {
if (!(n < 1000)) {
compileTimeCheckFailed();
}
} else {
if (!(n < 1000)) {
throw runTimeCheckFailed;
}
}
return 0;
}
"Öö Tiib" <ootiib@hot.ee>: Mar 04 06:02AM -0800

On Friday, 4 March 2016 14:10:50 UTC+2, David Brown wrote:
> }
> return 0;
> }
 
Calling non-constexpr from constexpr function (like
that 'compileTimeCheckFailed') and/or throwing from
constexpr function without using ?: operator should not
compile AFAIK. Maybe something like that:
 
constexpr int f(int n)
{
(n < 1000) ? true : throw 42;
// ... do what you need
return 0;
}
 
int main(int argc, char **argv)
{
constexpr int i = 5000;
int k = 6000;
const int m = 6;
const int n = argc;

constexpr int a = f(i); // <- compiler error
const int b = f(k); // <- throws 42
constexpr int c = f(m); // works OK
const int d = f(n); // works OK
}
Ian Collins <ian-news@hotmail.com>: Feb 23 09:19AM +1300

Mr Flibble wrote:
 
>> How is your considered critique coming along?
 
> I do hope you are writing that whilst saying it out loud in Stewie
> Griffin's voice.
 
Who?
 
--
Ian Collins
Wouter van Ooijen <wouter@voti.nl>: Feb 22 09:18PM +0100

Op 22-Feb-16 om 8:44 PM schreef Mr Flibble:
>> and how you can introduce new functionality under strict TDD rules
>> because this is the part that most people get wrong when they try TDD.
 
> TDD and classic refactoring are in conflict.
 
Explaining the conflict would be more usefull than just asserting that
there is a conflict.
 
And why the 'classic'? You see to imply that TDD is not in conflict with
some other type of refactoring?
 
> TDD is bollocks pure and simple.
 
Again, providing details is more usefull than a simple assertion. And as
a lengthy discussion has shown me, it is usefull to state what you think
TDD is exactly. I would agree with you when TDD == (the three rules
without refactoring), but that seems to be a strawman.
 
Wouter van Ooijen
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)