GEgeoffbp·Jun 29, 2023Submission
3 points · Open discussiongoogle
glog
C++2015–2023
google / glog · Archived
glog
C++ implementation of the Google logging module
5Distinct people
5Mentions
0Explicit recommenders
7.4KGitHub stars
What to know before exploring
What it is
C++ implementation of the Google logging module
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year5 dated mentions
Observed mentions: 2015-08-05 11:32:59 UTC to 2023-06-29 13:34:30 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
5 sourcesIf you're new to C++11, Captain Proto (particularly the kj library embedded within it-- src/kj ) is a great read: https://github.com/capnproto/capnproto kj semi-re-implements several core C++11 features like Own and Maybe (actually Maybe / std::optional is still pretty new!) https://github.com/capnproto/capnproto/blob/master/c%2B%2B/s... Why did Kenton do this? He can speak for himself, but the core of Captain Proto is /roughly/ like a serializable / portable memory arena, so it was necessary for the design. Reading through kj and _comparing_ it with C++11 will give you some great initial insight into why both are implemented the ways they are. I'm not really advocating you use kj directly or adopt things like capnp's unique comment style, but the codebase is nevertheless very well organized and clear.
Some of the older glog code
Read the rest
is pretty nice with regards to a very vanilla and portable treatment of macros https://github.com/google/glog/tree/master/src/glog
While I wouldn't necessarily recommend Boost as a model project / repo ( https://github.com/boostorg ), it's worth checking out to help understand why modern decisions were made the way they were.
>I'm probably missing your point, since one certainly don't need a preprocessor for line numbers in logging statements.
So, libc doesn't define anything like pclntab. About the closest you can really get is DWARF2 call frame information, which is generally treated as debug information (because, well, it _is_) and stripped in release builds. Further, not all platforms will use DWARF2, and the way it is embedded in binaries differs.
(Example: In Win32, when you are using MinGW, DWARF2 will be embedded as PE sections, which have 8 character long names; this is not long enough for the DWARF section names, so a special PE extension is used to specify the longer section names.)
What i'm trying to illustrate is, it's really, truly not possible to go from a PC value, to a line number in a source file, in pure C, at runtime. However, of course, as
Read the rest
you have no doubt noticed, everyone still manages to print out line numbers in C source code. And they do this using the preprocessor.
If you dig deep enough into pretty much any logging library that offers line numbers in C and C++, you will find a macro that passes through __FILE__ and __LINE__. And if you keep tracing, you will probably also find the 'function' you call to log is a macro that eventually calls this macro. As a quick example, here is one in glog, a logging library used at Google:
https://github.com/google/glog/blob/41f4bf9cbc3e8995d628b459...
Pantheios is another popular logging library, and it defines macros that can be used to control the prefix.
https://github.com/synesissoftware/Pantheios/blob/177dc5fcff...
If you look into your logging library, it is quite likely that you will find that at the end of the day, it boils down to the __FILE__ and __LINE__ macros. When all of the macros are computed for your log line, the preprocessor subs in a string literal and line number for the filename and the line number that the macro was originally invoked from.
Not only that, but glog authors observed the overhead of frequent fadvise and added rate limiting almost a year and half ago. https://github.com/google/glog/commit/dacd29679633c9b845708e...
+1 perf. -1 stale library use. -1 misdirected learning
In Another reason why Docker containers may be slowWhy Google don't maintain glog any more?
1 points · Open discussion