Wednesday, January 4, 2017

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

bitrex <bitrex@de.lete.earthlink.net>: Jan 04 05:18PM -0500

The following snippet compiles with no warnings under GCC on Compiler
Explorer, while Clang warns on the line "init() : _ref(new (_buf) T())"
that "warning: instantiation of variable 'Bar<Foo>::_buf' required here,
but no definition is available [-Wundefined-var-template]"
 
When attempting to run the code on Ideone it fails with a linker error
about an undefined reference on the same line.
 
Is there a way to make a hack like this work "properly", i.e. have
get_ref() return a reference a templated class where "placement new" has
been used to instantiate the class on a static buffer, without resorting
to initializing the static field for the buffer outside the class
definition?
 
I would have thought that since _buf had static storage duration that I
could use placement new to initialize the const-qualified pointer 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.
 
#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* _buf;
 
static T& get_ref() {
struct init {
public:
init() : _ref(new (_buf) T()) {
_buf = new char[sizeof(T)];
}
 
operator T*() const {return _ref; }
 
private:
T *const _ref;
};
 
static init _init;
return *_init;
}
};
 
int main ()
{
auto b = Bar<Foo>();
b.print_it();
return 0;
}
Ian Collins <ian-news@hotmail.com>: Jan 05 11:27AM +1300

On 01/ 5/17 11:18 AM, bitrex wrote:
> been used to instantiate the class on a static buffer, without resorting
> to initializing the static field for the buffer outside the class
> definition?
 
I don't think there is, Bar<T>::_buf still has to be defined, whether
placement new or regular new is used.
 
Don't forget that static data members aren't part of class instances.
 
--
Ian
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 04 05:02PM

On Tue, 2017-01-03, Daniel wrote:
> https://github.com/philsquared/Catch, but it tries to be too clever,
> resulting in too many issues.
 
> Any suggestions?
 
I'm always willing to plug my own: https://github.com/kjgrahn/orchis
But it's very minimal, and you can tell I don't like the official unit
test ideology very much.
 
I've used Google Test too, but I'm not very impressed. I remember them
making it hard to integrate with the build system, unless you choose
the build system /they/ like.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Ian Collins <ian-news@hotmail.com>: Jan 05 08:37AM +1300

On 01/ 5/17 06:02 AM, Jorgen Grahn wrote:
 
> I've used Google Test too, but I'm not very impressed. I remember them
> making it hard to integrate with the build system, unless you choose
> the build system /they/ like.
 
That's a non-issue these days.
 
--
Ian
Dombo <dombo@disposable.invalid>: Jan 04 09:34PM +0100

Op 04-Jan-17 om 18:02 schreef Jorgen Grahn:
 
> I've used Google Test too, but I'm not very impressed. I remember them
> making it hard to integrate with the build system, unless you choose
> the build system /they/ like.
 
I've been using the Google Test framework for a year now, and frankly I
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.
 
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. But it isn't that great either when compared to
the test frameworks for other programming languages like C#. Though the
Google test framework has a reasonable amount of documentation, it isn't
all that well organized; I find myself googling a lot for the
information I need rather than navigating through the documentation. I
also find it somewhat lacking in the extendability department. But other
than that it (mostly) does the job.
Juha Nieminen <nospam@thanks.invalid>: Jan 04 07:04AM

>> *facepalm* Analysing algorithms is a discipline of mathematics.
 
> No, it isn't; it is a discipline of computer science and algorithmics.
 
That's like saying "that's not physics, it's astronomy".
 
> Wrong. std::list::sort *is* required to be stable.
 
Who was talking about std::list? The discussion was about linked lists.
Juha Nieminen <nospam@thanks.invalid>: Jan 04 07:07AM

> keep track of the middle element (in each of the two partitions)
> because you don't know ahead of time how many elements will be in
> each partition.
 
Every second time you add to the list, advance the "middle" iterator.
 
Sure, that adds a bit to the constant factor of the complexity, but
on the other hand it may be worth it, if the median-of-three pivot
choice compensated for it on average.
Daniel <danielaparker@gmail.com>: Jan 04 07:18AM -0800

On Wednesday, January 4, 2017 at 2:04:52 AM UTC-5, Juha Nieminen wrote:
> Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote:
 
> > Wrong. std::list::sort *is* required to be stable.
 
> Who was talking about std::list? The discussion was about linked lists.
 
Well, Gareth Owen wrote "std::list::sort is *not* required to be stable", and Mr
Flibble replied correctly that it is. That was in the text that you snipped.
 
Regards,
Daniel
Gareth Owen <gwowen@gmail.com>: Jan 04 06:39PM


> Well, Gareth Owen wrote "std::list::sort is *not* required to be
> stable", and Mr Flibble replied correctly that it is. That was in the
> text that you snipped.
 
Yup. In this regard, Flibble was entirely correct.
scott@slp53.sl.home (Scott Lurndal): Jan 04 01:33PM


>> Ye gods!
 
>He doesn't work for anybody needing code. That much is certain.
>Otherwise, he'd have been fired.
 
I dunno - I've seen similar code in shipping products:
 
For example (Product: ADSINP, language: BPL circa 1977):
 
DEFINE flip (x) = x := x NOT 1#, &FLIP 0/1 00223000
inc (a,b,c,d,e,f,g,h,i,j,k) = 00224000
a := a + IFF (b,b,1) 00225000
IFF (c,+c) IFF (d,+d) IFF (e,+e) IFF (f,+f) IFF (g,+g) 00226000
IFF (h,+h) IFF (i,+i) IFF (j,+j) IFF (k,+k)#, 00227000
dinc (a,b) = inc (a,b,b)#, 00228000
dec (a,b,c,d,e,f,g,h,i,j,k) = 00229000
a := a - IFF (b,b,1) 00230000
IFF (c,-c) IFF (d,-d) IFF (e,-e) IFF (f,-f) IFF (g,-g) 00231000
IFF (h,-h) IFF (i,-i) IFF (j,-j) IFF (k,-k)#, 00232000
ddec (a,b) = dec (a,b,b)#, 00233000
 
or
 
@PAGE&******************************************************************00136700
&***********************************************************************00136800
PROCEDURE.CONVERT_DATE; 00136900
BEGIN 00137000
OWN INTEGER DAYS_TO_DATE (65) := 00137100
36699335123051127410244092130818207152061210509104060030310200001; 00137200
INTEGER TRASH (4),LOCAL_JULIAN_DATE(5); 00137300
00137400
LOCAL_JULIAN_DATE := THE_JULIAN_DATE; 00137500
GREGORIAN_DATE.2.+6 := LOCAL_JULIAN_DATE.2; 00137600
IF LOCAL_JULIAN_DATE.3.+2 GEQ 60 THEN 00137700
BEGIN 00137800
TRASH := LOCAL_JULIAN_DATE.2 * 25; 00137900
IF TRASH.2.+2 NEQ 0 THEN 00138000
LOCAL_JULIAN_DATE := LOCAL_JULIAN_DATE + 1; 00138100
END; 00138200
SEARCH LOW DAYS_TO_DATE.3 THRU DAYS_TO_DATE.+65 00138300
FOR LOCAL_JULIAN_DATE.3.+2 INCREMENT 5; 00138400
GREGORIAN_DATE.2 := BASE.2.+3.IX1; 00138500
GREGORIAN_DATE.2.+3.NM := LOCAL_JULIAN_DATE.3.+2 - BASE.3.IX1; 00138600
END; & CONVERT_DATE 00138700
chrisv <chrisv@nospam.invalid>: Jan 04 07:45AM -0600

Scott Lurndal wrote:
 
>>Otherwise, he'd have been fired.
 
>I dunno - I've seen similar code in shipping products:
 
>For example (Product: ADSINP, language: BPL circa 1977):
 
I suppose that there are some clueless managers who are "impressed" by
impenetrable code.
 
--
"Or could it be that some ISPs are using the shitty linux servers that
draws in viruses and malware? LOL!!!" - some POS that calls itself
"GreyCloud"
scott@slp53.sl.home (Scott Lurndal): Jan 04 02:54PM


>>For example (Product: ADSINP, language: BPL circa 1977):
 
>I suppose that there are some clueless managers who are "impressed" by
>impenetrable code.
 
to be fair, in the 1970's, there were limits on pretty
much everything, including number of lines that a compiler could
handle in a reasonable amount of time given memory constraints.
 
Compact (dense) code was more the rule than the exception in those
days.
Jeff-Relf.Me <@.>: Jan 04 10:17AM -0800

Peter Köhlmann <peter-koehlmann@t-online.de>: Jan 04 07:19PM +0100

wrote:
 
 
> LCS( "ABCDE", "AEBDF" ) = Max( LCS( "ABCD", "AEBDF" ), LCS( "AEBD",
> "ABCDE" ) )
> LCS( "ABCD", "AEBD" ) = 1 + LCS( "ABC", "AEB" )
 
Idiot
ram@zedat.fu-berlin.de (Stefan Ram): Jan 04 06:12PM

Ich kenne die Geschichte bisher so:
 
1995 - 2004 war die Zeit der "Kaffee-Sprachen" wie Java und
C#, die Effizienz für Produktivität eintauschten.
2004 hörten die Prozessoren auf schneller zu werden (im
Single Thread, "The free lunch is over."). Seitdem kommt es
zur Rennaissance nativer Sprachen wie C++. Projekte bei
Microsoft werden wieder von C# auf C++ umgestellt.
 
Aber nun hat vor kurzen der heise-Verlag seine
"Programmiersprache des Jahres" vorgestellt: Java.
 
Eine der Begründungen dafür lautete: Java ist zwar
etwas langsamer, aber es profitiert davon, daß die
Prozessoren immer schneller werden. Hey, so hat man
das bis 2004 immer gesagt! Leben die bei heise also
in der Vergangenheit?
Stefan Ram <ram@zedat.fu-berlin.de>: Jan 04 06:12PM

cancel <Taktfrequenzen-20170104190616@ram.dialup.fu-berlin.de> in newsgroup comp.lang.c++
 
This article was cancelled from within 6.6.4 (NOV)
porparek@gmail.com: Jan 04 08:33AM -0800

Hi All,
 
Why there is no std::shared_array ?
 
thanks for answers
Cholo Lennon <chololennon@hotmail.com>: Jan 04 01:47PM -0300

> Hi All,
 
> Why there is no std::shared_array ?
 
> thanks for answers
 
Maybe this helps:
 
http://stackoverflow.com/questions/25968849/benefits-of-using-boost-shared-array-over-shared-ptr
 
 
--
Cholo Lennon
Bs.As.
ARG
woodbrian77@gmail.com: Jan 03 06:20PM -0800


> inline int GetError () { return errno; }
> inline void windows_start () {}
 
>
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)