Tuesday, December 19, 2017

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

fir <profesor.fir@gmail.com>: Dec 19 08:28AM -0800

I played game hyperballoid2 recently
(you may download it its quite kool game,
50 MB, checked no instals any malware
imo,
 
https://www.alawar.com/game/hyperballoid-2/
)
 
it has NxPhysics.dll (Novadex SDK) its version 2.1.2 dated from 2004
 
i would like to find some documentation for this dll, as it seems cool,
 
does maybe someone know where i could found it?
red floyd <dont.bother@its.invalid>: Dec 19 09:22AM -0800

On 12/19/2017 8:28 AM, fir wrote:
> [OT redacted]
 
Did you have a C++ language question?
Real Troll <real.troll@trolls.com>: Dec 19 01:30PM -0400

On 19/12/2017 16:28, fir wrote:
 
> does maybe someone know where i could found it?
 
How about contacting whoever released it. I know this sounds silly but
the original creator is the best place to start. Ask him/her if you
could have the source code!!!
 
Good luck.
David Brown <david.brown@hesbynett.no>: Dec 19 08:54AM +0100

On 18/12/17 19:03, fir wrote:
>> Is anyone doing anything with modules?
 
>> I watched two talks from Cppcon about modules:
 
>> https://duckduckgo.com/?q=cppcon+2017+boris&t=ffsb&iax=videos&ia=videos&iai=E8EbDcLQAoc
 
and another one that had to do with the gcc implementation
 
> in my world, there is a lot of modules, there are called dlls, (for
> example msvcrt.dll kernel32.dll bass.dll NxPhysics.dll green.fire.dll
> )
 
There are many things known as "modules". This thread is in c.l.c++, so
it is about C++ modules - these bare no more relation to DLL's on
Windows than they do to space station modules.
 
C++ modules will hopefully be part of C++20, and will replace or augment
the traditional .h and .cpp packaging with modules that can be compiled
- improving structure and modularity of C++ programs, and massively
improving build times compared to header-based template libraries.
 
fir <profesor.fir@gmail.com>: Dec 19 08:17AM -0800

W dniu wtorek, 19 grudnia 2017 08:55:03 UTC+1 użytkownik David Brown napisał:
 
> > there is a lot that can be said on those modules as this knowledge
> > related to them is very importnt, you may for example read my post
> > "granular upgrade" on comp.lang.c which is up to that
 
module concept and win32 dll perfectly covers
 
this module design (i mean what and how to divide on dlls and various aspect that do appear here) are very domain of knowledge
for good c coder
 
recently im interested in drivers, drivers are also just modules but have some specyfics which i feel i would like to know better
Ralf Goertz <me@myprovider.invalid>: Dec 19 09:22AM +0100

Am Mon, 18 Dec 2017 23:26:48 +0000 (UTC)
> features people like to use. I don't expect anyone to adapt to me,
> but I do find some uses of UTF-8 gratuitous with no value added,
> simply different.
 
You say that probably because for your native language there is no
difference between ASCII and UTF-8. For those of us less fortunate (or,
to put it differently, with a richer character set in their language) it
is a huge relief to have an encoding where you don't have to bother
about code pages and stuff like that. And after getting used to it I
found myself playing around with those other characters like „…"
(ellipsis in german style quotation marks) just because I can and it is
so much nicer. Spoiled by using LaTeX, I guess.
 
> Just like I find your preference to always use trailing return
> type :).
 
With that I agree ;-)
David Brown <david.brown@hesbynett.no>: Dec 19 11:09AM +0100

On 19/12/17 09:22, Ralf Goertz wrote:
> found myself playing around with those other characters like „…"
> (ellipsis in german style quotation marks) just because I can and it is
> so much nicer. Spoiled by using LaTeX, I guess.
 
There is no problem in using UTF-8 where it is /useful/. The issue is
with /gratuitous/ use of extra characters that makes it needlessly
difficult for some people. Not everyone is lucky enough to have Linux
with good fonts, and some people have much more limited systems.
 
The rule I suggest (and this is merely my opinion) is to use ASCII when
it suffices, and use UTF-8 for other cases. So if your surname is
actually spelt Görtz, then by all means write it that way - it is your
name, and should appear the way you want it to. However, using …
instead of ... or « » instead of " " or << >> adds nothing to the
information in a post (unless the thread is about typography and
characters).
 
It is a different matter for documents where appearance is more
relevant. You don't want to use simple quotation marks in a LaTeX
document - people might think you wrote the document in Word, and that
would be awful! (That's not sarcasm - I really am that snobby about
typography and document appearance. But everything in its place.)
 
So yes to /useful/ UTF-8, no to gratuitous non-ASCII.
 
Ralf Goertz <me@myprovider.invalid>: Dec 19 03:34PM +0100

Am Tue, 19 Dec 2017 11:09:46 +0100
> with /gratuitous/ use of extra characters that makes it needlessly
> difficult for some people. Not everyone is lucky enough to have Linux
> with good fonts, and some people have much more limited systems.
 
Okay, but are you suggesting that those harmless characters are not
available in other systems than linux? I don't talk about e.g. asian
alphabets (which /I/ can't read anyway) but typographic characters.
Can't we assume that in a computer oriented newsgroup like this people
know how to have UTF-8 displayed correctly after so many years that it
is around?
 
> when it suffices, and use UTF-8 for other cases. So if your surname
> is actually spelt Görtz, then by all means write it that way - it is
> your name, and should appear the way you want it to.
 
No, it is actually spelt Goertz which itself is a consequence of not
having around a "UTF-8 capable" typewriter when my father was born in
the 1930s outside of Germany. He regretted that very much all his life
whereas I was happy with it because it is easier when communicating with
non-German people. But the ö is a good example. You need UTF-8 for this
anyway. Okay there is iso*, but i you use non-ASCII characters anyway
one should use UTF-8. Seeing how those characters get messed up when
they are quoted by people not capable of handling them correctly makes
me said. How must Öö feel.
 
> However, using … instead of ... or « » instead of " " or << >> adds
> nothing to the information in a post (unless the thread is about
> typography and characters).
 
To my mind it is useful to have distinct characters to open and close a
quote. It helps clarity. It's not needed but it helps. Much like your
usage of two spaces after a sentence. This has always looked wrong for
me. Try using \frenchspacing. ;-) By the way using << and >> instead of
the (french?) quotation marks feels even more wrong (is that the right
comparative?). I associate those with much smaller/bigger.
 
> document - people might think you wrote the document in Word, and that
> would be awful! (That's not sarcasm - I really am that snobby about
> typography and document appearance. But everything in its place.)
 
I agree with you. Completely. But I think this /is/ the place.
David Brown <david.brown@hesbynett.no>: Dec 19 04:39PM +0100

On 19/12/17 15:34, Ralf Goertz wrote:
> Can't we assume that in a computer oriented newsgroup like this people
> know how to have UTF-8 displayed correctly after so many years that it
> is around?
 
I have no idea what sort of proportions of users have trouble displaying
such typographic UTF-8 characters. But I do know that older systems can
have challenges. A lot of fonts have common Western European characters
(like Latin-9 characters), such as accented letters - but relatively few
have extra typographical characters. Modern gui software can do a fair
job of font substitution so that even if you are normally using a font
without these characters, they can show them from other fonts.
 
However, there are people out there with older systems, or older
newsreaders, or with particular font settings that might cause
limitations. Linux has supported UTF-8 and associated fonts for ages -
in the Windows world, it is more recent (Windows has supported a variant
of UTF-16 for nearly two decades, but good UTF-8 support and good fonts
are not as old. Remember, Windows XP is the third most popular OS in
the world!).
 
Is it going to bother anyone if you use UTF-8 typographical symbols? I
don't know - probably not, or at least not many people. Maybe I'm just
old-fashioned. Maybe the percentage of people that can't see these
UTF-8 symbols is so small by now that it is irrelevant.
 
> one should use UTF-8. Seeing how those characters get messed up when
> they are quoted by people not capable of handling them correctly makes
> me said. How must Öö feel.
 
The difference here is that you /don't/ need a large UTF-8 font to show
a ö character. You just need a program that understands UTF-8 encoding,
and you need a font with that has that symbol. And lots of fonts do -
fonts for Western European languages, that have been around since the
days of MS-DOS, have it. So someone who is running XP and likes "MS
sans serif" will have no problem with ö, but will have difficulty with
directional quotation marks.
 
>> typography and characters).
 
> To my mind it is useful to have distinct characters to open and close a
> quote. It helps clarity. It's not needed but it helps.
 
If it helps clarity and reading, then fair enough - that is a good
reason to use them. But make sure it really helps. For example,
Stefan's use of » « quotations does not, IMHO, help clarity at all - it
hinders it. Along with his non-standard indentation and quoting, and
stunningly ugly coding style, his ideas of what makes a post clear mean
that I rarely bother reading them.
 
> Much like your
> usage of two spaces after a sentence. This has always looked wrong for
> me. Try using \frenchspacing. ;-)
 
I learned to type on a typewriter - a mechanical one! (I am not /that/
old, and had been programming before I decided to teach myself
touch-typing properly.) Double spaces at the end of a sentence look
good to me, even though I know they are a bit old fashioned. (There is
some controversy as to whether "French spacing" refers to single or
double spacing at the end of a sentence. But we know that Knuth is
always right :-) )
 
> By the way using << and >> instead of
> the (french?) quotation marks feels even more wrong (is that the right
> comparative?). I associate those with much smaller/bigger.
 
I think you have missed a bit of your sentence here...
 
>> would be awful! (That's not sarcasm - I really am that snobby about
>> typography and document appearance. But everything in its place.)
 
> I agree with you. Completely. But I think this /is/ the place.
 
Well, maybe we should end this off-topic sub-thread and start making
more use of UTF-8 characters in C++ posts. If it adds to readability
and people are happy viewing it, then I am quite ready to change my
mind. If people complain about funny symbols or question marks turning
up in the posts, then we will know that the c.l.c++ world is not yet
ready for UTF-8 !
ram@zedat.fu-berlin.de (Stefan Ram): Dec 19 12:19PM

>found myself playing around with those other characters like „…"
 
In the TeXbook (chapter 12) Donald E. Knuth writes:
 
|[I]f you try to specify `...' by typing three periods in a
|row, you get `...' - the dots are too close together. One way
|to handle this is to go into mathematics mode, using the
|\ldots control sequence defined in plain TeX format.
 
So he recommands a special code because a sequence of three
normal dots is "too close together".
 
Ironically, usually, in »…«, the dots are too close together
(here), while when one just types three dots »...« (in the
monospaced font often used in Newsreaders) they are apart
just fine.
ram@zedat.fu-berlin.de (Stefan Ram): Dec 19 01:48PM

main.cpp
 
#include <type_traits>
 
using stringtype = decltype( "abc" );
using stringtype1 = ::std::remove_reference_t< decltype( "abc" )>;
 
void fn( stringtype );
void fn1( stringtype1 );
 
int main(){ fn( "abc" ); fn1( "abc" ); }
 
transcript
 
undefined reference to `fn(char const (&) [4])'
undefined reference to `fn1(char const*)'
 
Notes:
 
Linker error messages can print types for you.
 
The decltype of "abc" is a reference, because string
literals are lvalues and »decltype« returns an lvalue
reference when its argument is an lvalue. In this case
there is no decay.
 
When the reference is then removed using
»::std::remove_reference_t« this also seems now to trigger
decay to a pointer and loss of the size information.
Ian Collins <ian-news@hotmail.com>: Dec 19 12:59PM +1300

On 12/19/2017 10:42 AM, Scott Lurndal wrote:
> the first template implementations with cfront, e.g. std::min/std::max
> generate code inline with simple comparision instructions with good
> optimizing compilers. Templates can be abused, however.
 
for loops can be abused as well, should we avoid those?
 
It's foolish to write of a chunk of a language because it can be abused.
Just don't abuse it...
 
--
Ian.
"Öö Tiib" <ootiib@hot.ee>: Dec 18 04:34PM -0800

On Monday, 18 December 2017 23:42:56 UTC+2, Scott Lurndal wrote:
> the first template implementations with cfront, e.g. std::min/std::max
> generate code inline with simple comparision instructions with good
> optimizing compilers. Templates can be abused, however.
 
Every tool can be abused. Modern human has indeed may be too flexible
mind and is too open to innovation. More complex tool is simpler
to misunderstand, harder to learn and has more ways to misuse. History
of our tool industry shows that it really took millions of years for
our ancestors to get somewhere. https://en.wikipedia.org/wiki/Stone_tool
;)
It is likely that C++ has gone overboard with incorporating various
complications into it but templates and constexpr really make it
simpler to achieve efficient results in practice ... especially when
not abused.
Thiago Adams <thiago.adams@gmail.com>: Dec 18 04:43PM -0800

On Monday, December 18, 2017 at 9:18:44 PM UTC-2, David Brown wrote:
...
> foo<unsigned int> don't both take space. And they will merge the same
> template-generated function across different translation units (unless
> the functions have been inlined, cloned, etc.).
..
I think this merge feature in Microsoft Visual C++ is done by
the linker and it works even for C.
Thiago Adams <thiago.adams@gmail.com>: Dec 18 05:13PM -0800

On Monday, December 18, 2017 at 9:04:59 PM UTC-2, Richard wrote:
> [Please do not mail me a copy of your followup]
?

> thiago.adams spake the secret code
> [..] thusly:
?

> >Generic code can be dangerous when you try to solve problems that you
> >don't have.
 
> Interesting. Can you provide an example?
 
I used a wrong word. It may be dangerous in some cases
where the specialization is not obvious or never tested.
However, what I was trying to say is that generic code can be
waste of time or make code unnecessarily complicated or obfuscated
trying to accept cases that you may not have.
 
Generic code is an strategy for code reuse. This strategy can be
a gamble or you already have use cases for each type of type.
Even when you know the type of type you are going to use
I think the code can be too complicated. I never liked the
policy design because I think it tries to make too much with
the same template class instead of split the problem
in more classes.
 
Once I wrote a parser generator. For the scanner, instead of
use std::string I used a type <T>. My intention was to allow
some super fast string append with some custom string allocated
on stack. I think this code was written in 2009.
I have never used this type T with a type different from std::string.
I just make the code more complicated.
Thiago Adams <thiago.adams@gmail.com>: Dec 18 05:19PM -0800

On Monday, December 18, 2017 at 9:25:20 PM UTC-2, Richard wrote:
...
> >for the equivalent of deleted constructor and operator =. This is
> >for windows and we don´t have a refactoring tool.
 
> clang-tidy is pretty much ubiquitous.
 
But this tool cannot remove old custom macros.
 
For large codebases a custom parser can be useful because
you can fix something in large scale. In this aspect I think
the C language is more convenient than C++. Although both have
the preprocessor, the C language is much simpler.
Gareth Owen <gwowen@gmail.com>: Dec 19 05:50AM


> for loops can be abused as well, should we avoid those?
 
> It's foolish to write of a chunk of a language because it can be
> abused. Just don't abuse it...
 
Given that (in the Linux kernel at least) most of the things that would
be templates in C++ are implemented with macros, I don't find the
"templates can be abused" argument very compelling either.
Ian Collins <ian-news@hotmail.com>: Dec 19 08:52PM +1300

On 12/19/2017 06:50 PM, Gareth Owen wrote:
 
> Given that (in the Linux kernel at least) most of the things that would
> be templates in C++ are implemented with macros, I don't find the
> "templates can be abused" argument very compelling either.
 
Indeed, macros have to be inline, so they can cause more bloat than
function templates which don't.
 
--
Ian.
David Brown <david.brown@hesbynett.no>: Dec 19 09:02AM +0100

On 19/12/17 01:43, Thiago Adams wrote:
> ..
> I think this merge feature in Microsoft Visual C++ is done by
> the linker and it works even for C.
 
I don't know about MSVC, but in gcc it is handled at two levels. In the
compiler, merging is done for functions (or sections of code) that match
in their internal structures, and can be done at various stages of
optimisation (the earlier it is done, the more efficient it is). In
linking, merging is done for functions with the same object code. Each
level has its advantages.
Juha Nieminen <nospam@thanks.invalid>: Dec 19 12:47PM

>>equivalent non-templated version (just compare std::sort with qsort,
>>for instance).
 
> And how many operating systems need a sort function?
 
Are going to ask that same question for every single simple example
that could be given?
 
> I suspect that anything that can be done with constexpr in C++ can also be
> done in C, if less cleanly, with preprocessor macros.
 
Only if you are willing to either generate the code by hand (and do so again
every single time some parameter changes), or write a separate code generator
program, which you integrate into the building process of the entire project.
 
As a simple example, with constexpr functions and objects you can generate
an array of precalculated values (using some functions) at compile time,
rather than having to calculate these values at runtime.
Christopher Pisz <christopherpisz@gmail.com>: Dec 18 04:15PM -0800

The following assert is failing. Is this a known thing with standard c++ or with the compiler I happen to be using?
 
 
class S1
{
public:
int m1;
char m2;
char m3;
};
 
class S2
{
public:
int m1;
char m2;
public:
char m3;
};
 
int main()
{
assert(sizeof(S1) == sizeof(S2));
}
"Öö Tiib" <ootiib@hot.ee>: Dec 18 04:47PM -0800

On Tuesday, 19 December 2017 02:15:48 UTC+2, Christopher Pisz wrote:
> {
> assert(sizeof(S1) == sizeof(S2));
> }
 
It must be the compiler that you are using since I can't reproduce it
with any I can reach.
 
C++ does not have concept of "layout-compatible types" like C has so
I think the behavior is legal and does not violate standards.
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Dec 18 05:03PM -0800

On 12/18/2017 4:15 PM, Christopher Pisz wrote:
> {
> assert(sizeof(S1) == sizeof(S2));
> }
 
What compiler are you using? Keep in mind that these are not POD's.
 
Here is a little program:
______________________
#include <cassert>
#include <iostream>
 
class S1
{
public:
int m1;
char m2;
char m3;
};
 
class S2
{
public:
int m1;
char m2;
public:
char m3;
};
 
int main()
{
std::cout << "sizeof(S1) == " << sizeof(S1) << "\n";
std::cout << "sizeof(S2) == " << sizeof(S2) << "\n";
assert(sizeof(S1) == sizeof(S2));
return 0;
}
______________________
 
So far, I cannot get it to trip the assert.
Ian Collins <ian-news@hotmail.com>: Dec 19 02:16PM +1300

On 12/19/2017 01:15 PM, Christopher Pisz wrote:
> {
> assert(sizeof(S1) == sizeof(S2));
> }
 
 
It looks like a bug - they should have the same layout if all the
members have the same access control. Which compiler was this?
 
Try adding
 
#include <type_traits>
 
static_assert( std::is_standard_layout<S1>::value,
"S1 not standard layout" );
static_assert( std::is_standard_layout<S2>::value,
"S2 not standard layout" );
static_assert( sizeof(S1) == sizeof(S2),
"S1 and S2 differ");
 
and see what you get.
 
--
Ian.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 19 07:59AM +0100

On 12/19/2017 2:16 AM, Ian Collins wrote:
>> }
 
> It looks like a bug - they should have the same layout if all the
> members have the same access control.
 
With C++11 rules yes. With C++03 it was about an "intervening access
specifier", IIRC.
 
 
Cheers!,
 
- Alf
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)