Friday, February 9, 2018

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

Lynn McGuire <lynnmcguire5@gmail.com>: Feb 09 04:43PM -0600

On 3/15/2017 3:45 PM, Richard wrote:
> offering built-in that uses the clang front end and the MSVC code
> generator allowing you access to the language parsing of clang and
> code generation of MSVC.)
 
"How to compile C++ for Windows with clang in Visual Studio 2015"

https://stackoverflow.com/questions/31351372/how-to-compile-c-for-windows-with-clang-in-visual-studio-2015#34011385
 
Looks a little tricky.
 
Lynn
Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 09 06:38AM

On Thu, 2018-02-08, Josef Moellers wrote:
...
> x86 architectures, but eg the M68k (and, probably others too) has two
> sets of registers: address and data registers and int results are
> returned in d0 while pointer results in a0!
 
I'm pretty sure the Commodore-Amiga (MC68000) ABI said everything
fitting in a register was returned in d0. Supporting pre-prototype C
might have been the reason. There may be/have been other examples,
but a MC68k-based computer doesn't /have to/ do it like you describe.
 
Of course, use C or C++ properly and you don't have to care.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
David Brown <david.brown@hesbynett.no>: Feb 09 09:24AM +0100

On 08/02/18 17:04, Josef Moellers wrote:
> x86 architectures, but eg the M68k (and, probably others too) has two
> sets of registers: address and data registers and int results are
> returned in d0 while pointer results in a0!
 
This is a totally specious argument. Your compiler should warn you
about using a function without a declaration. If it does not, you
either have a useless compiler, or you don't know how to use your tools.
Either way, you have a vastly bigger problem than a mere incorrect
function call.
 
Similarly, arguments about "you might get inconsistent types if the code
is changed" are only valid if you have a completely broken development
process.
 
The only reason /not/ to cast the result of malloc() in C is that
casting it will cause some old C programmers to rant about it being a
C++'ism and how K&R never cast their mallocs, so neither should you.
 
Ben Bacarisse <ben.usenet@bsb.me.uk>: Feb 09 10:54AM

David Brown <david.brown@hesbynett.no> writes:
<snip>
> The only reason /not/ to cast the result of malloc() in C is that
> casting it will cause some old C programmers to rant about it being a
> C++'ism and how K&R never cast their mallocs, so neither should you.
 
K&R always do so the old programmers would be lying!
 
The main reason not to cast the result of malloc is just that it's
extraneous code. Some people like extraneous code, but if you don't,
that's probably reason enough.
 
--
Ben.
David Brown <david.brown@hesbynett.no>: Feb 09 12:43PM +0100

On 09/02/18 11:54, Ben Bacarisse wrote:
>> casting it will cause some old C programmers to rant about it being a
>> C++'ism and how K&R never cast their mallocs, so neither should you.
 
> K&R always do so the old programmers would be lying!
 
Ah, you know your K&R better than I do :-)
 
> The main reason not to cast the result of malloc is just that it's
> extraneous code. Some people like extraneous code, but if you don't,
> that's probably reason enough.
 
People don't always agree on what is "extraneous". Casting the result
of malloc is certainly extraneous from the viewpoint of C. But if you
think it improves readability, reduces the risk of errors, or improves
portability to C++ (most programmers agree that malloc should not be
found often in C++ code, but it turned up in this example), then it is
no longer extraneous. I am no fan of adding code that serves no
purpose, but I see purpose in code beyond the mere mechanics of the
language needed for the compiler.
 
My main point is that if you think casting the result of malloc (or any
other void* pointer) increases the risk of errors in your C code, then
you have a problem with the way you write, compiler or otherwise
automatically check your code.
 
Beyond that, it is a matter of choice or coding style.
Josef Moellers <josef.moellers@invalid.invalid>: Feb 09 02:06PM +0100

On 09.02.2018 11:54, Ben Bacarisse wrote:
>> casting it will cause some old C programmers to rant about it being a
>> C++'ism and how K&R never cast their mallocs, so neither should you.
 
> K&R always do so the old programmers would be lying!
 
I stand corrected, they indeed do: "should (1st ed)/must (2nd ed) be
cast into the apropriate type".
 
Josef
James Kuyper <jameskuyper@verizon.net>: Feb 09 11:05AM -0500

On 02/09/2018 03:24 AM, David Brown wrote:
> On 08/02/18 17:04, Josef Moellers wrote:
...
 
> This is a totally specious argument. Your compiler should warn you
> about using a function without a declaration. If it does not, you
> either have a useless compiler, or you don't know how to use your tools.
 
In C90, the behavior when calling a function without a declaration in
scope could be well-defined: the standard argument promotions were
performed on all arguments and the return type was implicitly assumed to
be int. If the number of arguments was the same as the number of
parameters in the function definition, and if the the promoted types of
the arguments were compatible with the corresponding parameters in the
function definition, and if the return type was actually int, there was
no problem with writing such code. Lots of code took advantage of this
fact, and a compiler that warned about such code by default would have
been very annoying to a lot of people (personally, I would have been
overjoyed to use such a compiler, or even one where it was merely an
option that could be turned on).
 
Implicit int was a bad idea, which is why it was removed in C99. But an
awful lot of code has been written (and some is still being written)
which either targeted C90 or was at least required to be compatible with
it. In the context of C90, it's a valid argument and excellent advice.
 
> Either way, you have a vastly bigger problem than a mere incorrect
> function call.
 
Yes, being forced to use C90 is a bigger problem - but not necessarily a
solvable one. In production code for the MODIS instrument, I'm bound by
a standards and guidelines document written in the 1993 that mandates
the use of either Ada, Fortran 77, Fortran 90, or C94 (C90 + two
technical corrigenda). That document has, as far as I know, never been
updated, replaced, or canceled - and I haven't been able to convince
anybody that it needs to be (to be fair, it's been a long time since I
last bothered trying).
 
> The only reason /not/ to cast the result of malloc() in C is that
> casting it will cause some old C programmers to rant about it being a
> C++'ism and how K&R never cast their mallocs, so neither should you.
 
As has already been pointed out by others, K&R did make the mistake of
casting their malloc()s. In all fairness to them, that was long before
anybody (the designers of C included) had had enough experience writing
C to realize that it was a bad idea to cast a malloc() call.
David Brown <david.brown@hesbynett.no>: Feb 09 06:10PM +0100

On 09/02/18 17:05, James Kuyper wrote:
> scope could be well-defined: the standard argument promotions were
> performed on all arguments and the return type was implicitly assumed to
> be int.
 
Yes, it could be well-defined. But implicit function declarations were
removed from the language in C99, and form of the implicit declarations
of C90 "int foo()" were considered obsolete in C90. Relying on implicit
function declarations has never been considered good practice.
 
So if you are writing code in a way that uses a poorly considered
language construct that was removed two decades ago, obsolete three
decades ago, and never considered a good idea, then you are not exactly
writing high quality code. And if you are using tools which don't tell
you about such a basic mistake, you are either using hopeless tools, or
you don't know how to use the tools you have.
 
I have had to deal with code written in this way. Actually, the
compiler /did/ warn this programmer about the implicit function
declarations - he just thought "it's only a warning, not a real
problem". The result was utterly crap software that was often
incomprehensible because a function could be used in one file with a
different set of parameters from the way it was defined.
 
(I think it is a flaw in gcc's warnings that "-Wimplicit-int" and
"-Wimplicit-function-declaration" are not enabled by default in C90
mode. In C90 mode it has to accept such code, but it could still warn
about it.)
 
> been very annoying to a lot of people (personally, I would have been
> overjoyed to use such a compiler, or even one where it was merely an
> option that could be turned on).
 
Old tools were more limited than modern ones. Some people wrote bad
code. That is no excuse for using failing to use modern tools to help
write good software.
 
I can understand people used to write code in other ways. I can
understand people using a wider set of C constructs than I do. But
there is some stuff that simply has no good justification for writing.
 
> awful lot of code has been written (and some is still being written)
> which either targeted C90 or was at least required to be compatible with
> it. In the context of C90, it's a valid argument and excellent advice.
 
No, it is not a valid argument and not excellent advice. Sure, some
people write C90 code - in many cases it is because the programmer
doesn't know any better, or has heard that K&R is "the Bible" for C
programming. But in some cases there are sensible reasons for it.
 
However, that does not matter. It does not /matter/ that you are
allowed to use implicit function declarations in C90, any more than it
matters that gcc will accept such code even in C99 or C11 mode, with
merely a warning. People can write C90 code if they need to or want to
- but they should still be striving to write /good/ C90 code.
 
Excellent advice here is not "make sure you never cast the result of
malloc so that you can find find this one particular case of missing
header files". Excellent advice is "make sure you have the right header
files for the functions you use", and "make sure you enable warnings in
your toolchain to catch small mistakes early".
 
> updated, replaced, or canceled - and I haven't been able to convince
> anybody that it needs to be (to be fair, it's been a long time since I
> last bothered trying).
 
Being required to write C90 is not the problem. It is writing bad code
without good use of tools that is the problem. Sure, C99 lets you write
better code in an easier way than C90, and I dislike having to go back
to C90 on the few occasions when it is necessary in my job. But you are
certainly not required to use implicit function declarations just
because you are writing C90 - it is, after all, implicitly obsolete
already in that standard.
 
> casting their malloc()s. In all fairness to them, that was long before
> anybody (the designers of C included) had had enough experience writing
> C to realize that it was a bad idea to cast a malloc() call.
 
I don't see casting malloc()s as a mistake. An unnecessary cast, yes,
technically. It is something you can choose to do or not - if you feel
it makes code clearer, or less susceptible to errors, then use it. (For
example, if there is a distance between the declaration of the pointer
and the call to malloc, then the cast will likely lead to a warning if
you have got the type wrong.) If you feel it disrupts the flow of the
code and its readability, then don't use it. But if you feel the cast
makes it /less/ likely that an error will be caught by your tools, then
you should fix your use of tools.
James Kuyper <jameskuyper@verizon.net>: Feb 09 12:48PM -0500

On 02/09/2018 12:10 PM, David Brown wrote:
> On 09/02/18 17:05, James Kuyper wrote:
...
> language construct that was removed two decades ago, obsolete three
> decades ago, and never considered a good idea, then you are not exactly
> writing high quality code. ...
 
It's not about deliberately using the construct, which was never a good
idea; my C instructor warned us against relying on that feature when I
first learned C in 1987, so it was already common knowledge before the
first standard was even approved. It's about protecting against a danger
that could only come up because that construct was permitted: the
possibility of forgetting to #include the appropriate header, and
getting no warning about the declaration being missing.
 
> ... And if you are using tools which don't tell
> you about such a basic mistake, ...
 
Then you were using perfectly ordinary commonplace implementation of
C90. Modern implementation that have a C90 mode often warn about this,
but it's still often optional, and was not as common before C99 came out
as it is now.
 
...
> Old tools were more limited than modern ones. Some people wrote bad
> code. That is no excuse for using failing to use modern tools to help
> write good software.
 
True. and if there were any good reason for inserting the cast, your
vitriol against those who object to it would be more understandable. But
I know of none, (and I've heard the faulty arguments of those who think
it makes their code safer a great many times).
 
...
> certainly not required to use implicit function declarations just
> because you are writing C90 - it is, after all, implicitly obsolete
> already in that standard.
 
As I said, the issue had nothing to do with deliberately using the
construct - it was about protecting yourself from accidentally invoking
the construct, and not getting any warning about the fact.
It's also about not writing code that serves no useful purpose, and that
applies even to more modern C compilers.
 
...
>> anybody (the designers of C included) had had enough experience writing
>> C to realize that it was a bad idea to cast a malloc() call.
 
> I don't see casting malloc()s as a mistake.
 
That's too bad - you really should understand the reasons why it was (in
C90). It's an important example of how not to design a computer language.
 
> example, if there is a distance between the declaration of the pointer
> and the call to malloc, then the cast will likely lead to a warning if
> you have got the type wrong.)
 
But you can solve the "wrong type" problem equally well by removing the
cast entirely. The real issue with malloc() is not getting the right
type: that happens automatically when malloc() is used correctly (which
doesn't require a cast - implicit conversions do the right thing without
it). It's getting the right size - and that's something that can be
arranged perfectly by using malloc(count * sizeof *p), without needing
to know or care about what type *p is.
Siri Cruise <chine.bleu@yahoo.com>: Feb 09 11:45AM -0800

In article <9da1ce32-7a51-4da6-a329-65c9b760e06e@googlegroups.com>,
> Or rather, why you should always check the pointer returned by this function.
> Most likely, you don't have a clue what's the catch with malloc, so we
> recommend looking through this article. https://www.viva64.com/en/b/0558/
 
64-bit MacOSX runs out of disk space before it runs out of heap memory. Malloc
doesn't fail--the process or system crashes.
 
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
I'm saving up to buy the Donald a blue stone This post / \
from Metebelis 3. All praise the Great Don! insults Islam. Mohammed
Vir Campestris <vir.campestris@invalid.invalid>: Feb 09 08:57PM

On 08/02/2018 22:17, Robert Wessel wrote:
 
> Now you *could* compress those addresses, especially in real mode to
> 20 bits, but that would have only been good for storing addresses, the
> processor could not use them for accessing memory.
 
The point is however that there are x86 architectures where
sizeof(void*) != sizeof(int). I suspect Josef has only used 32-bit x86
in flat address mode, and has probably never heard of a selector.
 
Me, I hope I never see one again!
 
Andy
legalize+jeeves@mail.xmission.com (Richard): Feb 09 09:03PM

[Please do not mail me a copy of your followup]
 
Josef Moellers <josef.moellers@invalid.invalid> spake the secret code
 
>You shouldn't ever cast malloc()'s result! [...]
 
In C++, std::malloc() returns void *, so it must be cast to some other
type for it to be useful.
--
"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>
Manjunatha <mlnaik.c21@gmail.com>: Feb 08 10:17PM -0800

Hi,
 
I want to build a C++ desktop application and I need to use HTML, JavaScript, and CSS for UI part. The UI part should contain Graphs, Charts etc.. I should take inputs from the C++ application asynchronously. The C++ application should be running continuously in the background, at the same time the output must be shown on the HTML page.
 
I need a sample desktop application that uses JavaScript to call a C++ application for input and then displays it on the HTML page (browser).
 
Thank you.
"Öö Tiib" <ootiib@hot.ee>: Feb 08 11:51PM -0800

On Friday, 9 February 2018 08:17:20 UTC+2, Manjunatha wrote:
 
> I want to build a C++ desktop application and I need to use HTML, JavaScript, and CSS for UI part. The UI part should contain Graphs, Charts etc.. I should take inputs from the C++ application asynchronously. The C++ application should be running continuously in the background, at the same time the output must be shown on the HTML page.
 
> I need a sample desktop application that uses JavaScript to call a C++ application for input and then displays it on the HTML page (browser).
 
> Thank you.
 
Web pages in browsers are rather well sand-boxed for security. So unless you
write web browser plugin you can't interact with any locally running
programs from a web-page in browser.
 
Making such plugin for each browser on each platform supported means
significant skill and manpower needed. One remotely capable would not
ask that question because far more hard is to reach such customer
trust level to deploy and install those (potential security hole)
plugins.
 
So best you can likely do is to write web service in C++, run that
service on local web server and interact like all web-pages interact
with web services. Typically over REST (client requests, service
responds) or WebSocket (both sides may send something actively).
Paavo Helde <myfirstname@osa.pri.ee>: Feb 09 01:53PM +0200

On 9.02.2018 8:17, Manjunatha wrote:
> Hi,
 
> I want to build a C++ desktop application and I need to use HTML, JavaScript, and CSS for UI part. The UI part should contain Graphs, Charts etc.. I should take inputs from the C++ application asynchronously. The C++ application should be running continuously in the background, at the same time the output must be shown on the HTML page.
 
> I need a sample desktop application that uses JavaScript to call a C++ application for input and then displays it on the HTML page (browser).
 
You can either integrate the browser into your desktop application or
have it a separate browser. For integrating one can use the MS
WebBrowser control in Windows, for example
("https://msdn.microsoft.com/en-us/library/system.windows.forms.webbrowser(v=vs.110).aspx")
which can be used from different languages like C# and C++. The
advantage is that you can manipulate the displayed web page
programmatically from inside the C++ program, and you can add other UI
elements to your app.
 
Alternatively, you could have a background C++ application and
displaying the UI in the standard browser. This would be more like a
standard web server, and the user interface would be just a normal web
page. The advantage here is that the browser and the server part can run
on different machines.
 
In both cases you will need a HTTP server component in your C++ part
which serves the browser requests. I highly recommend the Boost.asio
library, take one of their HTTP server examples and build on that.
Alternatively, you could take an existing web server like apache or
nginx and implement your application as a web server extension. As other
people have mentioned it is not clear that C++ would be the best main
language for such a project.
 
hth
Paavo
Thiago Adams <thiago.adams@gmail.com>: Feb 09 04:05AM -0800

See https://electronjs.org/
Dombo <dombo@disposable.invalid>: Feb 09 08:36PM +0100

Op 09-Feb-18 om 7:17 schreef Manjunatha:
> Hi,
 
> I want to build a C++ desktop application and I need to use HTML, JavaScript, and CSS for UI part. The UI part should contain Graphs, Charts etc.. I should take inputs from the C++ application asynchronously. The C++ application should be running continuously in the background, at the same time the output must be shown on the HTML page.
 
> I need a sample desktop application that uses JavaScript to call a C++ application for input and then displays it on the HTML page (browser).
 
You might want to take a look at:
https://www.webtoolkit.eu/wt
ram@zedat.fu-berlin.de (Stefan Ram): Feb 09 06:38AM

>I want to build a C++ desktop application and I need to use
>HTML, JavaScript, and CSS for UI part.
 
Here you write that you want to use HTML for the UI.
 
>I need a sample desktop application that uses JavaScript to
>call a C++ application for input
 
Now you want to call the C++ application for input?
So, now you want to use C++ for the UI?
 
Usually one would write the front-end in HTML and the
back-end in PHP or Java (as a web server, even if it is
running on the same desktop as the front-end). Other backend
languages could be Perl, Python or even JavaScript (again).
C++ is a bit too low-level for this purpose. You can use it
later for performance-critical parts.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 08 11:56PM

On 08/02/2018 00:50, Mr Flibble wrote:
 
> I've just finished implementing the neoGFX drop list / combo box widget:
 
> https://www.youtube.com/watch?v=nhqDVFQW_kE&feature=youtu.be
 
> neoGFX -- The Ultimate C++ GUI Library -- Coming Soon!
 
The neoGFX drop list widget now has hot tracking and other UX improvements:
 
https://www.youtube.com/watch?v=Ugx8FqVwxnw&feature=youtu.be
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 08 07:09PM -0500

On 2/8/2018 6:56 PM, Mr Flibble wrote:
>> https://www.youtube.com/watch?v=nhqDVFQW_kE
>> neoGFX -- The Ultimate C++ GUI Library -- Coming Soon!
 
> The neoGFX drop list widget now has hot tracking and other UX
improvements:
> https://www.youtube.com/watch?v=Ugx8FqVwxnw
 
"Looking good, Billy Ray."
"Feeling good, Louis."
 
https://thinkpurpose.files.wordpress.com/2016/11/wp-1480272739427.gif
https://thinkpurpose.files.wordpress.com/2016/11/wp-1480273153184.gif
 
--
Rick C. Hodgin
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Feb 08 08:29PM -0800

On 2/8/2018 4:09 PM, Rick C. Hodgin wrote:
> "Feeling good, Louis."
 
> https://thinkpurpose.files.wordpress.com/2016/11/wp-1480272739427.gif
> https://thinkpurpose.files.wordpress.com/2016/11/wp-1480273153184.gif
 
I second that. :^)
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)