Friday, March 13, 2015

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

Melzzzzz <mel@zzzzz.com>: Mar 12 11:09PM +0100

On Thu, 12 Mar 2015 23:02:24 +0100
 
> > ok, the latter is a linker error in C++, not compile time, but
> > still much better than a random error on random architecture
 
> Oh, that is indeed neat! Nice.
 
return type would not be caught by linker... c++ mangles function
names by parameter, but not by return type...
Paavo Helde <myfirstname@osa.pri.ee>: Mar 12 05:26PM -0500

Johannes Bauer <dfnsonfsduifb@gmx.de> wrote in
 
> Well to be honest, you only came up with one example that was news to
> me.
 
The issue is not if something is news to you or not. The issue is whether
something is error-prone and causing problems in the actual work for the
actual programmers. And the winner in this class are C-style casts, I don't
care if they are elegant or not. I really wish that my C++ compiler
rejected all C-style casts.
Christopher Pisz <nospam@notanaddress.com>: Mar 12 05:36PM -0500

On 3/12/2015 3:12 PM, Johannes Bauer wrote:
> doesn't.
 
> Cheers,
> Johannes
 
I had a lot of fun debugging variadic function arguments, which our
genius local C anti-programmer loved to spam everywhere, only to find
casts to incorrect types and void * all over the damn place. That was a
good 6 months of wasted man hours.
 
That's just one example. At one point, I was making a list and a website
dedicated to the hell C programmers working on C++ put me through. I'll
see if I can dig up the page on my HD at home, if you'd like to read
through years worth of my rants.
 
 
 
--
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
---
Christopher Pisz <nospam@notanaddress.com>: Mar 12 05:43PM -0500

On 3/12/2015 3:10 PM, Johannes Bauer wrote:
 
> Or any STL. Or any more advanced C++ features. Yup, that is what I'm doing.
 
> Cheers,
> Johannes
 
Common C programmer mentality. Always a fail.
 
Who are these deluded people that think they can do better than all the
intelligent minds combined that went into coming up with the STL, not to
mention the millions using it?
 
So, if I load up your projects, do I get to experience the joys of
maintaining and debugging your custom linked lists, your own custom
"faster, better" strings that aren't faster or better at all, 6000 line
header files full of typedef-ed types, and a plethora of other
constructs, because you are better than everyone else?
 
Been there, done that on several projects that in the end went belly-up,
all due to some legacy C programmer, that refused to modernize, that
they wouldn't get rid of.
 
 
 
--
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
---
JiiPee <no@notvalid.com>: Mar 13 01:20AM

On 12/03/2015 19:34, Christopher Pisz wrote:
 
>> The vast overwhelming majority of shitty C++ code I've seen is written
>> by people who keep writing C code and calling it C++.
 
> I second that emotion.
 
I remember me learning first C 1996 January. Then I found C++ and never
after that even considered doing a project with C (well only if no other
options, like embedded). Why use a language with less options? :) So its
kind of interesting to see some saying C is better than C++....the way
they think is so different.
"Öö Tiib" <ootiib@hot.ee>: Mar 12 09:04PM -0700

On Thursday, 12 March 2015 23:21:29 UTC+2, Wouter van Ooijen wrote:
> virtual functions you will end up getting them all, not just the ones
> that you actually use. But I agree that switch-based dispatching is in
> most cases even worse.
 
If the implementation does not eliminate all virtuals of class hierarchy
that have been never called virtually then it is issue of quality of
implementation. Fortunately when engineer has problems with compiler
then engineer can fix the compiler.
woodbrian77@gmail.com: Mar 12 10:25PM -0700

On Thursday, March 12, 2015 at 11:04:18 PM UTC-5, Öö Tiib wrote:
> that have been never called virtually then it is issue of quality of
> implementation. Fortunately when engineer has problems with compiler
> then engineer can fix the compiler.
 
Not many programmers fix the compiler bugs they find.
And some code generators are closed source.
 
Brian
Ebenezer Enterprises - So far G-d has helped us.
http://webEbenezer.net
BGB <cr88192@hotmail.com>: Mar 13 12:53AM -0500

On 3/12/2015 11:34 AM, JiiPee wrote:
>> unless I know I cannot afford it.
 
>> M4
 
> In an embedded system?
 
embedded can be fun, but may need clarification as to the class of
hardware and timing constraints, ...
 
like, there is a range of hardware, with anywhere from only a few kB of
RAM, up to devices with 100s of MB (basically, cellphone-class hardware,
or better).
 
likewise, there may be factors like non-real-time (it is done when its
done), vs soft-real-time (avoids significant delays, but small delays
here and there are acceptable), vs hard-real-time (say, code needs to
keep within a strict 10us tolerance and may not have any delays).
 
 
admittedly, I personally do most of my code in straight C (generally
including when developing on PCs as well), sometimes with assembler
thrown in the mix.
 
 
most of my stuff on embedded HW tends to shy away from dynamic
allocation (may be problematic, unavailable, or introduce delays), and
generally does a lot more using fixed-size global arrays (for example,
one statically knows the max number of IO pins, motor outputs, ... which
may exist, so sanely sized global arrays can keep waste low. likewise,
memory for any buffers can be reserved up-front, rather than allocated
dynamically).
 
sometimes, it may make sense to fake dynamic allocation by grabbing an
entry from an array (using a rover), or keeping free items in a
free-list, as this may be less of an issue than using a general-purpose
malloc (while still having more of the "feel" of PC style code).
 
 
(like, if you want to use a lot of the same code on different devices,
#defines and #ifdef's may be used for per-use-case functionality, ...).
 
likewise, a lot more code tends towards being event-driven state
machines, and conventional OO style coding doesn't really fit in so
well, the CPU speed may leave something to be desired, or there may be
issues with how much code is needed (for example, on a PC one may
largely forget about the issue of how much executable code they have in
a program, but on resource-constrained devices, code-size may also be an
issue), ...
 
so, it may be more of a case of doing what works, rather than what is
elegant or pretty.
 
 
and, if something goes wrong, maybe you have some blinking lights to
indicate the error status or something, or maybe get extra fancy and
have a small speaker to make noises or similar...
JiiPee <no@notvalid.com>: Mar 13 07:04AM

On 12/03/2015 16:32, Wouter van Ooijen wrote:
> costly and complex to develop and produce. Does that mean that we'd be
> better off fighting our enemies on bikes?
 
> Wouter
 
some would say that its not good to make war at all.... but thats
another issue and nothing to do with c++ ...
"Öö Tiib" <ootiib@hot.ee>: Mar 13 12:29AM -0700

> > then engineer can fix the compiler.
 
> Not many programmers fix the compiler bugs they find.
> And some code generators are closed source.
 
If you can't fix it then you can ask other programmer who can fix it. The
closed source software is also made by engineers. Engineer is usually
happy to hear about things that he can improve in his product.
Christian Gollwitzer <auriocus@gmx.de>: Mar 13 08:46AM +0100

Am 13.03.15 um 05:04 schrieb Öö Tiib:
> Fortunately when engineer has problems with compiler
> then engineer can fix the compiler.
 
Wow, that is really a bold statement. I think that "real" compilers,
i.e. something like LLVM or g++, are so incredibly complex that only few
people have the ability to "fix" them, if it is something as complex as
optimizing out dead code. Or am I the only one here who admits to not
understans the inner workings of these beasts? Similarly, I've never
hacked the Linux kernel or OpenOffice, when all I wanted was to install
some hardware or to write a letter.
 
Christian
David Brown <david.brown@hesbynett.no>: Mar 13 09:51AM +0100

On 13/03/15 05:04, 嘱 Tiib wrote:
> that have been never called virtually then it is issue of quality of
> implementation. Fortunately when engineer has problems with compiler
> then engineer can fix the compiler.
 
More often, it is a question of /usage/ of the compiler rather than
quality of the compiler. Typically the user has forgotten the
"-Wl,--gc-sections" or "-ffunction-sections" switches (to gcc), or not
enabled optimisation.
 
Of course, the number of engineers who actually read compiler manuals is
probably smaller than the number who can fix the compiler...
David Brown <david.brown@hesbynett.no>: Mar 13 10:03AM +0100

On 12/03/15 17:33, JiiPee wrote:
>> go with Python.
 
>> Wouter
 
> not Visual Basic??
 
If by "quick programming experience" you mean "try being a professional
programmer for a few weeks, then switch career paths to being a crash
test dummy because it's less painful", then Visual Basic is excellent at
finishing your programming experience quickly :-)
 
(I learned to program in Basic, on a wide variety of home computers. VB
is not actually that bad, as long as you are only doing very small and
simple programs, and don't presume that you are learning more than baby
steps of programming. But while I'd not recommend anyone to bother
learning VB, since there are better alternatives, if the choice was only
C++ or VB for first language, then VB is a better choice.)
Martijn van Buul <pino@dohd.org>: Mar 13 09:57AM

* BGB:
 
> like, there is a range of hardware, with anywhere from only a few kB of
> RAM, up to devices with 100s of MB (basically, cellphone-class hardware,
> or better).
 
Uh, why restrict the definition to systems that small? At work, I develop
software on hardware hardware that exceeds most desktop PCs(Broadwell Core i5
or i7, with about 16GB of memory) - yet it is still considered an embedded
system, and much of the issues I'm facing are very similar to the problems seen
on, say, a phone.
 
> most of my stuff on embedded HW tends to shy away from dynamic
> allocation (may be problematic, unavailable, or introduce delays),
 
It's neither. It's surprisingly predictable. Whether you want do do
dynamic memory on all of your RT tasks is something altogether different.
 
> and generally does a lot more using fixed-size global arrays (for example,
> one statically knows the max number of IO pins, motor outputs, ... which
> may exist, so sanely sized global arrays can keep waste low.
 
.. and it can explode in your face, because suddenly you face yourself with
having to allocate for mutually exclusive worst-case scenario's.
 
> likewise, a lot more code tends towards being event-driven state
> machines, and conventional OO style coding doesn't really fit in so
> well,
 
In contrary: It fits like a glove. It allows you to cleanly separate
the state machine from whatever it is controlling, (hopefully) leading to
better code quality. Whether that results in an unacceptable performance
penalty is largely the result of implementation details.
 
In another line of thought: (GUI) applications tend to be *very* event
driven, and so far I haven't heard anyone suggest that OO is a bad paradigm
there.
 
I've done OO on microcontrollers (which, admittedly, would have been
considered premium workstation classs hardware only a few years ago)
 
--
Martijn van Buul - pino@dohd.org
Johannes Bauer <dfnsonfsduifb@gmx.de>: Mar 13 11:04AM +0100

On 12.03.2015 23:43, Christopher Pisz wrote:
 
>> Or any STL. Or any more advanced C++ features. Yup, that is what I'm
>> doing.
 
> Common C programmer mentality. Always a fail.
 
I gave an example where including a *single* reference to std::string
made the program 4 times (!) the size of the controller ROM I'm using.
It just does not fit in the chip.
 
Don't know why this is so hard to understand to your "mentality", but
it's not a "fail" on my part, but a hard, physical constraint.
 
> Who are these deluded people that think they can do better than all the
> intelligent minds combined that went into coming up with the STL, not to
> mention the millions using it?
 
Why do you think I claim I can come up with more "intelligent" code? I
never claimed that and that you seem to suggest I did means the deluded
one here is you.
 
I don't claim to be able to write better code than the STL.
 
I claim to be able to write code that ACTUALLY WORKS in my scenario
where any single reference to STL functionality blows the code so out of
proportion that it becomes LITTERALLY unusable on constrained hardware.
 
> So, if I load up your projects, do I get to experience the joys of
 
Don't worry, you never will "load up my projects". Because nobody would
hire someone with such a deluded mindset to do an embedded programmer's
job. And because if they did they would fire you on the first day when
you come back from a task and say "it can't be done, we need different
hardware".
 
> "faster, better" strings that aren't faster or better at all, 6000 line
> header files full of typedef-ed types, and a plethora of other
> constructs, because you are better than everyone else?
 
So much anger and so much ignorance in your words. What a pity.
 
> Been there, done that on several projects that in the end went belly-up,
> all due to some legacy C programmer, that refused to modernize, that
> they wouldn't get rid of.
 
Life must be hard for you. I truly hope you find someone you can cry
your sorrows to.
 
Cheers,
Johannes
 
--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
scott@slp53.sl.home (Scott Lurndal): Mar 13 01:19PM


>> Cheers,
>> Johannes
 
>Common C programmer mentality. Always a fail.
 
Insults and intolerance seem to be the extent of
your discourse.
 
<rant elided>
scott@slp53.sl.home (Scott Lurndal): Mar 13 01:21PM

>dedicated to the hell C programmers working on C++ put me through. I'll
>see if I can dig up the page on my HD at home, if you'd like to read
>through years worth of my rants.
 
I think most of us would prefer that you keep your rants to
yourself. Here as well. Stick to discussion of C++ and
leave your foolish hatred of C programmers at home.
Wouter van Ooijen <wouter@voti.nl>: Mar 13 02:58PM +0100


> If the implementation does not eliminate all virtuals of class hierarchy
> that have been never called virtually then it is issue of quality of
> implementation.
 
That is theoretically true. But for me (and I guess for nearly everyone)
quality of implementation aspects are often of evrriding importance:
practical heap implementations for instance have an a-priori unknown
effect on the real-time behaviour of my code. You can say that that is
not the 'fault' of C++, but for me the consequence is still that in
general I can't the heap in my real-time code.
 
Fortunately when engineer has problems with compiler
> then engineer can fix the compiler.
 
That is theoretically true, but totally unpractical in practice.
 
Wouter van Ooijen
Wouter van Ooijen <wouter@voti.nl>: Mar 13 03:01PM +0100

JiiPee schreef op 13-Mar-15 om 8:04 AM:
>> better off fighting our enemies on bikes?
 
>> Wouter
 
> some would say that its not good to make war at all....
 
And I agree, but that would force me to find another argument that is
understandable to the war-minded world in general ;)
 
Wouter
Wouter van Ooijen <wouter@voti.nl>: Mar 13 03:04PM +0100

JiiPee schreef op 13-Mar-15 om 2:20 AM:
 
> Why use a language with less options? :)
 
One good reason is to look at it from the *reader* instead of the writer
perspective: YOU might settle on a reasonable subset of your language to
write your code in, but each feature will end up in someones subset, so
to read and maintain code you will need to understand the whole language.
 
Wouter
"Lőrinczy Zsigmond" <zsiga@nospam.for.me>: Mar 13 12:59PM +0100


> Hi, I am having a difficult time figuring out how I'm going to design my
> base and derived classes for a specific project.
 
Actually, it's not about classes and inheritance,
it's about data-organizations.
Maybe you could start here:
 
https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
Paul <pepstein5@gmail.com>: Mar 13 02:34AM -0700

I don't completely understand the implementation from http://www.cplusplus.com/reference/memory/uninitialized_copy/ although I do understand the basic idea.
 
The function is implemented below. I don't understand why (&*result) instead of just (result). Surely, when you dereference a pointer and then take the address, the operations just reverse each other. Using (result) instead of (&*result) worked fine on my compiler so I wasn't able to see why this was necessary. I also don't see why casting to void* is necessary. This also wasn't necessary on my compiler.
 
Thank you,
 
Paul
 
template<class InputIterator, class ForwardIterator>
ForwardIterator uninitialized_copy ( InputIterator first, InputIterator last,
ForwardIterator result )
{
for (; first!=last; ++result, ++first)
new (static_cast<void*>(&*result))
typename iterator_traits<ForwardIterator>::value_type(*first);
return result;
}
fefe <fefe.wyx@gmail.com>: Mar 13 02:46AM -0700

As implied by the name of the template parameter `ForwardIterator`, it may not be a pointer but an iterator, such as vector::iterator. Most iterators are not pointers, so *result will the object, and &*result will get the address of the object the iterator points to.
"Skybuck Flying" <skybuck2000@hotmail.com>: Mar 13 04:29AM +0100

KB 2670838 - The EVIL UPDATE
 
This Windows 7 update wasted a lot of my time today.
 
I could not find my own postings in the past... maybe I was unsure in the
past... I am still unsure today.. but much more sure than previously.
 
When installing IE11 I suspect this patch also gets installed.
 
This patch will cause:
 
1. Windows Live Mail fail to crash, making mail inaccessible.
2. Company of Heroes, Tales of Valor to crash.
3. Call of Duty 5 World at War to stop loading.
4. Possibly even IE9 to keep crashing...
5. And perhaps other misschief.
 
This patch is the worst patch I have ever seen... I am not 100% sure but
it's a very good guess.
 
Therefore it's time for me to spam this message all across usenet... so that
I will always find it in google hopefully, next time it pops it's ugly
head...
 
Hopefully it will save my lost of time in the future.
 
Also bare in mind:
 
IE9 crashes
IE10,IE11 is junk, it's slow... it's laggy and it's not worth this patch
trouble.
 
My advice is stick with Firefox and other browsers... always make sure to
have multiple browsers installed otherwise you might be stranded...
 
Also if you ever have a crashing internet explorer and you really can't
recover... remember that you can de-install it... this will revert it back
to IE8... at least that should give you a chance to become "unstranded" and
access the web again for help.
 
KB 2670838 - The EVIL UPDATE
 
 
http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_update/kb-2670838-the-evil-update/08bfdb2b-6896-4c34-89c2-16896a25dc3d
 
I was hoping Microsoft fixed this patch by now... unfortunately they did
not... and are probably too busy messing around with windows 8.1/windows 10
etc.
 
Shame on them cause this is ONE BITCH OF A PATCH !!!
 
Also FUCK Microsoft for intentionally DAMAGING computer software !
 
My trust in Microsoft is disappearing.
 
Their behaviour is always the same basically:
 
"Damage old software to try and get people to buy new systems/upgrade".
 
This patch makes me sick to my stomach... mostly because it endangers my
data !
 
If Microsoft causes my DATA to be lost or inaccessable their software will
be TERMINATED by me and I will switch to something else.
 
Even if it's just a stupid little patch like this... this kind of thing....
making my mail archieve inaccessible is unacceptable behaviour.
 
I will keep a close eye on this patch to see if it ever gets fixed.
 
If now I may get so sick to my stumach that I might just skip Windows 10 and
go to Linux route...
 
For now at least it can be deinstalled... but it comes at a great risk: no
more internet explorer, no more internet explorer updates...
 
Now I have to trust Mozilla and Open Source developers ?!
 
What's the world coming too ?! ;) ;) ;)
 
If Microsoft keeps this up they will drive everybody to open source... is
that what you want Microsoft ?
 
You guys are doing really bad right now... one little patch and you can't
fix it ???? REally ???
 
I will examine your details about this patch... I probably did it n the past
already...
 
You know what I will do it right now... just to see if I can add some info
to this posting.
 
Basically this is some kind of graphics patch update for hybrid graphics
cards... fuck that... please shove this up your ass.
 
Integrated graphics probably....
 
HHHHHHHHHHHHHHHHHHHHHHHHHHHMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
 
WHERE HAVE I HEAR THAT BEFORE ????????????????
 
DOES INTEL WRING A BELLLL ?????????????????
 
INTEGRATED ELECTRONICS = INTEL.
 
This patch is apperently CODE-AUTHORED BY INTEL.
 
INTEL IS PURPOSELY NUKING YOUR SYSTEMS.
 
THIS PUTS A NEW PERSPECTIVE ON INTEL.
 
I WAS PLANNING TO BUY THEIR NEW SKYLAKE PROCESSOR...
 
THOUGH THEIR HASWELL HAD A TRANSACTIONAL MEMORY BUG.
 
THIS LATEST RELEVATION/CONCLUSION SHEDS NEW LIGHT ON THIS POTENTIAL EVIL
FROM INTEL.
 
I can only advice researchers, academics, hackers, press... to investigate
this matter further.
 
IF THIS IS TRUE THEN THIS IS A GIGANTIC SCHANDAL OF IMAGINABLE PROPORTIONS
AND NEEDS A SEVERE COUNTER REACTION.
 
IF THIS IS TRUE I CAN RECOMMEND A BOYCOTT OF INTEL PROCESSORS AND MICROSOFT
SOFTWARE AND SWITCH TO OPEN SOURCE SOFTWARE where these kind of trust issues
and bugs can be more easily spotted and fixed and hopefully AVOIDED.
 
Basically I DEMAND A FULL INVESTIGATION from the goverments INTO PATCH
2670838.
 
GOODBYE,
FAILURE TO DO SO PUTS YOUR SYSTEMS AT RISK !
 
Bye,
Skybuck.
woodbrian77@gmail.com: Mar 12 07:23PM -0700

On Thursday, March 12, 2015 at 11:57:06 AM UTC-5, Lynn McGuire wrote:
 
> > Regards.
 
> I use the CGIC library on my webserver.
> http://www.boutell.com/cgic/
 
What do you use it for? I used to use that library also.
Now I use a binary protocol rather than http and C++ rather
than C.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
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)