profile
viewpoint
Philipp A. Hartmann pah Linz, Austria Bridging gaps.

pah/git-credential-helper 14

A set of Git credential helpers (gnome-keyring, osxkeychain, generic implementation) to be contributed to Git at some appropriate time in the future

pah/rapidjson 14

Yet another Rapidjson mirror [A fast JSON parser/generator for C++ with both SAX/DOM style API] (with additional fixes)

pah/pristine-tar 9

regenerate pristine tarballs from git

pah/dokuwiki 1

The DokuWiki Open Source Wiki Engine

pah/osci-release-flow-test 1

Repository for testing development flow

pah/dokuwiki-plugin-pageredirect 0

Redirects page requests based on content

pah/dokuwiki-plugin-yabibtex 0

Yet Another DokuWiki BibTeX plugin

pah/git 0

Git Source Code Mirror - This is a publish-only repository and all pull requests are ignored. Please follow Documentation/SubmittingPatches procedure for any of your improvements.

pah/nativejson-benchmark 0

C/C++ JSON parser/generator benchmark

push eventmicrosoft/GSL

Jordan Maples [MSFT]

commit sha 0140ab1d73d833d2b1eca37d1b3b91e52dda4176

Change build status badges (#955) Using Azure Pipelines badge instead of the Travis-ci and Appveyor badges.

view details

push time in 11 minutes

PR merged microsoft/GSL

Change build status badges

Using Azure Pipelines badge instead of the Travis-ci and Appveyor badges.

+8 -8

0 comment

1 changed file

JordanMaples

pr closed time in 11 minutes

Pull request review commentcplusplus/draft

Replace "could" and "might", Clauses 16-32.

  \pnum \begin{note}-If the clock is not synchronized with a steady clock, e.g., a CPU time clock, these-timeouts might not provide useful functionality.+If the clock is not synchronized with a steady clock, e.g., a CPU time clock,+it is possible that these timeouts do not provide useful functionality.

Thanks, the suggestion is a nice improvement. About "not guaranteed to provide useful functionality", I suspect that that additional strengthening wouldn't help much if we don't also define "useful functionality", so I think what we have now will do the job.

tkoeppe

comment created time in 3 hours

issue openedcplusplus/draft

[dcl.array] p.7 may be outdated

Paragraph 7 of [dcl.array] (https://eel.is/c++draft/dcl.array#7) states:

In addition to declarations in which an incomplete object type is allowed, an array bound may be omitted in some cases in the declaration of a function parameter ([dcl.fct]). An array bound may also be omitted when an object (but not a non-static data member) of array type is initialized and the declarator is followed by an initializer ([dcl.init], [class.mem], [expr.type.conv], [expr.new]). In these cases, the array bound is calculated from the number of initial elements (say, N) supplied ([dcl.init.aggr]), and the type of the array is “array of N U”.

The wording "an array bound may be omitted in some cases in the declaration of a function parameter", among other changes, was added by the resolution to CWG619.

Actually, the highlighted part ("in some cases") is the only difference between the proposed resolution in February of 2010 compared to the proposed resolution in March of 2010.

I believe that the only cases in which it was not allowed (at that time) to omit array bounds in the declaration of a function parameter were specified by [dcl.fct] p.8, which stated (in N3035, published in 2010):

If the type of a parameter includes a type of the form “pointer to array of unknown bound of T” or “reference to array of unknown bound of T,” the program is ill-formed. Functions shall not have a return type of type array or function, although they may have a return type of type pointer or reference to such things. There shall be no arrays of functions, although there can be arrays of pointers to functions. Types shall not be defined in return or parameter types. The type of a parameter or the return type for a function definition shall not be an incomplete class type (possibly cv-qualified) unless the function definition is nested within the member-specification for that class (including definitions in nested classes defined within the class).

However, the highlighted part of [dcl.fct] p.8 (forbidding pointers or references to arrays of unknown bound in the type of a parameter) was removed by the resolution to CWG393.

I do not know any cases in which, by the current specification, one cannot use arrays of unknown bound in the type of a function parameter. Are there any such cases that I am overlooking?

created time in 3 hours

Pull request review commentcplusplus/draft

Replace "could" and "might", Clauses 16-32.

 \pnum \begin{note} The current path for many operating systems is a dangerous-  global state. It might be changed unexpectedly by a third-party or system+  global state, and can be changed unexpectedly by a third-party or system

Done.

tkoeppe

comment created time in 3 hours

Pull request review commentcplusplus/draft

Replace "could" and "might", Clauses 16-32.

 \pnum \begin{note} The current path as returned by many operating systems is a dangerous-  global variable. It might be changed unexpectedly by third-party or system+  global variable, and can be changed unexpectedly by third-party or system

Done.

tkoeppe

comment created time in 3 hours

Pull request review commentcplusplus/draft

Replace "could" and "might", Clauses 16-32.

 \pnum \begin{note} If the directory structure being iterated over contains cycles-then the end iterator might be unreachable.+then it is possible for the end iterator to be unreachable.

That's nice, thanks. That's exactly the kind of comment I am looking for: we don't just want to change the bad words away mechanically, but ideally find nice ways to say something equivalent that avoids them.

tkoeppe

comment created time in 3 hours

Pull request review commentcplusplus/draft

Replace "could" and "might", Clauses 16-32.

 \returns \tcode{traits::eof()} to indicate failure.-Failure may occur because the input sequence could not be backed up, or if for some-other reason the pointers could not be set consistent with the constraints.+Failure may occur because the input sequence cannot be backed up, or if for some

I agree that the existing wording is already questionable, so let's keep this entire change out and have it reviewed by the wording group.

tkoeppe

comment created time in 3 hours

pull request commentcplusplus/draft

[over.call.func, gram.key] Make colon in bnf non-italic.

As long as \nontermdef is only used for the symbol being defined, then that'd work just fine.

Eelis

comment created time in 4 hours

Pull request review commentcplusplus/draft

Replace "could" and "might", Clauses 16-32.

 \begin{note} These apply regardless of the provided \tcode{policy} argument, and even if the corresponding \tcode{future} object is moved to another thread.-However, \tcode{f} might not be called at all,-so its completion might never happen.+It is possible for \tcode{f} not to be called at all,
However, it is possible for \tcode{f} not to be called at all,
tkoeppe

comment created time in 5 hours

Pull request review commentcplusplus/draft

Replace "could" and "might", Clauses 16-32.

  \pnum \begin{note}-If the clock is not synchronized with a steady clock, e.g., a CPU time clock, these-timeouts might not provide useful functionality.+If the clock is not synchronized with a steady clock, e.g., a CPU time clock,+it is possible that these timeouts do not provide useful functionality.

This feels a little clearer and less awkward:

If the clock is not synchronized with a steady clock, e.g., a CPU time clock, these
timeouts can fail to provide useful functionality.

Something like "...these timeouts are not guaranteed to provide..." would be even better, but I'm not sure if that passes ISO muster.

tkoeppe

comment created time in 5 hours

Pull request review commentcplusplus/draft

Replace "could" and "might", Clauses 16-32.

 \pnum \begin{note} The current path for many operating systems is a dangerous-  global state. It might be changed unexpectedly by a third-party or system+  global state, and can be changed unexpectedly by a third-party or system

No comma or "a" here.

tkoeppe

comment created time in 5 hours

Pull request review commentcplusplus/draft

Replace "could" and "might", Clauses 16-32.

 \returns \tcode{traits::eof()} to indicate failure.-Failure may occur because the input sequence could not be backed up, or if for some-other reason the pointers could not be set consistent with the constraints.+Failure may occur because the input sequence cannot be backed up, or if for some

Isn't the "may" here also problematic, since we aren't giving permission to failure but for it?

tkoeppe

comment created time in 5 hours

Pull request review commentcplusplus/draft

Replace "could" and "might", Clauses 16-32.

 \pnum \begin{note} The current path as returned by many operating systems is a dangerous-  global variable. It might be changed unexpectedly by third-party or system+  global variable, and can be changed unexpectedly by third-party or system

No comma here.

tkoeppe

comment created time in 5 hours

Pull request review commentcplusplus/draft

Replace "could" and "might", Clauses 16-32.

 \pnum \begin{note} If the directory structure being iterated over contains cycles-then the end iterator might be unreachable.+then it is possible for the end iterator to be unreachable.

I might say, slightly more directly, "then it is possible that the end iterator is unreachable".

tkoeppe

comment created time in 5 hours

pull request commentcplusplus/draft

[over.call.func, gram.key] Make colon in bnf non-italic.

@jensmaurer's suggestion sounds somewhat more structured -- what do you think? That way people don't have to remember to type colons at all.

Eelis

comment created time in 6 hours

push eventcplusplus/draft

Thomas Köppe

commit sha f124033f68060252988e469a3cdd661571a0b387

[std] Add "implemented" to hyphenation rules

view details

push time in 6 hours

pull request commentcplusplus/draft

Replace "could" and "might", Clauses 16-32.

@opensdh: Could you perhaps take a look at the filesystem changes?

@geoffromer: Could you perhaps take a look at the atomics and threads changes?

Thank you!

tkoeppe

comment created time in 6 hours

PR opened cplusplus/draft

Replace "could" and "might", Clauses 16-32.

These changes editorially remove the words "could" and "might".

Please review this change carefully with the following goals:

Flag anything that seems even remotely non-editorial, e.g. even if the explanation provided by a Note becomes less useful or (more) misleading. Also flag anything that could conceivably be worded better by a wider review. I would like all remaining instances of "could" and "might" to be reviewed by CWG/LWG, so please don't hold back on rejecting anything at this point.

+100 -100

0 comment

16 changed files

pr created time in 6 hours

pull request commentcplusplus/draft

[over.call.func, gram.key] Make colon in bnf non-italic.

We could make the colon an “active character.” This would allow you to just type an unadorned colon in the source (within the BNF environments) and LaTeX would interpret it as a macro that expands to \textnormal{:} (or similar).

Eelis

comment created time in 8 hours

issue commentisocpp/CppCoreGuidelines

GSL helper functions to convert span of bytes to a well-defined struct

@sunnychatterjee surely T would have to be standard layout, right? The versions of these function I have written throw an exception if the span is too smal for T, since your overload is noexcept, I imagine you return nullptr in that case, is that right?

There's also the issue of alignment, either alignof(T) would have to be 1, or some runtime check would have to be made to ensure correct alignment of the span pointer.

sunnychatterjee

comment created time in 10 hours

issue commentisocpp/CppCoreGuidelines

GSL helper functions to convert span of bytes to a well-defined struct

At least that was my understanding (probably also gsl::byte on c++14 systems and realistically, someone will want to have it for unsigned char too).

sunnychatterjee

comment created time in 13 hours

PR opened cplusplus/draft

[over.call.func] Make colon in bnf non-italic.
+1 -1

0 comment

1 changed file

pr created time in a day

issue commentmicrosoft/GSL

strict_not_null performance issues with reference types

@amaroker That's true, and I'm still not certain that there's a need to remove that check inside .get() -- because that one is only a performance improvement on some runs, and either of the other two changes by themselves also gives similar benefit.

I'm still investigating, but on some further experiments I ran today it does appear the extra check is free even in get() where it is redundant as long as every write to the pointer is checked. I'm now investigating whether it remains free even with a bit of additional complication in the check logic -- specifically I'm experimenting with calling a customizable violation handler to resolve a few of the other open issues.

Thanks again for the repro!

Amaroker

comment created time in a day

issue commentmicrosoft/GSL

strict_not_null performance issues with reference types

Thanks @hsutter for sharing your observations!

The performance improvements that you suggest would be satisfying.

I agree that there's no need to assert on each read (hence the removal) because the invariant has already been validated when the pointer was set in the constructor.

But I'm still curious. You previously suggested that not null test is to be considered free. But in this example, that's only true in the constructor. So, what really surprises me is that the assertion (not-null test without __builtin_expect) has different performance impact in a constructor and in a member function. Any thoughts on that?

Amaroker

comment created time in a day

push eventcplusplus/draft

Jens Maurer

commit sha dbabaf996dc156f716a95e3897155dd97fab228e

over first part

view details

Jens Maurer

commit sha 52b21c46fff4eb40654c12ad53cc6eabe0d9f9d0

over.load, over.dcl removal

view details

Jens Maurer

commit sha ef820ac19ddf8dc14334d90bc91ec4e6c2358459

over (remainder)

view details

push time in a day

starteddavidthings/hdelk

started time in a day

push eventcplusplus/draft

Jens Maurer

commit sha 77ecae6aadcfe265fab6bdd37a6074cb53a3cf91

classes (rest)

view details

push time in a day

issue commentisocpp/CppCoreGuidelines

GSL helper functions to convert span of bytes to a well-defined struct

Ah yes if the new member is only on that specialization, it wouldn't be needed.

sunnychatterjee

comment created time in a day

issue commentisocpp/CppCoreGuidelines

GSL helper functions to convert span of bytes to a well-defined struct

I think so yes, absolutely. However, when exactly would that be necessary? No matter what T is, my_span (or rather the return type ofsubspanin this example would always be of the concrete typegsl::spanstd::byteand thus the addtitiontemplate` should not be necessary no?

sunnychatterjee

comment created time in a day

more