malloc in main() or malloc in another function: allocating memory for a struct and its members
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
$begingroup$
When initializing a struct in C, we can allocate memory inside the main
function or within another function and return a pointer to the newly created struct. This first example shows the latter; memory is allocated in Buffer_create
and a pointer is returned:
#include <stdio.h>
#include "buffer.h"
int main(int argc, char *argv)
{
struct Buffer *tx_buffer = Buffer_create(8);
Buffer_destroy(tx_buffer);
return 0;
}
And this one shows how all memory allocations can be done within the main
function:
#include <stdio.h>
#include "buffer.h"
int main(int argc, char *argv)
{
uint8_t *ptr_rx_buffer = malloc(sizeof(uint8_t)*8);
struct Buffer *rx_buffer = malloc(sizeof(struct Buffer));
Buffer2_create(rx_buffer, ptr_rx_buffer, 8);
Buffer2_destroy(rx_buffer);
return 0;
}
And here are the contents of the header file buffer.h
:
#ifndef _buffer_h
#define _buffer_h
#include <stdint.h>
#include <stdlib.h>
struct Buffer {
uint8_t *buffer;
size_t size;
};
struct Buffer *Buffer_create(size_t size);
void Buffer_destroy(struct Buffer *who);
void Buffer2_create(struct Buffer *who, uint8_t *buffer, size_t size);
void Buffer2_destroy(struct Buffer *who);
#endif
And buffer.c
:
#include <stdint.h>
#include <assert.h>
#include <stdlib.h>
#include "buffer.h"
struct Buffer *Buffer_create(size_t size)
{
struct Buffer *who = malloc(sizeof(struct Buffer));
assert(who != NULL);
who->buffer = malloc(sizeof(uint8_t)*size);
who->size = size;
return who;
}
void Buffer_destroy(struct Buffer *who)
{
assert(who != NULL);
free(who->buffer);
free(who);
}
void Buffer2_create(struct Buffer *who, uint8_t *buffer, size_t size)
{
assert(who != NULL);
who->buffer = buffer;
who->size = size;
}
void Buffer2_destroy(struct Buffer *who)
{
assert(who != NULL);
free(who->buffer);
free(who);
}
The Result
Both approaches work and the executable files for both end up being the same size.
My Question
Will either of these approaches result in memory leaks or poor performance?
performance c comparative-review memory-management pointers
New contributor
$endgroup$
add a comment |
$begingroup$
When initializing a struct in C, we can allocate memory inside the main
function or within another function and return a pointer to the newly created struct. This first example shows the latter; memory is allocated in Buffer_create
and a pointer is returned:
#include <stdio.h>
#include "buffer.h"
int main(int argc, char *argv)
{
struct Buffer *tx_buffer = Buffer_create(8);
Buffer_destroy(tx_buffer);
return 0;
}
And this one shows how all memory allocations can be done within the main
function:
#include <stdio.h>
#include "buffer.h"
int main(int argc, char *argv)
{
uint8_t *ptr_rx_buffer = malloc(sizeof(uint8_t)*8);
struct Buffer *rx_buffer = malloc(sizeof(struct Buffer));
Buffer2_create(rx_buffer, ptr_rx_buffer, 8);
Buffer2_destroy(rx_buffer);
return 0;
}
And here are the contents of the header file buffer.h
:
#ifndef _buffer_h
#define _buffer_h
#include <stdint.h>
#include <stdlib.h>
struct Buffer {
uint8_t *buffer;
size_t size;
};
struct Buffer *Buffer_create(size_t size);
void Buffer_destroy(struct Buffer *who);
void Buffer2_create(struct Buffer *who, uint8_t *buffer, size_t size);
void Buffer2_destroy(struct Buffer *who);
#endif
And buffer.c
:
#include <stdint.h>
#include <assert.h>
#include <stdlib.h>
#include "buffer.h"
struct Buffer *Buffer_create(size_t size)
{
struct Buffer *who = malloc(sizeof(struct Buffer));
assert(who != NULL);
who->buffer = malloc(sizeof(uint8_t)*size);
who->size = size;
return who;
}
void Buffer_destroy(struct Buffer *who)
{
assert(who != NULL);
free(who->buffer);
free(who);
}
void Buffer2_create(struct Buffer *who, uint8_t *buffer, size_t size)
{
assert(who != NULL);
who->buffer = buffer;
who->size = size;
}
void Buffer2_destroy(struct Buffer *who)
{
assert(who != NULL);
free(who->buffer);
free(who);
}
The Result
Both approaches work and the executable files for both end up being the same size.
My Question
Will either of these approaches result in memory leaks or poor performance?
performance c comparative-review memory-management pointers
New contributor
$endgroup$
add a comment |
$begingroup$
When initializing a struct in C, we can allocate memory inside the main
function or within another function and return a pointer to the newly created struct. This first example shows the latter; memory is allocated in Buffer_create
and a pointer is returned:
#include <stdio.h>
#include "buffer.h"
int main(int argc, char *argv)
{
struct Buffer *tx_buffer = Buffer_create(8);
Buffer_destroy(tx_buffer);
return 0;
}
And this one shows how all memory allocations can be done within the main
function:
#include <stdio.h>
#include "buffer.h"
int main(int argc, char *argv)
{
uint8_t *ptr_rx_buffer = malloc(sizeof(uint8_t)*8);
struct Buffer *rx_buffer = malloc(sizeof(struct Buffer));
Buffer2_create(rx_buffer, ptr_rx_buffer, 8);
Buffer2_destroy(rx_buffer);
return 0;
}
And here are the contents of the header file buffer.h
:
#ifndef _buffer_h
#define _buffer_h
#include <stdint.h>
#include <stdlib.h>
struct Buffer {
uint8_t *buffer;
size_t size;
};
struct Buffer *Buffer_create(size_t size);
void Buffer_destroy(struct Buffer *who);
void Buffer2_create(struct Buffer *who, uint8_t *buffer, size_t size);
void Buffer2_destroy(struct Buffer *who);
#endif
And buffer.c
:
#include <stdint.h>
#include <assert.h>
#include <stdlib.h>
#include "buffer.h"
struct Buffer *Buffer_create(size_t size)
{
struct Buffer *who = malloc(sizeof(struct Buffer));
assert(who != NULL);
who->buffer = malloc(sizeof(uint8_t)*size);
who->size = size;
return who;
}
void Buffer_destroy(struct Buffer *who)
{
assert(who != NULL);
free(who->buffer);
free(who);
}
void Buffer2_create(struct Buffer *who, uint8_t *buffer, size_t size)
{
assert(who != NULL);
who->buffer = buffer;
who->size = size;
}
void Buffer2_destroy(struct Buffer *who)
{
assert(who != NULL);
free(who->buffer);
free(who);
}
The Result
Both approaches work and the executable files for both end up being the same size.
My Question
Will either of these approaches result in memory leaks or poor performance?
performance c comparative-review memory-management pointers
New contributor
$endgroup$
When initializing a struct in C, we can allocate memory inside the main
function or within another function and return a pointer to the newly created struct. This first example shows the latter; memory is allocated in Buffer_create
and a pointer is returned:
#include <stdio.h>
#include "buffer.h"
int main(int argc, char *argv)
{
struct Buffer *tx_buffer = Buffer_create(8);
Buffer_destroy(tx_buffer);
return 0;
}
And this one shows how all memory allocations can be done within the main
function:
#include <stdio.h>
#include "buffer.h"
int main(int argc, char *argv)
{
uint8_t *ptr_rx_buffer = malloc(sizeof(uint8_t)*8);
struct Buffer *rx_buffer = malloc(sizeof(struct Buffer));
Buffer2_create(rx_buffer, ptr_rx_buffer, 8);
Buffer2_destroy(rx_buffer);
return 0;
}
And here are the contents of the header file buffer.h
:
#ifndef _buffer_h
#define _buffer_h
#include <stdint.h>
#include <stdlib.h>
struct Buffer {
uint8_t *buffer;
size_t size;
};
struct Buffer *Buffer_create(size_t size);
void Buffer_destroy(struct Buffer *who);
void Buffer2_create(struct Buffer *who, uint8_t *buffer, size_t size);
void Buffer2_destroy(struct Buffer *who);
#endif
And buffer.c
:
#include <stdint.h>
#include <assert.h>
#include <stdlib.h>
#include "buffer.h"
struct Buffer *Buffer_create(size_t size)
{
struct Buffer *who = malloc(sizeof(struct Buffer));
assert(who != NULL);
who->buffer = malloc(sizeof(uint8_t)*size);
who->size = size;
return who;
}
void Buffer_destroy(struct Buffer *who)
{
assert(who != NULL);
free(who->buffer);
free(who);
}
void Buffer2_create(struct Buffer *who, uint8_t *buffer, size_t size)
{
assert(who != NULL);
who->buffer = buffer;
who->size = size;
}
void Buffer2_destroy(struct Buffer *who)
{
assert(who != NULL);
free(who->buffer);
free(who);
}
The Result
Both approaches work and the executable files for both end up being the same size.
My Question
Will either of these approaches result in memory leaks or poor performance?
performance c comparative-review memory-management pointers
performance c comparative-review memory-management pointers
New contributor
New contributor
edited 41 mins ago
1201ProgramAlarm
3,7632925
3,7632925
New contributor
asked 3 hours ago
DavidDavid
1093
1093
New contributor
New contributor
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
$begingroup$
Looking at the performance, the two versions should perform just about identically. The second version has one less call/return, which can save a couple of CPU cycles, but if you have it multiple places in your code the additional code bytes and cache misses can overshadow that. Either way you probably won't notice a difference.
Looking at readability and maintainability, the first version is much better. You know at a glance what it is doing (rather than looking at several lines to figure it all out), you won't forget any important steps, and error checking is much easier since most of it can be handled in one place (excepting the last check for successful creation of the buffer). Debugging can also be easier, since you can set a breakpoint on the creation or destruction functions if necessary.
$endgroup$
add a comment |
$begingroup$
In the first case, the caller is not given any control over allocation. This limits freedom and (therefore) performance: there is no control over the number of dynamic allocations or over which memory is used for what purpose, and there are limits on how the handle to the buffer can be stored (the returned pointer to Buffer
must be kept around somehow, even if we would really just want to store the Buffer
by value and avoid some unnecessary double-indirection).
In the second case, the caller does have control, but Buffer2_destroy
makes a very limiting assumption about how the memory was allocated so in the end the caller still has no choice. Of course by looking into the implementation details, one could see that simply not calling Buffer2_destroy
enables some freedom again, but this would probably be considered a hack. All in all this approach violates the guideline "allocate and free memory in the same module, at the same level of abstraction", and doesn't get much in return.
Practically what a user of some buffer may want to do is for example:
- Having the
Buffer
as a local variable but its datamalloc
-ed. - Having the
Buffer
as a local variable and making its data refer to a local array. - Save the
Buffer
into some other struct or array (by value, not a pointer to aBuffer
which then points to the data). - Using (part of) a static array as the data.
- Various other such combinations..
- Allocate both the buffer data and the instance of
Buffer
in the same allocation.
Which is why a common advice is, where possible, do not allocate or deallocate memory, use memory supplied by the caller. This applies especially to performance-sensitive settings, where "secret malloc
" is not appreciated, and custom allocators are commonly used.
$endgroup$
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "196"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
David is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f217807%2fmalloc-in-main-or-malloc-in-another-function-allocating-memory-for-a-struct-a%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
Looking at the performance, the two versions should perform just about identically. The second version has one less call/return, which can save a couple of CPU cycles, but if you have it multiple places in your code the additional code bytes and cache misses can overshadow that. Either way you probably won't notice a difference.
Looking at readability and maintainability, the first version is much better. You know at a glance what it is doing (rather than looking at several lines to figure it all out), you won't forget any important steps, and error checking is much easier since most of it can be handled in one place (excepting the last check for successful creation of the buffer). Debugging can also be easier, since you can set a breakpoint on the creation or destruction functions if necessary.
$endgroup$
add a comment |
$begingroup$
Looking at the performance, the two versions should perform just about identically. The second version has one less call/return, which can save a couple of CPU cycles, but if you have it multiple places in your code the additional code bytes and cache misses can overshadow that. Either way you probably won't notice a difference.
Looking at readability and maintainability, the first version is much better. You know at a glance what it is doing (rather than looking at several lines to figure it all out), you won't forget any important steps, and error checking is much easier since most of it can be handled in one place (excepting the last check for successful creation of the buffer). Debugging can also be easier, since you can set a breakpoint on the creation or destruction functions if necessary.
$endgroup$
add a comment |
$begingroup$
Looking at the performance, the two versions should perform just about identically. The second version has one less call/return, which can save a couple of CPU cycles, but if you have it multiple places in your code the additional code bytes and cache misses can overshadow that. Either way you probably won't notice a difference.
Looking at readability and maintainability, the first version is much better. You know at a glance what it is doing (rather than looking at several lines to figure it all out), you won't forget any important steps, and error checking is much easier since most of it can be handled in one place (excepting the last check for successful creation of the buffer). Debugging can also be easier, since you can set a breakpoint on the creation or destruction functions if necessary.
$endgroup$
Looking at the performance, the two versions should perform just about identically. The second version has one less call/return, which can save a couple of CPU cycles, but if you have it multiple places in your code the additional code bytes and cache misses can overshadow that. Either way you probably won't notice a difference.
Looking at readability and maintainability, the first version is much better. You know at a glance what it is doing (rather than looking at several lines to figure it all out), you won't forget any important steps, and error checking is much easier since most of it can be handled in one place (excepting the last check for successful creation of the buffer). Debugging can also be easier, since you can set a breakpoint on the creation or destruction functions if necessary.
answered 33 mins ago
1201ProgramAlarm1201ProgramAlarm
3,7632925
3,7632925
add a comment |
add a comment |
$begingroup$
In the first case, the caller is not given any control over allocation. This limits freedom and (therefore) performance: there is no control over the number of dynamic allocations or over which memory is used for what purpose, and there are limits on how the handle to the buffer can be stored (the returned pointer to Buffer
must be kept around somehow, even if we would really just want to store the Buffer
by value and avoid some unnecessary double-indirection).
In the second case, the caller does have control, but Buffer2_destroy
makes a very limiting assumption about how the memory was allocated so in the end the caller still has no choice. Of course by looking into the implementation details, one could see that simply not calling Buffer2_destroy
enables some freedom again, but this would probably be considered a hack. All in all this approach violates the guideline "allocate and free memory in the same module, at the same level of abstraction", and doesn't get much in return.
Practically what a user of some buffer may want to do is for example:
- Having the
Buffer
as a local variable but its datamalloc
-ed. - Having the
Buffer
as a local variable and making its data refer to a local array. - Save the
Buffer
into some other struct or array (by value, not a pointer to aBuffer
which then points to the data). - Using (part of) a static array as the data.
- Various other such combinations..
- Allocate both the buffer data and the instance of
Buffer
in the same allocation.
Which is why a common advice is, where possible, do not allocate or deallocate memory, use memory supplied by the caller. This applies especially to performance-sensitive settings, where "secret malloc
" is not appreciated, and custom allocators are commonly used.
$endgroup$
add a comment |
$begingroup$
In the first case, the caller is not given any control over allocation. This limits freedom and (therefore) performance: there is no control over the number of dynamic allocations or over which memory is used for what purpose, and there are limits on how the handle to the buffer can be stored (the returned pointer to Buffer
must be kept around somehow, even if we would really just want to store the Buffer
by value and avoid some unnecessary double-indirection).
In the second case, the caller does have control, but Buffer2_destroy
makes a very limiting assumption about how the memory was allocated so in the end the caller still has no choice. Of course by looking into the implementation details, one could see that simply not calling Buffer2_destroy
enables some freedom again, but this would probably be considered a hack. All in all this approach violates the guideline "allocate and free memory in the same module, at the same level of abstraction", and doesn't get much in return.
Practically what a user of some buffer may want to do is for example:
- Having the
Buffer
as a local variable but its datamalloc
-ed. - Having the
Buffer
as a local variable and making its data refer to a local array. - Save the
Buffer
into some other struct or array (by value, not a pointer to aBuffer
which then points to the data). - Using (part of) a static array as the data.
- Various other such combinations..
- Allocate both the buffer data and the instance of
Buffer
in the same allocation.
Which is why a common advice is, where possible, do not allocate or deallocate memory, use memory supplied by the caller. This applies especially to performance-sensitive settings, where "secret malloc
" is not appreciated, and custom allocators are commonly used.
$endgroup$
add a comment |
$begingroup$
In the first case, the caller is not given any control over allocation. This limits freedom and (therefore) performance: there is no control over the number of dynamic allocations or over which memory is used for what purpose, and there are limits on how the handle to the buffer can be stored (the returned pointer to Buffer
must be kept around somehow, even if we would really just want to store the Buffer
by value and avoid some unnecessary double-indirection).
In the second case, the caller does have control, but Buffer2_destroy
makes a very limiting assumption about how the memory was allocated so in the end the caller still has no choice. Of course by looking into the implementation details, one could see that simply not calling Buffer2_destroy
enables some freedom again, but this would probably be considered a hack. All in all this approach violates the guideline "allocate and free memory in the same module, at the same level of abstraction", and doesn't get much in return.
Practically what a user of some buffer may want to do is for example:
- Having the
Buffer
as a local variable but its datamalloc
-ed. - Having the
Buffer
as a local variable and making its data refer to a local array. - Save the
Buffer
into some other struct or array (by value, not a pointer to aBuffer
which then points to the data). - Using (part of) a static array as the data.
- Various other such combinations..
- Allocate both the buffer data and the instance of
Buffer
in the same allocation.
Which is why a common advice is, where possible, do not allocate or deallocate memory, use memory supplied by the caller. This applies especially to performance-sensitive settings, where "secret malloc
" is not appreciated, and custom allocators are commonly used.
$endgroup$
In the first case, the caller is not given any control over allocation. This limits freedom and (therefore) performance: there is no control over the number of dynamic allocations or over which memory is used for what purpose, and there are limits on how the handle to the buffer can be stored (the returned pointer to Buffer
must be kept around somehow, even if we would really just want to store the Buffer
by value and avoid some unnecessary double-indirection).
In the second case, the caller does have control, but Buffer2_destroy
makes a very limiting assumption about how the memory was allocated so in the end the caller still has no choice. Of course by looking into the implementation details, one could see that simply not calling Buffer2_destroy
enables some freedom again, but this would probably be considered a hack. All in all this approach violates the guideline "allocate and free memory in the same module, at the same level of abstraction", and doesn't get much in return.
Practically what a user of some buffer may want to do is for example:
- Having the
Buffer
as a local variable but its datamalloc
-ed. - Having the
Buffer
as a local variable and making its data refer to a local array. - Save the
Buffer
into some other struct or array (by value, not a pointer to aBuffer
which then points to the data). - Using (part of) a static array as the data.
- Various other such combinations..
- Allocate both the buffer data and the instance of
Buffer
in the same allocation.
Which is why a common advice is, where possible, do not allocate or deallocate memory, use memory supplied by the caller. This applies especially to performance-sensitive settings, where "secret malloc
" is not appreciated, and custom allocators are commonly used.
answered 23 mins ago
haroldharold
1,47368
1,47368
add a comment |
add a comment |
David is a new contributor. Be nice, and check out our Code of Conduct.
David is a new contributor. Be nice, and check out our Code of Conduct.
David is a new contributor. Be nice, and check out our Code of Conduct.
David is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Code Review Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f217807%2fmalloc-in-main-or-malloc-in-another-function-allocating-memory-for-a-struct-a%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown