Sunday, February 28, 2016

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

woodbrian77@gmail.com: Feb 27 05:25PM -0800

On Friday, February 26, 2016 at 6:54:39 PM UTC-6, Richard wrote:
 
Richard,
 
Please don't swear here.
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 28 02:15AM

> On Friday, February 26, 2016 at 6:54:39 PM UTC-6, Richard wrote:
 
> Richard,
 
> Please don't swear here.
 
'This video may contain sexual swearwords, I'm afraid. There are 28
'fucks'. Including that one 29. Ah, fuck it, make it 30.' -- Paul Calf
 
https://www.youtube.com/watch?v=42UCpOzTbNU
 
/Flibble
Gareth Owen <gwowen@gmail.com>: Feb 28 07:33AM

> fucks'. Including that one 29. Ah, fuck it, make it 30.' -- Paul Calf
 
> https://www.youtube.com/watch?v=42UCpOzTbNU
 
> /Flibble
 
"As such this video may contain frequent sexual swearwords, such as
bollocks, and wanke..." https://www.youtube.com/watch?v=15niBO3ZaQo
Christian Gollwitzer <auriocus@gmx.de>: Feb 28 09:19AM +0100

> On Friday, February 26, 2016 at 6:54:39 PM UTC-6, Richard wrote:
 
> Richard,
 
> Please don't swear here.
 
I don't understand, why you oppose against fucking. It is the one thing
through which we all were made. It is scientifically proven the cause of
all our being.
 
Christian
David Brown <david.brown@hesbynett.no>: Feb 28 04:43PM +0100

On 27/02/16 17:45, 嘱 Tiib wrote:
 
> Experimental implementation is not carved into rock and its makers
> knew that it has to be likely rewritten. People who used such for
> real product knew with what they risk.
 
Yes, there is a bit of trial-and-error here to see what works in
practice. Some people will like the idea enough to risk using the
experimental versions - and their feedback will help shape the final
versions. I understand that this will take time - but I hope it will
not be long before a final agreed version can be made.
 
> I am more worried that adding innovations like Modules, Concepts and
> Reflection at once will cause serious headache of integrating those
> features into whole.
 
Certainly modules and concepts are being tried out as experimental
features in compilers - hopefully that means they will be reasonably
good when they make the standards. It would be unfortunate if they were
added and then found to have some fundamental problem.
"Öö Tiib" <ootiib@hot.ee>: Feb 28 10:24AM -0800

On Sunday, 28 February 2016 17:44:09 UTC+2, David Brown wrote:
> features in compilers - hopefully that means they will be reasonably
> good when they make the standards. It would be unfortunate if they were
> added and then found to have some fundamental problem.
 
I wonder if anyone is trying all the three at once? Integration involves
always issues, rough edges and dim corners. Dealing with those may add
complexities and complexities may be in conflict with faster and
better scalable builds, better diagnostics, easier definition checking,
more transparency, better structure, better type-safety (IOW the
motivation of adding those features).
Juha Nieminen <nospam@thanks.invalid>: Feb 28 06:26PM

> Why people are insistent on trying to jam every possible library into
> the standard is beyond me.
 
That got me thinking: There are many things that do not really belong
into the C++ standard, but are nevertheless things that would be very
useful and people often request.
 
Perhaps a kind of compromise could work: A "secondary" specification
defined by the standard committee, of optional libraries. In other words,
libraries that a standard-conforming compiler is not forced to implement,
but if it does, then it has to implement it as specified (so that all
programs written to use said library will compile and work).
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 28 07:42PM

On 28/02/2016 07:33, Gareth Owen wrote:
 
>> /Flibble
 
> "As such this video may contain frequent sexual swearwords, such as
> bollocks, and wanke..." https://www.youtube.com/watch?v=15niBO3ZaQo
 
Interesting that "wanker" is acceptable on the BBC whilst, I think,
"cunt" is not but this is probably due to the fact that "cunt" is the
strongest swear word in the English language. ITV dubbed out the "cunt"
in "Can I get any of you cunts a drink?" when they showed Shaun Of The
Dead once.
 
/Flibble
Gareth Owen <gwowen@gmail.com>: Feb 28 09:04PM


> Interesting that "wanker" is acceptable on the BBC whilst, I think,
> "cunt" is not but this is probably due to the fact that "cunt" is the
> strongest swear word in the English language.
 
Well, there's no flat list of "allowed v. not allowed". The context is
taken into consideration. I do remember ITV once replacing the word
"Penis" with "Twinkie" in Ghostbusters, tho.
Dombo <dombo@disposable.invalid>: Feb 28 10:18PM +0100

Op 27-Feb-16 om 20:23 schreef Öö Tiib:
 
> It is actually good. It makes clear interface where your program logic
> layer (that does not use UI classes) touches with UI (that does not
> use standard library).
 
If mixing UI and program logic is really a big concern and you cannot
rely on the discipline of the developers you'd much better of using
another programming language for the UI.
 
> intermixed with GUI and I congratulate GUI toolkit that makes it as
> painful as possible for those who let so different responsibilities
> to diffuse all over the code base.
 
I'm all for keeping a clear separation between UI and business logic.
But there are better ways to accomplish that than introducing
incompatible types. Making interfacing with the standard library
unnecessarily hard just stimulates people to just do everything in the
UI code to avoid having to write error-prone/no-added-value glue code to
interface with other parts of the program.
 
And lets be honest; keeping the UI code separate from business logic is
not the reason why those GUI toolkits have their own string and
container classes. Just look at Qt, it is (unfortunately) not just a GUI
library, but provides classes for just about anything they could think
of, including lots of stuff that has absolutely nothing to do with UI.
And guess what; those non-UI classes use the same string types and
container types as used for the GUI part, apparently Qt didn't thought
it was necessary to introduce more incompatible string and container
classes to make the distinction between UI and business logic clear.
 
One of the things that separates C++ from other modern programming
languages is the inconsistent mess of (naming) conventions, strings,
containers...etc you get confronted with if you use multiple libraries
from various sources. Not a good thing in my book.
Ian Collins <ian-news@hotmail.com>: Feb 29 10:18AM +1300

Mr Flibble wrote:
> strongest swear word in the English language. ITV dubbed out the "cunt"
> in "Can I get any of you cunts a drink?" when they showed Shaun Of The
> Dead once.
 
Before or after The Thick of It?
 
This one is still hard to best:
 
https://www.youtube.com/watch?v=JaY7VTftPdY
 
--
Ian Collins
JiiPee <no@notvalid.com>: Feb 28 01:27PM

We all know the vector class does not have a function to delete extra
memory from the vector. So my first question is that why is it not
there? :) Is there a good reason, as I think its many times needed.
 
Secondly, we can do it ouselves, and everybody recommends:
 
(deleting extra memory from a)
vector<int> a{3,4,7,5,8,7};
a.push_back(55);
 
vector<int> temp(a);
a.swap(temp);
 
so now a has capacity 7. But I was just thinking, that can't we just do
a move:
vector<int> temp(a);
a = std::move(temp);
 
becouse move will now make sure a is excatcly temp. Why we would like to
copy stuff from a to temp (with swap) bce temp is not needed anyway ...
kind of extra work? What is the reason behind swap here?
JiiPee <no@notvalid.com>: Feb 28 02:38PM

does anybody know in what situation shrink_to_fit would not do the job
of taking off the extra memory exactly like asked? I tested, and it
always did take off the extra memory. But we know its not guaranteed, so
in what situation it would not do it?
 
On 28/02/2016 13:27, JiiPee wrote:
Paavo Helde <myfirstname@osa.pri.ee>: Feb 28 06:53PM +0200

On 28.02.2016 15:27, JiiPee wrote:
> We all know the vector class does not have a function to delete extra
> memory from the vector.
 
You mean shrink_to_fit() is not guaranteed to work? I bet when it does
not then it has good reasons not to.
 
> So my first question is that why is it not
> there? :) Is there a good reason, as I think its many times needed.
 
For example? It most probably means an extra copy of the whole array for
no obvious benefit.
 
If one is working in tight environment where every byte is counted, then
one does not over-allocate arrays in the first place, so there will be
no need to shrink them. Instead, one would use e.g. reserve() to
allocate the correct amount beforehand.
 
> a move:
> vector<int> temp(a);
> a = std::move(temp);
 
That's basically just as good. The swap idiom just predates the C++11
move. And if you have C++11 then you will have shrink_to_fit() which
most probably does the same in a more direct way, so there is no need to
use move.
 
 
> becouse move will now make sure a is excatcly temp. Why we would like to
> copy stuff from a to temp (with swap) bce temp is not needed anyway ...
> kind of extra work? What is the reason behind swap here?
 
Swap was a workaround to *avoid* extra copy and extra work in pre-C+11
when there was no move.
"Öö Tiib" <ootiib@hot.ee>: Feb 28 09:38AM -0800

On Sunday, 28 February 2016 16:38:55 UTC+2, JiiPee wrote:
> of taking off the extra memory exactly like asked? I tested, and it
> always did take off the extra memory. But we know its not guaranteed, so
> in what situation it would not do it?
 
Implementations are allowed to ignore it for sake of optimizations.
 
Imagine memory management that actually allocates only as multiples
of 32 bytes or the like. In reality most implementations have memory
management with such constraints.
 
As result the 'std::vector<char> hi{'H','e','l','l','o',0};' has
two choices:
1) to claim that its capacity is 6 (despite it got 32 bytes)
2) to put extra effort into telling honestly that the capacity is 32.
Most implementations have chosen to ignore the extra and to
do 1). It is simpler to implement and less stupid questions and
who really cares that it is less optimal.
Juha Nieminen <nospam@thanks.invalid>: Feb 28 06:32PM

> We all know the vector class does not have a function to delete extra
> memory from the vector. So my first question is that why is it not
> there? :) Is there a good reason, as I think its many times needed.
 
std::vector::shrink_to_fit() does exactly that, if the underlying
memory management system supports reducing the size of an alloction.
(If the underlying memory management system does not support it, which
is sometimes the case, then that function does nothing.)
 
The reason why it's optional is, obviously, because historically not
all systems support resizing of allocated blocks of memory (either
larger or smaller). The only way was/is to allocate a new block and
copy all the values there.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 28 09:32PM +0100

On 28.02.2016 19:32, Juha Nieminen wrote:
>> there? :) Is there a good reason, as I think its many times needed.
 
> std::vector::shrink_to_fit() does exactly that, if the underlying
> memory management system supports reducing the size of an alloction.
 
No no.
 
shrink_to_fit can and will in general allocate a new buffer, when the
original capacity is way too large.
 
 
> (If the underlying memory management system does not support it, which
> is sometimes the case, then that function does nothing.)
 
No no.
 
 
> all systems support resizing of allocated blocks of memory (either
> larger or smaller). The only way was/is to allocate a new block and
> copy all the values there.
 
Yes, I agree. :)
 
 
Cheers!,
 
- Alf
Bob Langelaan <bobl0456@gmail.com>: Feb 28 11:38AM -0800

I have defined a variable m_Dir of the type:
 
enum Directions { NORTH, EAST, SOUTH, WEST };
 
I thought I should be able to increment the variable:
 
++m_Dir;
 
but I get the error:
 
"Error (active) this operation on an enumerated type requires an applicable user-defined operator function"
 
I thought this was supposed to work. Is this a bug or am I remembering wrong?
 
Thanks,
Bob
Jerry Stuckle <jstucklex@attglobal.net>: Feb 27 08:15PM -0500

On 2/27/2016 6:33 PM, Paavo Helde wrote:
>> is it owned by Borland any longer. It has changed significantly since
>> Borland owned it.
 
> So... and which part of this means "eventual failure of [Turbo C++]"?
 
The part where Borland failed with it.
 
> been name changes and sell-offs (to shake off some alleged bad
> reputation or not, I don't know), but as far as I can see there is no
> "eventual failure".
 
The current product is nothing like the failed one. Just because there
is a derivative does not mean the original was successful.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: Feb 27 06:21PM -0500

On 2/27/2016 5:47 PM, Paavo Helde wrote:
 
> Except that it is not dead. Nowadays this is called Embarcadero
> C++Builder and the last release according to Wikipedia was on 31 Aug.
> 2015 (C++Builder 10 Seattle (23)).
 
C++ Builder is a derivative of Turbo C++, but it is not Turbo C++, nor
is it owned by Borland any longer. It has changed significantly since
Borland owned it.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
David Brown <david.brown@hesbynett.no>: Feb 28 03:26PM +0100

On 27/02/16 19:14, 嘱 Tiib wrote:
 
> I meant it more generally. People who ever want to port their code to
> different version or different compiler or different platform should
> be prepared that there are some noisy and some silent breaking changes.
 
Agreed.
 
> representation of bitfield some are because of defects. Defects are
> most likely in the code compiled but sometimes also in previous or
> new implementation.
 
Agreed. It is important to remember that "implementation defined
behaviour" can vary between compiler versions. New compiler versions
can have new bugs in the compiler - they can also have new optimisations
or changes to code generation that causes different behaviour in code
that had undefined behaviour but happened to work on the other compiler.
 
For the kind of development I do, I rarely change compiler in the middle
of a project - and if I have to make changes to an old project, I first
bring up the old tools and check that I can do a bit-perfect rebuild of
the old version.
 
Marcel Mueller <news.5.maazl@spamgourmet.org>: Feb 28 10:16AM +0100

On 27.02.16 21.48, Öö Tiib wrote:
 
> I see you use string literals to initialize 'Name' so I don't
> understand why there is that mutable array and that L, do you want
> to dynamically modify it?
 
No, but the same structure is used for other lookup tables too.
The size differs from table to table and I did not want to define a new
type for each purpose.
 
 
> 'boost::variant<paramtype1,paramtype2,paramtype3>'. You must know
> anyway all the different types of parameters when you initialize
> that 'opcodeMap' of yours.
 
Not that pretty since there are about a dozen types, but true. The do
not change often. I could use a typedef.
 
> Btw words like "Map" and "List" may be
> misleading in name of variable since readers sometimes assume
> underlying container.
 
Well, basically it is a map, implemented as sorted array.
The compiler will tell, if someone tries to invoke .begin() ;-)
But since the member is private this is unlikely.
 
 
> No ... union is not type-safe, it is type-punning.
 
With an appropriate C++ wrapper it is safe.
 
>> Could this be expressed type safe in C++11, without the need to deal
>> with pointers, new and delete for each line?
 
> Unfortunately the 'variant' is not in C++11.
 
Hmm, the additional dependency to the boost library could cause some
harm with respect to portability. Especially because I require constexpr
support.
 
 
Marcel
Marcel Mueller <news.5.maazl@spamgourmet.org>: Feb 28 10:31AM +0100

On 27.02.16 21.58, Alf P. Steinbach wrote:
> };
 
> // ... later
> Op_entry e{ "Blah!", [=](){ Parser::assembleADD( Inst::A_ADD ); } };
 
Indeed, I didn't think of lambdas.
 
But is this still constexpr? I.e. can this still be a table of compile
time constants in the rodata segment?
If the objects have to be created at application start, it would be
quite costly, there are thousands (not only for op-codes). Target is a
Pi 1, where performance is always an issue.
 
 
Marcel
"Öö Tiib" <ootiib@hot.ee>: Feb 28 03:12AM -0800

On Sunday, 28 February 2016 11:31:39 UTC+2, Marcel Mueller wrote:
> If the objects have to be created at application start, it would be
> quite costly, there are thousands (not only for op-codes). Target is a
> Pi 1, where performance is always an issue.
 
Lambdas are not allowed in constexpr expressions by C++14. There is
proposal N4487. http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4487.pdf
I'm not sure what versions of what compilers support it.
"Öö Tiib" <ootiib@hot.ee>: Feb 28 05:03AM -0800

On Sunday, 28 February 2016 11:16:35 UTC+2, Marcel Mueller wrote:
 
> No, but the same structure is used for other lookup tables too.
> The size differs from table to table and I did not want to define a new
> type for each purpose.
 
Do you modify that 'Name' dynamically in other lookup tables then?
 
> > that 'opcodeMap' of yours.
 
> Not that pretty since there are about a dozen types, but true. The do
> not change often. I could use a typedef.
 
Yes, but how else to reach type-safety? All the allowed types
have to be listed somewhere for wrong type to cause code
being ill-formed with diagnostic.
 
> But since the member is private this is unlikely.
 
> > No ... union is not type-safe, it is type-punning.
 
> With an appropriate C++ wrapper it is safe.
 
Writing such wrapper around union is quite interesting task that is why
there are so lot of different variant classes.
 
 
> Hmm, the additional dependency to the boost library could cause some
> harm with respect to portability. Especially because I require constexpr
> support.
 
I am not sure how you mean constexpr and portability almost in same
sentence. Constexpr was sort of careful in C++11 and C++14 loosened it
up only slightly. Couple latest versions of top compilers support it
and only Clang is bit ahead of time with it.
 
My opinion is that if you need best portability and best tested
thing then Boost.Variant, if you need better constexpr support
then Eggs.Variant. Those have quite close interfaces. Both are
licensed under boost's "do whatever you want just don't change the
license".
 
Eggs.Variant's repo includes interesting Catch unit
test framework if you don't have one. Add unit tests what you
really want and run those on targets that you target.
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)