Thursday, January 5, 2017

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

Daniel <danielaparker@gmail.com>: Jan 05 07:29AM -0800

On Wednesday, January 4, 2017 at 1:39:33 PM UTC-5, gwowen wrote:
 
> Yup. In this regard, Flibble was entirely correct.
 
You know, you could be setting a dangerous precedent by conceding something on
comp.lang.c++. Where might it all end? Rick conceding that Flibble has a point
about the lack of evidence for an historical jesus? Jerry conceding that voltage
can exist without current? Flibble conceding that sausages are bad for you? Brian
conceding that ::std is silly?
 
Better to just brazen it out, like most of us here.
 
Best regards,
Daniel
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 05 09:21PM

On 05/01/2017 15:29, Daniel wrote:
> can exist without current? Flibble conceding that sausages are bad for you? Brian
> conceding that ::std is silly?
 
> Better to just brazen it out, like most of us here.
 
Sausages are bad for me? Oh noes! Luckily I have just started dieting so
I won't be eating many sausages.
 
/Flibble
moroney@world.std.spaamtrap.com (Michael Moroney): Jan 05 03:34AM


>All the code that I posted here has been _trashed already.
 
Yay! Relfie did something right for once!
Jeff-Relf.Me <@.>: Jan 04 10:26PM -0800

Anonymous <anonymous@invalid.tld>: Jan 05 08:18AM


> My guide:
 
> " Dynamic Programming | Set 4 (Longest Common Subsequence) "
> http://www.geeksforgeeks.org/dynamic-programming-set-4-longest-common-subsequence/
 
Jeff, just out of curiosity: did you ever tried programming in Lisp or Forth?
Peter Köhlmann <peter-koehlmann@t-online.de>: Jan 05 09:24AM +0100

Anonymous wrote:
 
>> http://www.geeksforgeeks.org/dynamic-programming-set-4-longest-common-subsequence/
 
> Jeff, just out of curiosity: did you ever tried programming in Lisp or
> Forth?
 
Relf programmes in "Shit". And naturally writes shitty code
Jeff-Relf.Me <@.>: Jan 05 01:08AM -0800

jmfbahciv <See.above@aol.com>: Jan 05 02:08PM

Scott Lurndal wrote:
> handle in a reasonable amount of time given memory constraints.
 
> Compact (dense) code was more the rule than the exception in those
> days.
 
Another reason is having been on a firefight, fixing the installation's
code so it can run, then carrying back the changes and taking 2 months
to figure out why the new fixes worked. However, the end result is
"if it ain't broke, don't fix it" so the impenetrable code stays
with lots of comments including "thar be dragons".
 
/BAH
jmfbahciv <See.above@aol.com>: Jan 05 02:08PM

Jeff-Relf.Me wrote:
 
>> Compact (dense) code was more the rule
>> than the exception in those days.
 
> My C++ is dense, 236 columns wide, and I'm running:
 
Oh, goodfuckinggrief. That's not the definition of dense code.
It's called human-unreadable code. White space helps the
maintainer and gives one margins to scribble notes.
 
Now everything you wrote about this subject makes sense.
 
[embarassed emotiocn here for not thinking of his definition]
 
You are a newbie.
 
/BAH
Vir Campestris <vir.campestris@invalid.invalid>: Jan 05 09:09PM

On 04/01/2017 18:17, Jeff-Relf.Me wrote:
> When I see sparse code, with lots of whitespace and comments,
> I _immediately know the programmer is struggling.
 
If whitespace is bad how come APL is unreadable?
 
Andy
legalize+jeeves@mail.xmission.com (Richard): Jan 05 09:19PM

[Please do not mail me a copy of your followup]
 
Vir Campestris <vir.campestris@invalid.invalid> spake the secret code
>> When I see sparse code, with lots of whitespace and comments,
>> I _immediately know the programmer is struggling.
 
>If whitespace is bad how come APL is unreadable?
 
APL is unreadable in the sense that Chinese or Arabic is unreadable to
someone who only knows latin/european languages. It uses unfamiliar
symbols and it reads right to left. Sometimes Chinese is typeset top
to bottom and sometimes (particularly in modern text) it is typeset
left to right. These things make it very foreign to a new reader, but
once oriented on the symbols (APL is much easier to grasp than Chinese
in this regard!) and the proper direction in which to read the code,
it's not that bad.
 
The bigger mind-twist for a conventional procedurally oriented thinker
is the switch to functional oriented thinking.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 05 01:19PM -0800

Many people think Christianity is a religion. It is not. For many,
that's all it will ever be. But for those who are saved, it is not
a religion. It is the new life brought to bear upon the sinner, and
to such an extent that their entire world is changed.
 
Listen to this whole sermon. He teaches about spiritual battles,
about the war of the flesh and spirit for the soul, and how he was
transformed when coming to the Lord asking forgiveness for his sin.
 
An excellent sermon:
 
"How to Discern Spirits"
https://www.youtube.com/watch?v=CEomxwZZUbk
 
It's logical:
 
"He that hath the Son hath life. He that hath not the Son
hath not life."
 
Best regards,
Rick C. Hodgin
gdotone@gmail.com: Jan 05 12:37PM -0800

given three files
 
GradeBook.h
GradeBook.cpp
fig03_15.cpp -- which contains main --
 
how do i compile this to produce and object file,
an executable, with the name fig03_15?
 
-----------------------------
 
i tried:
 
clang++ -o fig03_13 GradeBook.h GradeBook.cpp fig03_13.cpp
 
clang++ GradeBook.h GradeBook.cpp fig03_13.cpp -o fig03_13
 
i get:
 
clang: error: cannot specify -o when generating multiple output files
 
 
------------------------------
also:
 
clang++ GradeBook.h GradeBook.cpp fig03_13.cpp
 
produces an a.out that works and it produces a file named
GradeBook.h.gch
 
 
Thanks everyone,
 
g.
Vir Campestris <vir.campestris@invalid.invalid>: Jan 05 09:05PM


> clang++ GradeBook.h GradeBook.cpp fig03_13.cpp
 
> produces an a.out that works and it produces a file named
> GradeBook.h.gch
 
Your teacher should have explained.
 
clang++ -o fig03_13 GradeBook.cpp fig03_13.cpp
clang++ GradeBook.cpp fig03_13.cpp -o fig03_13
 
ought to do it. That's your lines, but without the .h file.
 
Inside the cpp files you'll find a line
#include "GradeBook.h"
which is how it gets used.
 
Andy
gdotone@gmail.com: Jan 05 01:10PM -0800

On Thursday, January 5, 2017 at 4:05:25 PM UTC-5, Vir Campestris wrote:
> #include "GradeBook.h"
> which is how it gets used.
 
> Andy
 
Thanks Andy.
ram@zedat.fu-berlin.de (Stefan Ram): Jan 01 07:23PM

>I still had to answer to this.
>MFC uses message maps, which substantially work, but they are buried
>within MFC, so they come with all of its burden (which Alf summarized well).
 
Since I asked this, I feel obliged to answer something,
but I can add little to what you and others already wrote.
 
One idea would be to try to clearly split the program into
two parts: The majority of the program is written in modern
C++ and excludes the topic of message cracking.
 
Then there is a separatedly compiled part that only deals
with the topic of message cracking and calling into the
interface of the rest of the program. This part is allowed
to use any "dirty tricks" that make the life of the programmer
easier (wizards, preprocessors, MFC, obsolete programming
style).
 
So, the idea is: When there has to be some "dirt" in a
program, it should be isolated from the rest of the program.
ram@zedat.fu-berlin.de (Stefan Ram): Jan 05 08:45PM

>clang++ -o fig03_13 GradeBook.h GradeBook.cpp fig03_13.cpp
 
I assume that header files (like »GradeBook.h«) are meant to
be included in the source files, but to /not/ be specified on
the command line of the compiler call.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 05 08:49AM

On Wed, 2017-01-04, Dombo wrote:
> Op 04-Jan-17 om 18:02 schreef Jorgen Grahn:
...
> don't see what would make it hard to integrate it with a build system,
> or why it would prefer a particular build system. As far as I can tell
> it is pretty much build system agnostic.
 
We (the project I was in) may have overlooked something ... as I
remember it, we ended up having to build it as part of the project,
rather than installing it as a library. And it wasn't very clear
/how/ to build it using Make; they shipped with CMake recipes.
 
> Of the C++ test frameworks I've had the (dis)pleasure to work with,
> including some "homebrew" and Boost, the Google Test framework is
> certainly not the worst.
 
My impression too.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Ian Collins <ian-news@hotmail.com>: Jan 05 10:12PM +1300

On 01/ 5/17 09:49 PM, Jorgen Grahn wrote:
> remember it, we ended up having to build it as part of the project,
> rather than installing it as a library. And it wasn't very clear
> /how/ to build it using Make; they shipped with CMake recipes.
 
Usually projects just build gtest-all.cc :)
 
--
Ian
Daniel <danielaparker@gmail.com>: Jan 05 07:31AM -0800

On Tuesday, January 3, 2017 at 1:36:43 PM UTC-5, Cholo Lennon wrote:
 
> Boost.Test can be used without compiling it and as a subset of the whole
> Boost
 
Thanks, I'll look into that.
 
Daniel
legalize+jeeves@mail.xmission.com (Richard): Jan 05 08:22PM

[Please do not mail me a copy of your followup]
 
Daniel <danielaparker@gmail.com> spake the secret code
 
>It's proving too difficult if not impossible to set up continuous
>integration builds for all the environments and compilers supported that
>link to boost [...]
 
What exactly is the difficulty?
 
When I worked at Fusion-io we supported a fairly large number of linux
targets, but most of these end up using the same compiler so the build
matrix isn't exactly one-to-one with platform. In the end, it
amounted to 3 variants: MacOS, linux and Windows. We built the
necessary dependencies for our build (including boost) and created
pullable packages for them from the build environment. So the build
environment just pulled down a prebuilt binary to link test
exectuables against.
 
This has the advantage that you don't spend CI build time rebuilding
dependencies that you aren't changing and it decouples the build
system used by the dependencies from the build system of the
application.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Daniel <danielaparker@gmail.com>: Jan 05 07:48AM -0800

Is there a rationale for why std::back_insert_iterator (and some other output
iterators) declare iterator_traits<It>::value_type,
iterator_traits<It>::difference_type, iterator_traits<It>::pointer, and
iterator_traits<It>::reference to be void, as opposed to picking them up
from the container type?
 
The context for the question is implementing a template function similar to
std::copy or std::transform, but with different implementations depending on
properties of the value_type written to.
 
Thanks,
Daniel
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 05 01:13AM

On Wed, 4 Jan 2017 17:18:06 -0500
> within the initializer list, even though _buf is instantiated within
> the constructor. I imagine there is something somewhere in the
> standard which says I am wrong.
 
If is ODR-used, then it must be defined. In addition, in your usage it
also needs to be initialized before first use. See below.

> init() : _ref(new (_buf) T()) {
> _buf = new char[sizeof(T)];
> }

The first time you call get_ref(), you use placement new in the member
initializer list before the block of memory pointed to by 'buf' has
been allocated in the constructor. Surely you get a segfault with gcc
(which you say makes the mistake of trying to compile and link it)?
 
(Apart from that, the code cannot possibly serve any useful purpose
because every time print_it() is called after that first time, a 'T'
object will be constructed in the formerly allocated memory, but then
immediately be replaced by reallocated memory in the constructor
which will have no object constructed in it. In consequence, you have
a memory leak, and you also have a second round of undefined behavior by
the call to the Foo::print_it() non-static method on a Foo object which
does not exist.)
 
bitrex <bitrex@de.lete.earthlink.net>: Jan 05 01:41AM -0500

On 01/04/2017 08:13 PM, Chris Vine wrote:
 
> initializer list before the block of memory pointed to by 'buf' has
> been allocated in the constructor. Surely you get a segfault with gcc
> (which you say makes the mistake of trying to compile and link it)?
 
It does appear to compile under later versions of GCC on Compiler
Explorer with no errors, and even produces an assembly output:
 
https://godbolt.org/g/u8yPUZ
 
Clang produces a warning about the issue you mention.
 
On my home PC using GCC 5.4 it fails with a linker error.
 
> a memory leak, and you also have a second round of undefined behavior by
> the call to the Foo::print_it() non-static method on a Foo object which
> does not exist.)
 
Why would the the "T" object be constructed repeatedly? In the "get_ref"
function the struct "init" is only instantiated once and is declared
with static storage duration.
 
This compiles under GCC and Clang with no errors or warnings, runs OK
and seems to be what I was getting at:
 
#include <cstddef>
#include <iostream>
#include <new>
 
struct Foo
{
Foo() = default;
void print_it()
{
std::cout << "hey hey hi" << std::endl;
}
};
 
template <typename T>
class Bar
{
public:
Bar() = default;
~Bar() = default;
 
void print_it()
{
get_ref().print_it();
}
 
private:
static char *const buf_init()
{
static char* _buf = new char[sizeof(T)];
return _buf;
}
 
static T& get_ref()
{
struct init
{
public:
init() : _ref(new (buf_init()) T())
{
std::cout << "I was only called once." << std::endl;
}
 
operator T*() const
{
return _ref;
}
 
private:
T *const _ref;
};
 
static init _init;
return *_init;
}
};
 
int main ()
{
auto b = Bar<Foo>();
for (size_t i = 0; i < 10; ++i) { b.print_it(); }
return 0;
}
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 05 11:09AM

On Thu, 5 Jan 2017 01:41:46 -0500
 
> Why would the the "T" object be constructed repeatedly? In the
> "get_ref" function the struct "init" is only instantiated once and is
> declared with static storage duration.
 
Yes, you are right about that.
 
> for (size_t i = 0; i < 10; ++i) { b.print_it(); }
> return 0;
> }
 
Yes that looks OK. Function statics avoid both the issues that you ran
into (the absence of a definition and use before initialization).
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)