Sunday, December 25, 2022

Digest for comp.lang.c++@googlegroups.com - 12 updates in 4 topics

Bo Persson <bo@bo-persson.se>: Dec 25 08:49PM +0100

On 2022-12-25 at 15:40, Stefan Ram wrote:
> with them. To learn how to use "Month" takes me at least one
> additional lookup. It could be even more lookups if even
> "Month" then redirects me to more opaque types.
 
What if the return value is January?
 
https://en.cppreference.com/w/cpp/chrono/month
red floyd <no.spam.here@its.invalid>: Dec 25 12:39PM -0800

On 12/25/2022 12:22 PM, Stefan Ram wrote:
> for C++20 yet. Lippman, Meyers, Sutter, Stroustrup do not
> seem to have updated their works yet. Today's fast pace of
> standardization puts a strain on authors!
 
Josuttis seems to have one out now.
 
https://www.amazon.com/20-Complete-Guide-Nicolai-Josuttis/dp/3967309207/
Bonita Montero <Bonita.Montero@gmail.com>: Dec 25 09:49PM +0100

Am 25.12.2022 um 21:39 schrieb red floyd:
 
> Josuttis seems to have one out now.
 
> https://www.amazon.com/20-Complete-Guide-Nicolai-Josuttis/dp/3967309207/
 
mega.nz has a version for free:
 
https://mega.nz/file/mpcQmSYC#AP0h6VvlX019meVCBQ3Va0m44ptL4L_YrE1V7Eh0Fs0
 
Password is "usenetrocks".
ram@zedat.fu-berlin.de (Stefan Ram): Dec 25 02:40PM

From the code examples for the C++ core guideline
"P.1: Express ideas directly in code":
 
|class Date {
|public:
| Month month() const; // do
| int month(); // don't
| // ...
|};
 
. Ok, when I read "int month()", I am not sure whether
January is 0 or 1, but otherwise I have the idea that
possible values probably are 0..11 or 1..12 and how to deal
with them. To learn how to use "Month" takes me at least one
additional lookup. It could be even more lookups if even
"Month" then redirects me to more opaque types.
 
When "const" is missing, this tells me that
- the function might be effectivly const, but the
programmer just forgot to mark it correspondingly, or
- the function may change the object's state.
 
Would there be a "var", it would tell me clearly that
- the function may change the object state, it is
not to be considered "const".
ram@zedat.fu-berlin.de (Stefan Ram): Dec 25 08:22PM

>What if the return value is January?
 
I'd say: If the language actually has a means of indicating
a month number, then one should use this. I didn't know C++20
had this!
 
Using names from the standard library is more clear and
readable than using names from a custom library would be.
 
I've started to read the Core Guidelines because it's one
of the few sources that might already contain a bit of C++20
(except the ISO standard itself). There are not many books
for C++20 yet. Lippman, Meyers, Sutter, Stroustrup do not
seem to have updated their works yet. Today's fast pace of
standardization puts a strain on authors!
"Öö Tiib" <ootiib@hot.ee>: Dec 24 06:19PM -0800

On Saturday, 24 December 2022 at 21:40:36 UTC+2, Malcolm McLean wrote:
> source to the program source, then you've got to specify how to invoke yacc to
> generate the C. That adds considerable complication to the build system and
> introduces several points at which it could break.
 
That is, yes, problem for small project where the toolchain was for example
just set up by Project -> New... of some IDE like Visual Studio, XCode or
QtCreator with sole purpose of trying something out.
The ways how to add some dependent library nothing to talk of more tools
to toolchain can feel rather arcane and take some learning.
In bigger project that anyway has multiple dependencies, targets multiple
toolchains, has several tools added to those and ultimately produces and
deploys multiple modules ... adding lex and yacc may be considered
relatively trivial task.
scott@slp53.sl.home (Scott Lurndal): Dec 25 05:07PM

>toolchains, has several tools added to those and ultimately produces and
>deploys multiple modules ... adding lex and yacc may be considered
>relatively trivial task.
 
Adding lex and yacc _are_ trival tasks.
 
acgram.c acgram.h: $A/acgram.y
$(YACC_CMD) $A/acgram.y
mv y.tab.c acgram.c
mv y.tab.h acgram.h
...
 
acgram.$o: acgram.c $(P1_H)
$(CC_CMD) $(YYDEBUG) acgram.c
 
aclex.c: $A/aclex.l
$(LEX) $(LFLAGS) $A/aclex.l
mv lex.yy.c aclex.c
 
aclex.$o: aclex.c acgram.h $(P1_H)
$(CC_CMD) aclex.c
"daniel...@gmail.com" <danielaparker@gmail.com>: Dec 25 10:55AM -0800

On Sunday, December 25, 2022 at 12:07:18 PM UTC-5, Scott Lurndal wrote:
 
> mv lex.yy.c aclex.c
 
> aclex.$o: aclex.c acgram.h $(P1_H)
> $(CC_CMD) aclex.c
 
Nonetheless, they don't appear to be widely used.
 
Most significant programming languages - JavaScript, Java Open JDK, PHP, C#, clang, gcc, Golang, Lua,
Swift, Julia, rust - use a handwritten parser, Ruby uses the Bison parser generator, PHP, and Python use
parser generators, Kotlin appears to use FLEX to tokenize and the rest is hand written.
 
Apart from programming language compilers, looking at implementations on github of XML, JSON,
and YAML for C++, Python and Ruby, most appear to use a handwritten parser.
 
Daniel
"gdo...@gmail.com" <gdotone@gmail.com>: Dec 24 06:27PM -0800

is it best practice to use new(nothrow) as to not have to handle the exception?
"Öö Tiib" <ootiib@hot.ee>: Dec 24 07:54PM -0800

> is it best practice to use new(nothrow) as to not have to handle the exception?
 
Best practice is not to use explicit new but standard library containers.
Standard library does not use new(nothrow).
 
Do you have some plan what to do when allocation fails somewhere?
If no then you can just catch std::bad_alloc in main and then report that
program died because it is out of memory. If yes then you can catch at
points where it is easiest to switch to that plan.
With new(nothrow) you will have to check in code after every new.
Check that has no idea what to do if it failed or how far it is from
place where there is something to do. How is it better?
 
Also the exceptions that are likely never thrown typically cost lot less
performance than those checks all over code base.
Paavo Helde <eesnimi@osa.pri.ee>: Dec 25 10:30AM +0200

> is it best practice to use new(nothrow) as to not have to handle the exception?
 
No, because then you would handle the nullptr return, which becomes more
cumbersome as soon as you have to do that in more than one place.
 
Best practice is to figure out if and why are you wanting to do a
dynamic allocation in the first place, then use std::make_unique or
std::make_shared as appropriate.
Andrey Tarasevich <andreytarasevich@hotmail.com>: Dec 25 01:09AM -0800

> is it best practice to use new(nothrow) as to not have to handle the exception?
 
Do you have a good strategy for handling a null return?
 
If you do, then just go ahead and use 'new(nothrow)' if you like it better.
 
If you don't, then it makes no difference. Better use plain 'new', since
it looks cleaner.
 
--
Best regards,
Andrey
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)