There is no direct relationship between headers and object files in C
or C++. Compilation process is two stage:
1. Source files are compiled into object files
2. Object files are linked together into executable of sorts
(Actually it's a three stage process, but i'm going to describe it
using two
I think a lot is because a lack of macros. With macros it is difficult to
figure out changed dependencies.
> On Nov 13, 2020, at 7:55 PM, kev kev wrote:
>
> Oh right, I seem to not understand why golang is faster in that respect. If
> you can include the precompiled headers and or have an ob
Oh right, I seem to not understand why golang is faster in that respect. If
you can include the precompiled headers and or have an object file
On Saturday, 14 November 2020 at 01:21:51 UTC ren...@ix.netcom.com wrote:
> In C there are precompiled headers which avoid the recompilation.
>
> On Nov
In C there are precompiled headers which avoid the recompilation.
> On Nov 13, 2020, at 7:18 PM, kev kev wrote:
>
>
> Thanks for the answer. If C/C++ has object files, is it not possible to see
> “something.h” and then fetch the corresponding object file?
>
> With go, if I import “package s
Thanks for the answer. If C/C++ has object files, is it not possible to see
“something.h” and then fetch the corresponding object file?
With go, if I import “package something” and that package imports another
package called “package bar” then at some point I will need to compile
“bar” and “so
C/C++ also has object file caching (depending on how your build is set up,
I guess). In C/C++ the issue is that you need to possibly open a large
number of header files when you import any header file.
For example, if I write a file "main.c" which imports "something.h", which
in turn imports "a
I recently read the post by Rob Pike about language choices for
Golang: https://talks.golang.org/2012/splash.article#TOC_5.
The seventh point refers to how Golang handles dependencies. It mentions an
"object file" for packages that a _dependent_ reads.
Below I go through my interpretation of th
If I understand what you're trying to do, I'd approach it this way, using a
generously buffered channel and discarding the extras at the consumer, as
shown below, instead of at the producer:
result <- c // wait for result to appear
for len(c) > 0 {
// there is a newer result available
re
I see some smart people suggesting that what OP is doing is not
correct. I am going to cautiously disagree with some of those replies
and suggest that a similar pattern can be useful for some
applications.
We have an application where we have a similar need. Specifically,
there is a periodic tic
Try to use two channels: one to signal that the receiver needs a new
value and another one to send new value to the receiver. Supposedly
the sender won't block if you're using `select` to check what
receivers need values, and the receiver can block until a new value is
arrived at the input channel.
On Fri, Nov 13, 2020 at 8:12 AM 陶青云 wrote:
>
> It is not a one-length buffered channel. I need to drop because the
> recveiver do heavy work that can't process as quickly as sender.
>
You need to write a flow control scheme then. Channels may be part of the
solution, but they can't solve it on
On Thu, Nov 12, 2020 at 11:13 PM 陶青云 wrote:
>
>
> It is not a one-length buffered channel. I need to drop because the
> recveiver do heavy work that can't process as quickly as sender.
Don't use channels for this. It's not what they are for.
Ian
> 在2020年11月13日星期五 UTC+8 下午2:36:13 写道：
>>
>>
12 matches
Mail list logo
