"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 01 12:49AM +0200
On 31.03.2016 20:44, Stefan Ram wrote:
> I observed that with GCC 5.1.1 and »-std=c++17«, I can write
> »if( s )« even though operator bool is explicit in »eta«.
`explicit` operator `bool` is implicitly invoked for an expression
that's used where the syntax requires a (C++ grammar) /condition/.
So, it's not perfect, but it's backward-compatible.
If you really want a conversion to `bool` that can only be explicitly
invoked, then the easiest is to use a named operation, e.g. `is_good`.
Alternatively, one can use a Rube Goldberg scheme with `operator
Private_member_ptr`, which doesn't convert to `void*`, so doesn't foul
up overload resolution in general, but which does convert to `bool`.
<code>
#include <iostream>
using namespace std;
class S
{
private:
enum Private {};
using Private_memptr = void(S::*)(Private);
void True( Private ) {}
public:
auto is_good() const -> bool { return true; }
operator Private_memptr() const
{ return (is_good()? &S::True : nullptr); }
};
void foo( void const* ) { cout << "foo(ptr)" << endl; }
void foo( ... ) { cout << "foo(...)" << endl; }
auto main()
-> int
{
S const o;
foo( o ); // Invokes "foo(...)".
if( o ) { cout << "Condition worked!" << endl; }
bool const b = o; // Converts even if this isn't a "condition".
(void) b;
#ifdef GAH
int const x = o; // !Doesn't convert.
(void) x;
SORRY! That I clicked WRONG address and sent this email by mistake!
PLEASE JUST DELETE IT. THANKS. SORRY,!
Sent from my iPad
Begin forwarded message:
Dear MEIMEI
Just a note to say HELLO and we MISS YOU.
Also wish to make sure our letter has reached you safely.
We LOVE you
奶奶爺爺
Sent from my iPad
Dear MEIMEI
Just a note to say HELLO and we MISS YOU.
Also wish to make sure our letter has reached you safely.
We LOVE you
奶奶爺爺
Sent from my iPad
bleachbot <bleachbot@httrack.com>: Mar 30 07:27PM +0200
|
"Heinz-Mario Frühbeis" <Div@Earlybite.individcore.de>: Mar 30 09:04PM +0200
Am 30.03.2016 um 17:25 schrieb Geoff:
>>>>>>>> Am 27.03.2016 um 15:03 schrieb Alf P. Steinbach:
>>>>>>>>> On 27.03.2016 11:17, Heinz-Mario Frühbeis wrote:
>> [...]
[...]
> Since you were copying a const char *nString, I assumed you knew where
> it was coming from and would obtain the lock on that string before
> copying it to the local mutable string for manipulation.
I know, what I experience... std::string.c_str works, std::string not.
Regards
Heinz-Mario Frühbeis
| Dombo <dombo@disposable.invalid>: Mar 30 09:59PM +0200
Op 30-Mar-16 om 16:38 schreef Mr Flibble:
>> That makes a big difference in efficiency.
> x is a constant though so it makes no difference as far as algorithmic
> "efficiency" (complexity) is concerned.
But it does make a difference as far as effective speed and memory
fragmentation is concerned.
| Mr Flibble <flibble@i42.co.uk>: Mar 30 09:23PM +0100
On 30/03/2016 20:59, Dombo wrote:
>> "efficiency" (complexity) is concerned.
> But it does make a difference as far as effective speed and memory
> fragmentation is concerned.
You can use a custom allocator with std::list to avoid fragmentation;
without a custom allocator std::deque also suffers from fragmentation.
/Flibble
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 30 11:15PM +0200
On 30.03.2016 21:04, Heinz-Mario Frühbeis wrote:
> I know, what I experience... std::string.c_str works, std::string not.
Sorry, with C++ this is not sufficient. You have to know whether and why
something works and something does not. If you do not know and do not
want to learn, please choose another language, with less Undefined Behavior.
Cheers
Paavo
| "Öö Tiib" <ootiib@hot.ee>: Mar 30 02:26PM -0700
On Wednesday, 30 March 2016 22:04:42 UTC+3, Heinz-Mario Frühbeis wrote:
> I know, what I experience... std::string.c_str works, std::string not.
And we know that you are incorrect. The code that you posted
should not compile on C++ compiler. It is full of odd screaming
syntax errors. Your code, my comments added:
std::string string_var;
if(string_var.length() > 0)
// FINE ... you wrote ERROR
{}
if(strlen(string_var.c_str) > 0)
// ERROR: invalid use of member function 'c_str' ... you wrote NO ERROR
{}
if(string_var == "HALLO"() > 0)
// ERROR: string literal can't be called as function ... you wrote ERROR
{}
if(string_var.c_str == "HALLO")
// ERROR: invalid use of member function 'c_str' ... you wrote NO ERROR
{}
So you either experience troll lulz from responses of you pretending
ignorance or you really write such kooky voodoo code and anything you
experience with it is only within your imagination.
| jt@toerring.de (Jens Thoms Toerring): Mar 30 09:34PM
>> if you don't own the lock on it you are not thread safe. Your
>> experiment is flawed and your statement above is incorrect.
> I know, what I experience... std::string.c_str works, std::string not.
Please take a deep breath, relax and consider for just a moment
that you may have misunderstood a number of things: unfortunately,
your "experience" is completely irrelevant here as programming is
not an experimental science. Just because something happens with
a lower probability (e.g. the problems you experienced with a C
arrays compared to a C++ std::string) and you thus may not yet have
experienced it is no proof that it can't happen. What you say is
a bit like "experimental mathematics": 3 is a prime, 5 is a prime,
7 is a prime, thus, according to "experience", all odd numbers are
prime;-)
If you use threads and a thread can modify an object while another
thread accesses it (even just for reading) at the same time you've
got a massive problem, called a "race condition" (do yourself a
favour and look it up). These problems are insidious because they
are non-deterministic - most of the time it looks as if everything
is fine and dandy (because most of the time there's just one thread
doing anything with the object), but once in a while something
strange will happen but can't be reproduced. Threads are nice and
all, but they come with their own set of requirements to work pro-
perly: you either have to operate on "atomic" objects or obtain
locks while accessing them when there's even the slightest chance
that this object could be accessed by a different thread simulta-
nously. Everything else is simply a recipe for disaster.
A function can be "thread-safe", which just means that it will
work properly when two different threads call it at the same
time. But (with very few exceptions) objects aren't (neither a C
array nor a C++ std::string is) - only objects that can be acces-
sed "atomically" are - and there are very few of that kind (and
what is an "atomic" types can differ on different machines, so
that's another realm where your "experience" you gained on one
platform is, unfortunately, worth zilch).
And - BTW and out of context - one other of your code snippets
from a different thread
if (my_string.c_str() == "HELLO") {
....
}
is very unlikely to do what you seem to think it does. It com-
pares the address of where the 'my_string' std::string object
has stored it's string to where the compiler has stored the
non-modifiable C string "HELLO". That's rather unlikely to be
what you really want to know: from the looks of it you want to
know if these strings have the same content. But that's a dif-
ferent question and would require the use of the strcmp() func-
tion.
if (my_string == "HELLO")
and
if (my_string.c_str() == "HELLO")
may look similar (up to the point of getting fooled into assu-
ming that they are equivalent), but what they actually test for
is very, very different.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
| jacobnavia <jacob@jacob.remcomp.fr>: Mar 30 08:38PM +0200
Le 30/03/2016 18:14, Scott Lurndal a écrit :
>> Please, there is NO comparison here!
> Wrong group for this argument. Suffice it to say
> horses for courses.
Tex is used in scientific journals like astronomy and astrophysics. It
is the work of D. Knuth, someone I profoundly respect. The independence
of TeX from the machine, and many other things of TeX makes it a unique
creation.
Obviously nroff has the same stuff, and many other text handling
programs (probably, I do not really know nroff that well) but in a
mathematical way, TeX is relly something.
I remember when it appeared, the bugs of Knuth, his analysis of those
bugs, those wonderfully typesetted programming books that Knuth wrote.
Mostly sentimental reasons as you see.
| jacobnavia <jacob@jacob.remcomp.fr>: Mar 30 10:07PM +0200
Le 30/03/2016 18:23, Keith Thompson a écrit :
> hashtable.c:383:15: note: 'HashIdx' was declared here
> HashIndex HashIdx,*hi;
> ^
This comes because the code analyzer of gcc fails to realize that this
data is initialized in the call to getfirst in function Clear
> integer expressions [-Wsign-compare]
> if (h->Log2N == -1 || h->count > (1 << h->Log2N)) {
> "-std=c99" gives similar results.
OK. Thanks I will look at that one later
> One more minor problem: "make clean" doesn't remove "test.o".
OK. Thanks
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Mar 30 08:47PM +0200
On 30.03.16 19.07, Bo Persson wrote:
[VM with git vs. C++]
> So, to have optimal performance you either download an executable
> specifically optimized for your system, or a JVM with specific
> optimizations for your system.
Except that the latter has to be done only once for each platform while
the optimized executable has to be build for the cross product of
platforms and applications.
In real live no one does the latter. Even common Linux distributions
target only roughly the hardware. So many new CPU features are unused by
most of the applications. Some exceptions prove the rule, of course.
E.g. the FFTW library comes with optimized assembler code for many
architectures.
Marcel
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 30 06:56PM
On Tue, 2016-03-29, Christopher Pisz wrote:
> in C++?
> My office mate is arguing with me that C# is now more portable than C++,
> because...mono. He is making me angry.
You should be mildly amused and secretly condescending. Problem
solved!
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
|
Geoff <geoff@invalid.invalid>: Mar 29 05:09PM -0700
On Tue, 29 Mar 2016 18:36:05 +0200, Paavo Helde
>> What are the advantages/disadvantages?
>If it works and there is no need to add features or change
>functionality, then there is not much reason to convert anything.
It works very well and there are no features to add.
>With std::vector, sorting and removing would then become:
> std::sort(Tx.begin(), Tx.end());
> Tx.resize(newsize);
This would be most likely, since access speed to the array is critical
to the speed of the computations.
> - no arbitrary limit of 1000 elements
> - no fear of buffer overrun
> - no need to track the actual size in a separate variable
These reasons we in my mind while considering the question.
>pointers to them.
> - serialization needs to be rewritten a bit to work without the
>terminator.
The 1000 limit was chosen to limit the study. As it stands, a 1000 x
1000 array can take dozens of hours to compute all the products on a
modern platform. Back when this was written, a 400MHz i486 was a fast
machine and it would take several days.
>address is important) or you need things like splice. In this usage
>scenario I do not see any need to use std::list, it would just combine
>the worst properties of std::vector and std::set (for this scenario).
I think I'd have to test and measure the speeds of analysis of an
array compared with a std::vector before committing to it.
Thank you for your well-considered reply.
| Juha Nieminen <nospam@thanks.invalid>: Mar 30 06:19AM
> std::set in my codebase: not all lists need to be ordered.
> Just because YOU are unfamiliar with the common use-cases for std::list
> does not mean that std::list is redundant.
I am perfectly aware of how linked lists work, and what their advantages
and disadvantages are.
Yet, I have not used std::list since forever, for the simple reason that
I have never needed it. I remember using it in one serious project for
university, where it was actually necessary (the algorithm in question was
explicitly designed to work with fast splicing of linked lists). But
that's about it.
The problem with std::list is that it consumes more memory, adding
elements to it is slower (because memory allocation is slow), and it
easily gets fragmented in memory, potentially adding to the slowness
of even element access. (This slowness does not technically speaking
affect its asymptotic complexity, but slowness is slowness.)
Perhaps you are too reliant on pointers/iterators all over the place,
outliving their creation scope?
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
| Juha Nieminen <nospam@thanks.invalid>: Mar 30 06:22AM
> std::deque also makes O(n) memory allocations like std::list and
> std::set so you clearly do not know what you are talking about.
But std::deque makes n/x memory allocations while std::list makes n.
That makes a big difference in efficiency.
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
| "Heinz-Mario Frühbeis" <Div@Earlybite.individcore.de>: Mar 30 09:58AM +0200
Am 28.03.2016 um 22:12 schrieb Geoff:
>>>>> On Sun, 2016-03-27, Heinz-Mario Frühbeis wrote:
>>>>>> Am 27.03.2016 um 15:03 schrieb Alf P. Steinbach:
>>>>>>> On 27.03.2016 11:17, Heinz-Mario Frühbeis wrote:
[...]
> cout.flush();
> return 0;
> }
std::string (of its own; not c_str) is *not thread safe...
Yes, you can store a member var as std::string, but e.g. within a
callback function e.g. from a loop which is runnnung in a pthread, you
can only use c_str, also *not length(). Else, undef behaviour, or even
crash...
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 30 11:20AM +0200
On 30.03.2016 09:58, Heinz-Mario Frühbeis wrote:
> callback function e.g. from a loop which is runnnung in a pthread, you
> can only use c_str, also *not length(). Else, undef behaviour, or even
> crash...
I'm sorry, that's bollocks. The threading issues are the same with
`std::string` as with C style strings. If some code is unsafe with the
former, then its unsafe with the latter, and vice versa, except that its
easier to introduce bugs with C style strings.
Cheers & hth.,
- Alf
| "Heinz-Mario Frühbeis" <Div@Earlybite.individcore.de>: Mar 30 01:09PM +0200
Am 30.03.2016 um 11:20 schrieb Alf P. Steinbach:
> former, then its unsafe with the latter, and vice versa, except that its
> easier to introduce bugs with C style strings.
> Cheers & hth.,
Here, I have a XLib-Event-Loop running in a pthread and *every access on
std::string in a callback-function from this loop results in an error,
except I'm using c_str!
E.g.:
std::string string_var;
if(string_var.length() > 0){ // ERROR
}
if(strlen(string_var.c_str) > 0){ // NO ERROR
}
if(string_var == "HALLO"() > 0){ // ERROR
}
if(string_var.c_str == "HALLO"){ // NO ERROR
}
To me, it seems to be the same behaviour like XLib has...
Regards
Heinz-Mario Frühbeis
| "Öö Tiib" <ootiib@hot.ee>: Mar 30 04:31AM -0700
On Wednesday, 30 March 2016 10:59:04 UTC+3, Heinz-Mario Frühbeis wrote:
> callback function e.g. from a loop which is runnnung in a pthread, you
> can only use c_str, also *not length(). Else, undef behaviour, or even
> crash...
You seem to claim that 'char' array is more thread safe than 'std::string'.
That is dangerous nonsense. Only very few things that are immutable
whole program run are thread safe (constexpr, static const and string
literals). In C++ it is *possible* to make rest of things thread safe.
However that is it. Read up on C++ memory model.
| "Öö Tiib" <ootiib@hot.ee>: Mar 30 04:35AM -0700
On Wednesday, 30 March 2016 14:09:38 UTC+3, Heinz-Mario Frühbeis wrote:
> if(string_var.c_str == "HALLO"){ // NO ERROR
> }
> To me, it seems to be the same behaviour like XLib has...
Huh? What you now posted should not compile in C++.
It seems full of strange syntax errors.
There must be no way to run it. Stop the nonsense, please.
| Mr Flibble <flibble@i42.co.uk>: Mar 30 03:38PM +0100
On 30/03/2016 07:22, Juha Nieminen wrote:
>> std::set so you clearly do not know what you are talking about.
> But std::deque makes n/x memory allocations while std::list makes n.
> That makes a big difference in efficiency.
x is a constant though so it makes no difference as far as algorithmic
"efficiency" (complexity) is concerned.
/Flibble
| Mr Flibble <flibble@i42.co.uk>: Mar 30 03:42PM +0100
On 30/03/2016 07:19, Juha Nieminen wrote:
> university, where it was actually necessary (the algorithm in question was
> explicitly designed to work with fast splicing of linked lists). But
> that's about it.
If you have only used std::list once in your entire career then it is
painfully obvious that you are not aware of (or stubbornly ignore) its
advantages.
> easily gets fragmented in memory, potentially adding to the slowness
> of even element access. (This slowness does not technically speaking
> affect its asymptotic complexity, but slowness is slowness.)
std::set, std::multiset, std::map and std::multimap also have a single
node based allocation strategy so are you suggesting we shouldn't use
these containers either as they are "slow"? Besides, the allocation
problems of which you speak can be mostly mitigated against through the
use of a custom allocator such as one of the Boost pool allocators which
should, IMO, be part of C++.
> Perhaps you are too reliant on pointers/iterators all over the place,
> outliving their creation scope?
No more than I should be.
/Flibble
| Geoff <geoff@invalid.invalid>: Mar 30 08:25AM -0700
On Wed, 30 Mar 2016 09:58:54 +0200, Heinz-Mario Frühbeis
>callback function e.g. from a loop which is runnnung in a pthread, you
>can only use c_str, also *not length(). Else, undef behaviour, or even
>crash...
If you are using memmove or strlen without obtaining appropriate locks
then you are not thread safe. It makes no difference if you are using
the c_str member or not, you are still accessing the same object and
if you don't own the lock on it you are not thread safe. Your
experiment is flawed and your statement above is incorrect.
Thread safety is YOUR problem, not the functions and not the objects
(necessarily). You asked about string manipulation and splitting and
presented non-threaded C code. I showed you an example of a
non-threaded C++ way to do it. Thread safety is a separate issue.
Since you were copying a const char *nString, I assumed you knew where
it was coming from and would obtain the lock on that string before
copying it to the local mutable string for manipulation.
| woodbrian77@gmail.com: Mar 30 10:51AM -0700
On Wednesday, March 30, 2016 at 9:42:45 AM UTC-5, Mr Flibble wrote:
> If you have only used std::list once in your entire career then it is
> painfully obvious that you are not aware of (or stubbornly ignore) its
> advantages.
Whatever.
> problems of which you speak can be mostly mitigated against through the
> use of a custom allocator such as one of the Boost pool allocators which
> should, IMO, be part of C++.
There's junk in the standard that should be removed and
there are some things that should have been added years
ago. The standard adds "any" but what about something
useful like pool allocators? Leave out the good stuff and
throw in some junk. More about this after the next paragraph.
Chandler Carruth gave a talk a few years ago about data
structures and performance. He said he despises std::map.
I agree with that.
Maybe this is like a Scooby Doo cartoon where a group
of friends is out playing and they run into a crook.
They put the pieces of the puzzle together and they
eventually catch up to the crook and take off his
mask. Then they are stunned to realize it's someone
they thought they knew. I think Chandler, Andrei A.
Bjarne S. and myself are some of the good guys. I have
hope for people here to go in the right path also,
but it's not clear yet to me what they will do. I
understand Andrei A.'s effort to be a trailblazer. If
that doesn't work out, I hope he will come back to C++.
I could name some people I think are suspect, but am not
sure that would help.
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
| legalize+jeeves@mail.xmission.com (Richard): Mar 30 01:11AM
[Please do not mail me a copy of your followup]
Christopher Pisz <nospam@notanaddress.com> spake the secret code
>the interpreter exists, but that's what 3 or 4 platforms? There are
>probably thousands if not millions of pieces of hardware out there that
>utilize C++.
I always chuckle when I install the Java runtime and it shouts "3
billion devices run Java!". The number for C++ is probably something
like 300 billion, but because there is no "C++ SDK" or "C++ Virtual
Machine" from a single company that you have to install, there isn't
any shouting from the rooftops how ubiquitous C++ is in modern
computing.
Where does C++ run? Everywhere.
What runs C++? Everything.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
| Johann Klammer <klammerj@NOSPAM.a1.net>: Mar 30 09:22AM +0200
On 03/29/2016 10:27 PM, Christopher Pisz wrote:
> Does there exist a list of operating systems/hardware that I can target in C++?
> My office mate is arguing with me that C# is now more portable than C++, because...mono. He is making me angry.
Isn't mono another one of those platforms that emulate a non-existent architecture and
the emulator runs only on a very small subset of actually existing architectures?
(like java?)
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Mar 30 01:11PM +0200
On 30.03.16 09.22, Johann Klammer wrote:
> Isn't mono another one of those platforms that emulate a non-existent architecture and
> the emulator runs only on a very small subset of actually existing architectures?
> (like java?)
Mono and Java are essentially the same. Only the ecosystem around them
is quite different. Most sufficiently powerful computer can deal with
both of them.
However, if you talk about "existing architectures" and include embedded
devices, you are right. This will not work mostly. Just because the VMs
are too bulky - for now...
Btw. neither the Mono nor the Java VM emulates any hardware. They are
just JIT platforms where the compiler to assembly language always runs
on the target platform. So the binaries are only an intermediate
language. The important advantage is that this binaries are /not/
platform dependent and, of course, the compiler can use hardware
specific optimization which are impossible when you deliver executables
for a series of platforms like x86 or arm64.
The result is similar than distributing your C++ application as source
code. But without all the drawbacks of compile time source code
incompatibilities and so on.
Of course the intermediate language (or Java Byte Code) is the least
common denominator. You can't do any hacks that won't fit into this
standard (mostly platform specific hacks).
If you look how gcc internally works it does basically the same. It
parses the C++ code into formal execution trees (to some degree
comparable to the Mono IL) and in the second stage the machine code for
the target platform is generated. This is part of the success story of
gcc. If a new language feature is required you only change the first
stage (mostly), then the feature is available on all platforms. If you
port gcc to a new platform you only implement the second stage, and you
get all the language features. AFAIK LLVM works similar (as the name
suggests).
Btw.: the concept of the Transmeta CPUs is similar too. It morphs the
code into platform specific RISC code. The coffin nail was that they
used the (horrible) x86 instruction set as intermediate language.
All modern x64 CPUs operate similar, but they do not write the result
back into memory because the decoder stages are realized in hardware and
operate on the fly.
Btw.2: I am quite sure, as long as C++ code do not use the ugly (and
often platform dependent) reinterpret casts, it could be compiled into
intermediate language too. But probably there is no much existing C++
application around that satisfies this restriction.
Marcel
| Bo Persson <bop@gmb.dk>: Mar 30 07:07PM +0200
On 2016-03-30 13:11, Marcel Mueller wrote:
> platform dependent and, of course, the compiler can use hardware
> specific optimization which are impossible when you deliver executables
> for a series of platforms like x86 or arm64.
The supposed JIT advantage really isn't any advantage at all, as a C++
compiler can produce code for any specific system of its choice.
For example, gcc has TONS of options specifically for doing that:
https://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html#Submodel-Options
So, to have optimal performance you either download an executable
specifically optimized for your system, or a JVM with specific
optimizations for your system.
Big deal! :-)
Bo Persson
| Wouter van Ooijen <wouter@voti.nl>: Mar 30 07:13PM +0200
Op 30-Mar-16 om 7:07 PM schreef Bo Persson:
> specifically optimized for your system, or a JVM with specific
> optimizations for your system.
> Big deal! :-)
The deal is that in order to be able to dowload a version of the app
specific for your system such a version must exits. For N apps and M
systems that means N * M executables.
For the JIT version it requires N 'executables' + M JIT compilers.
Wouuter van Ooijen
(A big C++ fan, but also a big Python user)
| jacobnavia <jacob@jacob.remcomp.fr>: Mar 30 03:03PM +0200
https://github.com/jacob-navia/ccl.git
There you will find all the source code and the source code of the
dopcumentation in TeX form (the only word processor of the 80es that is
still running today and will run in 2030)
The C Containers library is a replica of the STL written in plain C.
jacob
| scott@slp53.sl.home (Scott Lurndal): Mar 30 03:11PM
>There you will find all the source code and the source code of the
>dopcumentation in TeX form (the only word processor of the 80es that is
>still running today and will run in 2030)
troff is a word processor of
the 70's that is still running today, and will continue to
run through 2030, and is still the foundation of manual pages
on unix/linux systems.
If you are documenting source code, then you should at minimum
provide doxygen comments in the source.
| Randy Howard <rhoward.mx@EverybodyUsesIt.com>: Mar 30 10:30AM -0500
On 3/30/16 8:03 AM, jacobnavia wrote:
> There you will find all the source code and the source code of the
> dopcumentation in TeX form (the only word processor of the 80es that is
> still running today and will run in 2030)
Is "dopcumentation" an artifact of an archaic word processor? ;-)
Btw, I'm completely convinced that other word processors from that era
are still running today and will still be runnable in 2030. But don't
let that get in the way of grinding the axe for your favorite one.
> The C Containers library is a replica of the STL written in plain C.
Thanks for the warning.
Out of curiosity, is it really written in plain C, or that 'almost C'
flavor you like?
--
Randy Howard
(replace the obvious text in the obvious way if you wish to contact me
directly)
| Randy Howard <rhoward.mx@EverybodyUsesIt.com>: Mar 30 10:33AM -0500
On 3/30/16 10:11 AM, Scott Lurndal wrote:
> the 70's that is still running today, and will continue to
> run through 2030, and is still the foundation of manual pages
> on unix/linux systems.
Or perhaps nroff.
> If you are documenting source code, then you should at minimum
> provide doxygen comments in the source.
Seriously? doxygen is a train wreck.
--
Randy Howard
(replace the obvious text in the obvious way if you wish to contact me
directly)
| jacobnavia <jacob@jacob.remcomp.fr>: Mar 30 06:01PM +0200
Le 30/03/2016 17:11, Scott Lurndal a écrit :
> the 70's that is still running today, and will continue to
> run through 2030, and is still the foundation of manual pages
> on unix/linux systems.
You are comparing TeX to troff?
How about mathematical formulae?
How about QUALITY?
Please, there is NO comparison here!
| scott@slp53.sl.home (Scott Lurndal): Mar 30 04:12PM
>> run through 2030, and is still the foundation of manual pages
>> on unix/linux systems.
>Or perhaps nroff.
It's the same source language - troff generates typesetter output (now postscript)
and nroff generates terminal output.
>> If you are documenting source code, then you should at minimum
>> provide doxygen comments in the source.
>Seriously? doxygen is a train wreck.
YMMV.
| scott@slp53.sl.home (Scott Lurndal): Mar 30 04:14PM
>> on unix/linux systems.
>You are comparing TeX to troff?
>How about mathematical formulae?
man eqn(1) for the small subset of documents requiring math formulae.
man pic(1) for diagrams
man tbl(1) for tables
man dformat(1) for data structure documentation
mqn grap(1) for graphs
>How about QUALITY?
Missing definition noted.
>Please, there is NO comparison here!
Wrong group for this argument. Suffice it to say
horses for courses.
| Keith Thompson <kst-u@mib.org>: Mar 30 09:23AM -0700
(I'm not sure this belongs in comp.lang.c++, but I'll leave the
newsgroups list as it is for now.)
>> There you will find all the source code and the source code of the
>> dopcumentation in TeX form (the only word processor of the 80es that is
>> still running today and will run in 2030)
[...]
> Thanks for the warning.
> Out of curiosity, is it really written in plain C, or that 'almost C'
> flavor you like?
It appears to be plain C. When I modify the Makefile to use
-std=c11 -pedantic -Wall -Wextra -O3
with gcc 5.3.0, I get a number of unused parameter warnings.
(I haven't looked into them, but that's probably to be expected
for this kind of thing.) Adding
-Wno-unused-parameter
leaves two warnings:
hashtable.c: In function 'Clear':
hashtable.c:696:27: warning: 'HashIdx.ht' is used uninitialized in this
function [-Wuninitialized]
if (hi->index > hi->ht->max)
^
hashtable.c:383:15: note: 'HashIdx' was declared here
HashIndex HashIdx,*hi;
^
and:
priorityqueue.c: In function 'checkcons':
priorityqueue.c:418:36: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
if (h->Log2N == -1 || h->count > (1 << h->Log2N)) {
"-std=c99" gives similar results.
One more minor problem: "make clean" doesn't remove "test.o".
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
|
bleachbot <bleachbot@httrack.com>: Mar 29 06:49PM +0200
|
legalize+jeeves@mail.xmission.com (Richard): Mar 29 09:17PM
[Please do not mail me a copy of your followup]
Christopher Pisz <nospam@notanaddress.com> spake the secret code
>Does there exist a list of operating systems/hardware that I can target
>in C++?
All of them.
>My office mate is arguing with me that C# is now more portable than C++,
>because...mono. He is making me angry.
Every other language sits on top of some layer that is either C or C++.
Since C++ can be written to be link compatible with C that means that
C++ targets all the operating systems. The barrier is more one of
tools that target the operating system than it is of languages.
Anything that can run Mono (how do you think Mono itself is built?) is
going to run C++ applications as well because.... guess what? Mono is
written in C. For instance look in the io-layer folder for Mono on
github: <https://github.com/mono/mono>. It's all C code.
Microsoft VS team gave out a shirt one year that said "My compiler
compiled yours" referring to the fact that the C# compiler was written
in C++. They've since got a self-hosting compiler for C# written in
C#, but something has to bootstrap that process and the bottom layer
in that bootstrap is almost certainly C or C++.
About the only "operating system" I can think of that can't be
targetted directly with C++ are those systems where the language is
the operating system. A small embedded FORTH implementation uses
assembly language to bootstrap up a minimal FORTH dictionary and then
the rest of it is all written in FORTH. Open Firmware is an
initiative that works this way.
<https://en.wikipedia.org/wiki/Open_Firmware>
Another example might be something like a LISP Machine, where
everything is written in LISP.
<https://en.wikipedia.org/wiki/Lisp_machine>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
| legalize+jeeves@mail.xmission.com (Richard): Mar 29 09:36PM
[Please do not mail me a copy of your followup]
(Richard) legalize+jeeves@mail.xmission.com spake the secret code
>going to run C++ applications as well because.... guess what? Mono is
>written in C. For instance look in the io-layer folder for Mono on
>github: <https://github.com/mono/mono>. It's all C code.
In anticipation of nitpicks:
The bottom layer of the mono runtime is written in C (you'd think
they'd have chosen C++, but whatever).
The mono C# compiler is written in C#, but it needs the mono runtime
to run. To bootstrap everything from source, and not prebuilt mono
runtimes, you need a C compiler.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Mar 29 11:52PM +0200
On 29.03.16 22.27, Christopher Pisz wrote:
> Does there exist a list of operating systems/hardware that I can target
> in C++?
Probably it will be much more difficult to find any recent OS that does
/not/ support C++.
> My office mate is arguing with me that C# is now more portable than C++,
It is more portable because the included class library has more built-in
features (e.g. networking) than the C++ runtime. Although that changed a
bit with C++11 where things like threads are now also part of the standard.
> because...mono. He is making me angry.
Portable != supported. Any C/C++ application that uses more than the
standard library is not really portable. You need to have some platform
specific code. In practice this applies to really any larger
application, although the non portable code might be small.
But with Mono/.NET you can run into the same trouble. E.g. MS will it
make easy to write non-portable code, e.g. as soon as you use WPF or
something like that.
On the other side C++ has the risk of unchecked memory access and UB.
Although this is quite small if you really write C++ code, but in
practice much existing code lacks of C++ since it uses char*, pointer
arithmetic and other bad things all over.
So nearly always the discussion about the right language is just a
fan-boy war.
Personally I prefer C++ too, because I can express many thing in this
language without an ugly work around and without a runtime overhead.
But for commercial development I use C#, because of the better
maintainability and better availability of sufficiently skilled
programmers. The latter is mainly due to the reduced language complexity
and less UB in C# - although the distance decreases. And only a few
people have enough discipline not to use common code anti-patterns in
C++ that are likely to cause UB.
Marcel
| "Öö Tiib" <ootiib@hot.ee>: Mar 29 03:01PM -0700
On Tuesday, 29 March 2016 23:26:47 UTC+3, Christopher Pisz wrote:
> Does there exist a list of operating systems/hardware that I can target
> in C++?
Processor architectures supported by: GCC https://gcc.gnu.org/backends.html
Few and special case things are that you can not target in C++.
> My office mate is arguing with me that C# is now more portable than C++,
> because...mono. He is making me angry.
That is so silly. The tongue does not matter. What matters is what is
expressed in it. So better compare what known software is written in
C++ and what is in C#.
| Christopher Pisz <nospam@notanaddress.com>: Mar 29 06:26PM -0500
On 3/29/2016 4:52 PM, Marcel Mueller wrote:
> people have enough discipline not to use common code anti-patterns in
> C++ that are likely to cause UB.
> Marcel
I agree. Don't want to language war. I am not anti C# or strictly pro
C++, but I find the portability argument to be ludicrous!
I think he somehow defines "portability" differently, and seems to be
stuck somehow that there was a compilation step targeting the platform,
while I view it as the amount of code that has to change.
If I have to compile the same code twice with a platform switch, it is
one mouse click, so I don't get it.
Sure you can take interpreted code from one platform to the next where
the interpreter exists, but that's what 3 or 4 platforms? There are
probably thousands if not millions of pieces of hardware out there that
utilize C++.
I think I am just running into modern language fanaticism. Ironic,
because when I was 20 something, I was the one that had language fanaticism.
--
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
---
|
|
