Wednesday, September 4, 2019

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

Bonita Montero <Bonita.Montero@gmail.com>: Sep 04 06:55AM +0200

>> That might be sometimes so, f.e. when declaring serialized
>> data-structures, but that's not typical.
 
> In your, what appears to be, extremely limited experience.
 
My experience is not limited on that.
 
> the C bindings; it's left to the implementation (or the associated
> application binary interface (ABI)) to define the order and any
> padding.
 
That' proves that this is typical?
In C++ you usually don't even insitialize members of structures
or classes like this by hand but indirectly through a constructor.
Juha Nieminen <nospam@thanks.invalid>: Sep 04 01:49PM

> In C++ you usually don't even insitialize members of structures
> or classes like this by hand but indirectly through a constructor.
 
The problem is that the declaration/implementation of the struct might
not be modifiable (eg. because it's in a third-party library), and in
some situations the members might not be assignable, most typically
because you want/need the instantiation to be const (or even constexpr):
 
const Data kData = { .value = 5, .name = "hello" };
 
Of course you could go the long route of creating a "constructor" function
for it and use it to initialize the const object:
 
Data createData(int value, const char* name)
{
Data data;
data.value = value;
data.name = name;
return data;
}
 
...
 
const Data kData = createData(5, "hello");
 
but that's a long-winded way of doing it.
Daniel <danielaparker@gmail.com>: Sep 04 05:58AM -0700

Consider
 
#include <iostream>
#include <initializer_list>
 
struct arg_t
{
};
 
constexpr arg_t arg = arg_t();
 
class C
{
public:
C(size_t n) {}
};
 
class A
{
public:
explicit A(size_t n)
{
std::cout << "1\n";
}
A(std::initializer_list<C> item)
{
std::cout << "2\n";
}
A(arg_t, size_t n)
{
std::cout << "3\n";
}
A(arg_t, std::initializer_list<C> item)
{
std::cout << "4\n";
}
};
 
int main()
{
A a{ { 2 } }; // (1)
A b{ arg, { 2 } }; // (2)
}
 
Output (vs2019):
 
2
3
 
I don't understand why one of these constructors is using the
initializer_list, and the other is not. Explanation?
 
Thanks,
Daniel
Ralf Goertz <me@myprovider.invalid>: Sep 04 02:09PM +0200

Hi,
 
why does the declaration
 
std::vector<std::string> pt({{"One","Two"}});
 
throw:
 
terminate called after throwing an instance of 'std::length_error'
what(): basic_string::_M_create
 
whereas neither
 
std::vector<std::string> pt({{"One"}});
 
nor
 
std::vector<int> pt({{1,2}});
 
does? Full program:
 
#include <vector>
#include <string>
#include <iostream>
 
std::vector<std::string> pt({{"One","Two"}});
int main() {
for (auto p:pt) std::cout<<p<<std::endl;
}
 
No warning is given during compilation by gcc version 9.2.1 20190820
Sam <sam@email-scan.com>: Sep 04 08:20AM -0400

Ralf Goertz writes:
 
 
> throw:
 
> terminate called after throwing an instance of 'std::length_error'
> what(): basic_string::_M_create
 
Because this is undefined behavior.
 
 
> std::vector<std::string> pt({{"One"}});
 
> nor
 
> std::vector<int> pt({{1,2}});
 
If you actually examine the end result the last declaration, you will
discover, to your surprise, a std::vector<int> with just one value, and that
would hopefully be a big honking clue as to what this is doing.
 
{ /* something */ } introduces a braced initialization list.
 
{ { /* something */ } } introduces a braced initialization list with one
value.
 
 
{ { "One", "Two" } } attempts to construct a single std::string with two
values. The only overloaded std::string constructor this matches is the one
that takes a beginning iterator and an ending iterator of a sequence that
forms the contents of the constructed std::string.
 
Since "One" and "Two" decay to two character pointers which do not comprise
a single sequence, you just nuked yourself from high orbit, hence the crash.
 
> No warning is given during compilation by gcc version 9.2.1 20190820
 
A compiler has no obligation to warn you when you're about to shoot yourself
in a foot. It would be nice if it did, and in many cases it does; but you
can't rely on your compiler to keep you from shooting yourself in a foot.
Ralf Goertz <me@myprovider.invalid>: Sep 04 02:33PM +0200

Am Wed, 04 Sep 2019 08:20:51 -0400
> discover, to your surprise, a std::vector<int> with just one value,
> and that would hopefully be a big honking clue as to what this is
> doing.
 
Hm, I did that and it failed to surprise me.
 
 
#include <vector>
#include <string>
#include <iostream>
 
std::vector<int> pt({{1,2}});
int main() {
for (auto p:pt) std::cout<<p<<std::endl;
}
 
gives:
1
2
 
here. Just as I expected.
> { /* something */ } introduces a braced initialization list.
 
> { { /* something */ } } introduces a braced initialization list with
> one value.
 
But didn't we need to use two braces for container intialization?
Bonita Montero <Bonita.Montero@gmail.com>: Sep 04 02:43PM +0200

Am 04.09.2019 um 14:09 schrieb Ralf Goertz:
> Hi,
> why does the declaration
> std::vector<std::string> pt({{"One","Two"}});
 
To less curly brackets! Thre must be at least 42!
 
Or this:
vector<string> thatsright { "One", "Two" };
David Brown <david.brown@hesbynett.no>: Sep 04 09:03AM +0200

On 03/09/2019 22:17, Richard wrote:
> improved gcc at this point, but Stallman et al. have literally said
> that they made the internal interface as painful as possible to put
> into a library on purpose because they didn't want anyone doing that.
 
That was certainly true. But it is a long time - a very long time -
since Stallman and others with that attitude have ruled gcc. There is
no doubt that Stallman specifically wanted strong ties between different
parts of the code in gcc, to make it as difficult as possible to split
it up and mix the gcc front ends with commercial or closed backends, or
vice versa. However, as the project grew, with many more people
involved, many front ends, and many back ends, it got steadily cleaner
separation and more modularisation. And with gcc 4.5, nearly 10 years
ago (IIRC), it got plugin support.
 
One of the big influences and motivations for gcc plugins is the
competitive / cooperative relationship with llvm/clang. The two
projects push each other forward, which is great for users of either
tool suite.
 
RMS may not like the fact that gcc has plugins, with the risk that has
of mixing closed source software with gcc, but there is no doubt that
gcc supports plugins and these are used, amongst other things, for
additional static analysis.
 
> Clang was designed from the ground up to be used as a library.
 
True.
 
>> /long/ before looking at lex/yacc.
 
> Don't bother looking at lex/yacc because the context-sensitive nature
> of many C++ constructs makes it impossible to use lex/yacc.
 
True.
 
> Don't waste your time with GCC because it isn't designed to be used
> this way.
 
Unless you are stuck a decade behind the times, /do/ look at gcc, and
especially the existing plugin libraries, if you want to make your own
static analysis. And look at clang. Compare their approaches, compare
the documentation, websites, blogs, tutorials, third-party code,
examples and other information. Then figure out what is going to make
sense for the kind of tool you want to make and use.
 
My guess - and it is only a guess - is that clang is going to be the
best base if you want to write a large-scale checker and you want high
speed for analysing large code bases. And gcc with the Python or Melt
(Lisp) plugins are going to be good for small-scale checks written in
higher level languages.
 
Bonita Montero <Bonita.Montero@gmail.com>: Sep 04 10:44AM +0200

The best code analyzer is: printing the code out, having a bath
with the printouts in the hand or lying in the bad with the code
in the hand and a purring cat beside.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 04 01:07AM +0100

On Tue, 3 Sep 2019 20:46:44 +0200
> Error-handling is done through returning a combined structure with
> error- and return-codes. So error-handling is almost as complex as
> in C.
 
As far as I can tell, in rust you can match on the returned Result type,
and you can nest your matches to short-circuit in case of error in the
same way that exceptions do. The match on the Result type is a somewhat
more cumbersome version of a bind (Result and Option types are in fact
monads, although not referred to as such).
 
Using a Result type instead of exceptions seems to be a price that the
rust developers thought worthwhile in order to enforce correct error
handling through the type system: something that C of course does not
do. It does come with some complexity cost.
Clifford Heath <no.spam@please.net>: Sep 04 10:47AM +1000

On 3/9/19 11:29 pm, David Brown wrote:
 
> It is painfully clear, however, that you are unteachable - your reaction
> to being shown something new is denial and insults. This is a shame,
> and I hope you will realise it and make an effort to change.
 
David, respect. Your reputation remains untarnished with me.
 
But please, "someone is wrong on the Internet" is not a good reason to
continue this. Bonita has that special kind of ignorance - willful
ignorance. There's none so ignorant as one who chooses to be so.
 
Clifford Heath
William Ahern <william@25thandClement.com>: Sep 03 08:04PM -0700

> Error-handling is done through returning a combined structure with
> error- and return-codes. So error-handling is almost as complex as
> in C.
 
Servo's renderer isn't used in Firefox. The biggest (and I think only) piece
of Servo that has been integrated into Firefox so far is the CSS component,
Stylo. See https://wiki.mozilla.org/Quantum
 
Also, technically Rust does have exceptions--a panic can unwind the stack
and invoke destructors until it gets to a handler. However, much like Go
they dissuade people from thinking and using them as such. See
https://doc.rust-lang.org/nomicon/unwinding.html
Bonita Montero <Bonita.Montero@gmail.com>: Sep 04 06:38AM +0200

>> most of the standard-library can be omitted, stack is very limited
>> also if there is any and won't get more maintainability over C.
 
> Total and complete nonsense.
 
LOL.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 04 06:41AM +0200

> Look at Arduino. I will not argue that Arduino make sense.
> ButArduino is used and Arduino uses C++ features.
 
This doesn't mean that C++ makes sense here.
 
> 9 bytes of static allocated RAM. I did not check RAM use for stack,
> but there is good chance that stack + static use will fit in 128
> bytes.
 
That's a proof for the advantages of C++ on arduino?
 
> and compiler optimizations allow reasonbly small object code.
> Similar approach can be used with plain C, but then one may need
> a "program generator" as first step.
 
Templates might induce specialized Boat and inlining also should
be better avoided with such a small amount of flash.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 04 06:42AM +0200

> printf, or any <math.h> functions - that doesn't mean I won't be using
> C.  And I can write the code in C++ even if it doesn't use std::string,
> or vectors, or new.
 
C++ simply hasn't any significant advantage over C on such tiny
projects.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 04 06:46AM +0200

> Servo's renderer isn't used in Firefox. ...
 
Ok, thanks.
> Also, technically Rust does have exceptions--a panic can unwind
> the stack and invoke destructors until it gets to a handler. ...
 
But AFAIK only for non-recoverable errors.
Melzzzzz <Melzzzzz@zzzzz.com>: Sep 04 04:48AM

> and invoke destructors until it gets to a handler. However, much like Go
> they dissuade people from thinking and using them as such. See
> https://doc.rust-lang.org/nomicon/unwinding.html
 
panic can do that but it is not required, it can just abort as well,
currently one can catch panics.
Regarding error handling I disagree with previous post. Each function
can return discriminate union and Rust has sytnactic sugar for handling
errors.
 
 
--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Ian Collins <ian-news@hotmail.com>: Sep 04 04:56PM +1200

On 04/09/2019 12:47, Clifford Heath wrote:
 
> But please, "someone is wrong on the Internet" is not a good reason to
> continue this. Bonita has that special kind of ignorance - willful
> ignorance. There's none so ignorant as one who chooses to be so.
 
Well said! The snipping of attributions is a clear sign of willful
ignorance which makes engagement pointless.
 
--
Ian.
Paavo Helde <myfirstname@osa.pri.ee>: Sep 04 08:31AM +0300

On 3.09.2019 23:09, Richard wrote:
>> only been posted to CLC++.
 
> The author of the article barely mentions C++; instead all the
> comparisons are to C.
 
This is because the low-level bugs presumably solved by Rust, like
out-of-bounds access and memory leaks, are pretty much non-issues in C++.
 
In C++, it is hard to get an out-of-bounds access with
 
for(auto iter=container.begin(); iter!=container.end(); ++i)
 
and even harder with
 
for(auto& ref: container)
 
Similarly, it is much harder to get a memory leak or
access-after-destruction if there is not a single owning raw pointer (as
produced by malloc() or new) in the program.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 03 10:49PM -0700

On 9/3/2019 1:35 PM, Scott Lurndal wrote:
> highway" programmer; someone with strongly held, but poorly justified
> positions who won't mesh well with any competent programming
> team.
 
Very Pointed Ears?
 
I hope not, in a sense. She has to be able to blend into a team. Learn
its way of doing things, even down to the syntactic sugar it uses.
styles... CamelCase? Okay, fine with me. Pascal, pascalCase, CamelCase?
whatever. I can adapt to the teams coding quirks. How about the
underscores, like POSIX? well_this_is_how_we_do_it, pthread_mutex_t...
No problem.
 
;^) It does not matter. I am lucky enough to be part of the team in the
first place. ?
David Brown <david.brown@hesbynett.no>: Sep 04 09:13AM +0200

> are similar approaches getting more efficient and smaller code.
> In particular there are examples which are much more complicated
> that LED blinker that still fit into 2k code and 128 bytes RAM.
 
The Arduino libraries are, as you say, made with ease of use in mind.
They use C++ primarily for encapsulation. So you open the serial port
with "Serial.begin(9600);" and you send out data with
"Serial.print(x);", where the "print" method is overloaded for different
types.
 
There is a lot to dislike about the Arduino libraries and software
development environment - they are inefficient, limited, and hide a lot
of detail and flexibility that would be useful to more experienced
users. But they are for ease of use, rather than efficiency, and they
are aimed at beginners, not experienced embedded programmers.
 
> and compiler optimizations allow reasonbly small object code.
> Similar approach can be used with plain C, but then one may need
> a "program generator" as first step.
 
Yes. There are lots of features of C++ that have no cost whatsoever in
terms of code space, data space or run time. (Indeed the language is
aimed at zero cost - a "std::vector" may take a lot of code space and
require a heap, but so would the equivalent functionality in C.)
 
Many features of C++ are more significant for larger code bases, but
that doesn't mean they can't be useful for small code bases.
Daniel <danielaparker@gmail.com>: Sep 04 12:20AM -0700

On Tuesday, September 3, 2019 at 4:36:02 PM UTC-4, Scott Lurndal wrote:
 
> Funny, I get the opposite impression.
 
True or not, it's not necessary to share these impressions, it doesn't
contribute to civil discourse. That wouldn't have been allowed, for example,
on comp.lang.c++.moderated, and some self moderation is always appropriate. If
the arguments are sound, it shouldn't be necessary to supplement them with
statements about how stupid or pig headed the other person is. Or as they say,
when Peter talks about Paul, we learn more about Peter than we do about Paul.
 
Daniel
David Brown <david.brown@hesbynett.no>: Sep 04 09:24AM +0200

On 03/09/2019 23:43, Mr Flibble wrote:
 
> No I don't think you should choose a solution just so you can use a "gui
> library" as that would be just as fucktarded as your decision to use
> this antiquated technology. You chose wrong.
 
The device I picked is less than two years old. It is okay to be
ignorant of technology outside your usual field. It is not okay to
assume that you do, when it is clearly totally alien to you.
 
Now you get to choose. You can accept that some people are
knowledgeable and experienced in fields that are beyond your own
understanding. Or you can write another silly, rude, arrogant response
to further confirm that you don't appreciate your own limitations.
David Brown <david.brown@hesbynett.no>: Sep 04 09:33AM +0200

On 03/09/2019 21:16, Daniel wrote:
> willful and insistent ignorance ..." is unnecessary, as of course is "liar",
> not to mention "fucktarded". I would say "this person" is in many respects a
> very capable programmer, judging from her other postings.
 
I admit that I have not been as polite as I should have been, and
normally am, in this thread. I have no doubt at all that Bonita is
ignorant about many of the things she has been claiming, and in this
thread you can easily see her digging herself deeper and deeper in the
same hole, rather than trying to learn something. But I have not been
very diplomatic about how the conversation was going, and how I handled it.
 
I assume - as I have no reason to think otherwise - that Bonita is a
perfectly capable programmer within her field. She may even be an
exceptionally good programmer. But expertise in one field of
programming does not impart knowledge of other fields.
David Brown <david.brown@hesbynett.no>: Sep 04 09:37AM +0200

On 04/09/2019 02:47, Clifford Heath wrote:
> continue this. Bonita has that special kind of ignorance - willful
> ignorance. There's none so ignorant as one who chooses to be so.
 
> Clifford Heath
 
<https://xkcd.com/386/>
 
I'll continue with posts in reply to other people, but cut out my
replies to Bonita (in this thread at least).
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)