473,714 Members | 2,453 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

function and arguments as aguments

Hi. I have the following code:

--------------------------------------
function Tunnel() {
//arguments[0](???);
}

function Sum() {
var sum = 0;
for (i=0; i<arguments.len gth; i++) sum += arguments[i];
alert(sum);
};

// calling Sum directly
Sum(1,2,3,4);

// calling Sum through Tunnel
Tunnel(Sum, 1,2,3,4);
--------------------------------------

How should the Tunnel function be defined, knowing that the number of
parameters passed are unknown?

telmo
Feb 15 '06
41 2573
Michael Winter wrote:
On 17/02/2006 18:42, Thomas 'PointedEars' Lahn wrote:

[snip]
| 10.1.8 Arguments Object
| [...]
| * The value of the internal [[Prototype]] property of the
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^
| arguments object is the original Object prototype object,
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^
| the one that is the initial value of Object.prototyp e
| (section 15.2.3.1).
As I've always understood the 'original Object prototype' phrase, and it
seems rather explicit, above, the arguments object may only ever have
the properties as described in 15.2.3.1. That is, because it's
[[Prototype]] property is the /original/ Object prototype object,
modifications to that prototype will not be seen with an arguments
object. The fact that some implementations do use a modified Object
prototype object is a peculiarity of those implementations .


But to accept that position, 15.2.3.1:

"Object.prototy pe - The initial value of Object.prototyp e is the
Object prototype object (15.2.4)."

which also seems rather explicit, has to be reconciled. If this is not
an assignment of the original, it's a nebulous and extremely sloppy
indication that it's actually a copy or an original that's, in turn, to
remain completely pristine. Or do I misunderstand your interpretation
of how the original would remain intact?
Note that the only other use of the phrase, 'original Object prototype
object', is found in the description of the [[Construct]] property
(13.2.2) where the original Object prototype object will be used if the
prototype property of the Function object is not an object.


This, then, raises the question of what possible reason would there be
making this type of special condition of 'original inheritance only'
for these two cases. And especially in the case of a Function object
that doesn't happen to have an object as a prototype - why would
something outside the mold of all other objects being created have to
be used in this case?

It doesn't add up. The whole thing has the appearance of something that
was backed off in the production of the standard, but not completely.
In other words, it appears to me that the word 'original' should have
been removed in a couple of places, but was overlooked.

../rh

Feb 18 '06 #21
VK

ro********@gmai l.com wrote:
Michael Winter wrote:
On 17/02/2006 18:42, Thomas 'PointedEars' Lahn wrote:

[snip]
| 10.1.8 Arguments Object
| [...]
| * The value of the internal [[Prototype]] property of the
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^
| arguments object is the original Object prototype object,
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^
| the one that is the initial value of Object.prototyp e
| (section 15.2.3.1).


As I've always understood the 'original Object prototype' phrase, and it
seems rather explicit, above, the arguments object may only ever have
the properties as described in 15.2.3.1. That is, because it's
[[Prototype]] property is the /original/ Object prototype object,
modifications to that prototype will not be seen with an arguments
object. The fact that some implementations do use a modified Object
prototype object is a peculiarity of those implementations .


But to accept that position, 15.2.3.1:

"Object.prototy pe - The initial value of Object.prototyp e is the
Object prototype object (15.2.4)."

which also seems rather explicit, has to be reconciled. If this is not
an assignment of the original, it's a nebulous and extremely sloppy
indication that it's actually a copy or an original that's, in turn, to
remain completely pristine. Or do I misunderstand your interpretation
of how the original would remain intact?
Note that the only other use of the phrase, 'original Object prototype
object', is found in the description of the [[Construct]] property
(13.2.2) where the original Object prototype object will be used if the
prototype property of the Function object is not an object.


This, then, raises the question of what possible reason would there be
making this type of special condition of 'original inheritance only'
for these two cases. And especially in the case of a Function object
that doesn't happen to have an object as a prototype - why would
something outside the mold of all other objects being created have to
be used in this case?

It doesn't add up. The whole thing has the appearance of something that
was backed off in the production of the standard, but not completely.
In other words, it appears to me that the word 'original' should have
been removed in a couple of places, but was overlooked.


It adds up perfectly if we read Books of ECMA in the way it was
intended by Fathers, not in the after-Reformation way :-)

All they wanted to say is that any possible object in JavaScript (as
well as in any other language thought) has at very beginning of its
evolution chain the Object object.
And at the very bottom of everything there is the original constructor
(object factory, allocator, God forgive me - class) producing that the
most primitive Object object.
Object Constructor is the very bottom of everything, there is nothing
below that except the "possibilit y that still has to become", "to ti en
einai" of Aristote :-)

Something can be the very first in the chain, but nothing can appear
from nowhere. This is why there are objects without prototype, but
there are no objects without a constructor behind them.

So again they just wanted to say that the same "becomizato r"
(constructor, class, allocator) used to produce Object object - the
same constructor is being used to produce <arguments> object.

Therefore <Object> object and <arguments> object are not in inheritance
relations, but they are both instances of the same class constructor.
Just no one expected that 7 years later will be a new generation of
JavaScript programmers (and doc readers) with mentally prohibited
ability to apply constructor / class terms to the text.

If we read apocryphal texts of the same or close time (1998-1999) we
shall see not see too many cases where "prototype" is used as
"something strictly opposed to the class". At that time "prototype"
stayed closer to the original more universal "a first form from which
varieties arise", this is why prototype vs. constructor terminology in
Books Of ECMA is not so strict as some modern readers would like it to
be.
Some fun to play with:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html401/frameset.dtd">
<html>
<head>
<title>Test</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">

<style type="text/css">
body { background-color: #FFFFFF}
</style>

<script type="text/javascript">
function init() {
alert (arguments instanceof Object); // true
alert(init.cons tructor instanceof Object); // true
}

window.onload = init;
</script>

</head>
<body>
<p>&nbsp;</p>
</body>
</html>

P.S. I did not check: was OP's question anywhere answered? :-)

Feb 18 '06 #22
Michael Winter wrote:
On 17/02/2006 18:42, Thomas 'PointedEars' Lahn wrote:
| 10.1.8 Arguments Object
| [...]
| * The value of the internal [[Prototype]] property of the
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^
| arguments object is the original Object prototype object,
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^
| the one that is the initial value of Object.prototyp e
| (section 15.2.3.1).
As I've always understood the 'original Object prototype' phrase, and it
seems rather explicit, above, the arguments object may only ever have
the properties as described in 15.2.3.1.


Then you have to read it again, for you misunderstood it. Most
certainly because you read it not thoroughly enough.

Objects have a [[Prototype]] property that refers to the object they
inherit from.

Core objects, because they also expose themselves as constructors,
have also a `prototype' property that refers to an object O with
properties (their prototype object). The properties of O are
inherited through the prototype chain by objects which have their
[[Prototype]] property as referring to O, or, in other words, have
O as their [[Prototype]] property.

Those are two _different_ objects.
That is, because it's [[Prototype]] property is the /original/ Object
prototype object, modifications to that prototype will not be seen with
an arguments object.
Wrong. If the [[Prototype]] property of an object is another object O,
which is equivalent to the term "refers to O" (remember the `==' and
`===' operators), it inherits all properties from that object through
the prototype chain.

The "(original) Object prototype object" is Object.prototyp e.

The "internal [[Prototype]] property of the Object prototype object"
^^^^^^^^^^^
is Object.prototyp e.[[Prototype]], which is null (end of the prototype
chain).
The fact that some implementations do use a modified Object
prototype object is a peculiarity of those implementations .
Wrong. It is because of a strict ECMAScript-conforming implementation in
that regard.
Note that the only other use of the phrase, 'original Object prototype
object', is found in the description of the [[Construct]] property
(13.2.2) where the original Object prototype object will be used if the
prototype property of the Function object is not an object.
You have to read the definitions in context. The specification is very
clear in that regard:

| 4.3.4 Constructor
|
| A constructor is a Function object that creates and initialises objects.
| Each constructor has an associated prototype object that is used to
| implement inheritance and shared properties.

Only constructors C have a native `prototype' object, C.prototype.

| 8.6.2 Internal Properties and Methods
|
| Native ECMAScript objects have an internal property called [[Prototype]].
| The value of this property is either null or an object and is used for
| implementing inheritance. Properties of the [[Prototype]] object are
| visible as properties of the child object for the purposes of get access,
| but not for put access.

All native objects O have an internal [[Prototype]] property,
O.[[Prototype]]. Properties _of_ O.[[Prototype]] are inherited
for "get access" through the prototype chain.

Those are _different_ concepts, and _different_ objects.
That means essentially that `arguments' is an Object object, as it
inherits directly from Object.prototyp e through the prototype chain.
Which makes it possible to augment Object.prototyp e and call its
methods with `arguments' as caller.


Assuming for the moment that I'm correct, that would make this statement
false: it /shouldn't/ be possible (except through extensions to the
language) to use the properties of an augmented Object prototype object.
[...]


Exactly. This is _proof_ /that/ you are wrong. I have explained
above /why/ you are wrong.
A final, related note: the arguments object is an Array instance in Opera.


That appears to be true, and would be a conforming extension of ECMAScript:

| 2 Conformance
|
| A conforming implementation of ECMAScript must provide and support all the
| types, values, objects, properties, functions, and program syntax and
| semantics described in this specification.
| [...]
| A conforming implementation of ECMAScript is permitted to provide
| additional types, values, objects, properties, and functions beyond those
| described in this specification. [...]

It has Object.prototyp e in its prototype chain, though, through
Array.prototype .[[Prototype]] which is (or refers to) Object.prototyp e:

| 15.4.4 Properties of the Array Prototype Object
|
| The value of the internal [[Prototype]] property of the Array prototype
| object is the Object prototype object (section 15.2.3.1).

Which is why augmentation of Object.prototyp e or `arguments' itself works
there for `arguments', too.
HTH

PointedEars
Feb 18 '06 #23
On 18/02/2006 01:16, ro********@gmai l.com wrote:
Michael Winter wrote:
[snip]
As I've always understood the 'original Object prototype' phrase
[...] the arguments object may only ever have the properties as
described in 15.2.3.1. That is, because it's [[Prototype]] property
is the /original/ Object prototype object, modifications to that
prototype will not be seen with an arguments object. [...]


But to accept that position, 15.2.3.1:

"Object.prototy pe - The initial value of Object.prototyp e is the
Object prototype object (15.2.4)."

which also seems rather explicit, has to be reconciled.


I don't believe that they conflict, as such, but...
If this is not an assignment of the original, it's a nebulous and
extremely sloppy indication that it's actually a copy [...]
....I do agree that it's not presented very well, and I think that this
is the crux of the problem. If I continue your quotation of 15.2.3.1, we
find:

This property has the attributes { DontEnum, DontDelete,
ReadOnly }.

which means that the Object.prototyp e property can never be deleted or
reassigned, yet the description of the property above uses the word,
'initial'. Why say that value of the property /begins/ with the Object
prototype object if that's the only value that it can ever have? The
inclusion of 'initial' is redundant at best, but without the attribute
description above, its implication is misleading.

[snip]
This, then, raises the question of what possible reason would there be
making this type of special condition of 'original inheritance only'
for these two cases.
It is possible that this problem of language also applies to the use of
'original'. However, for the arguments object, I can't think of a
particular reason why one would want it to inherit properties from an
augmented Object prototype object.
And especially in the case of a Function object that doesn't happen
to have an object as a prototype - why would something outside the
mold of all other objects being created have to be used in this case?
That's a question I can't answer. However, the absence of an object for
the prototype property would be a rather exceptional event, so perhaps
the language designers decided on an exceptional way of dealing with it.
I'm not the person to ask: I've only made an observation.
It doesn't add up. The whole thing has the appearance of something that
was backed off in the production of the standard, but not completely.
Perhaps, but of the possible places to retain the distinction, the two
cases that I pointed to are about the only reasonable parts of the
specification where this behaviour could be applied (the only other
possibility that I can see is the [[Prototype]] property of the Math
object).

The similar phrase, 'Object prototype object', occurs elsewhere in the
specification where the inheritance of used-defined properties would be
undoubtedly beneficial.
In other words, it appears to me that the word 'original' should have
been removed in a couple of places, but was overlooked.


It's quite a coincidence that only these two occurrences exist, and do
so in places where the lack of inheritance is more-or-less inconsequential .

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Feb 19 '06 #24
On 18/02/2006 12:32, Thomas 'PointedEars' Lahn wrote:
Michael Winter wrote:
[snip]
As I've always understood the 'original Object prototype' phrase,
and it seems rather explicit, above, the arguments object may only
ever have the properties as described in 15.2.3.1.


Then you have to read it again, for you misunderstood it.


Your opinion is noted, but I don't agree. The inclusion of the word
'original' alters the meaning of the sentence. It implies that the
Object prototype object can be modified (and we know it can), but the
value of the internal [[Prototype]] property of the arguments object is
to use the original. If it meant a possibly augmented object, it could
have omitted the word in question as the specification does in the
majority of other occurrences of the phrase.

Whether this situation was intended by the language designers is a
different matter entirely.

[snip]
Objects have a [[Prototype]] property that refers to the object they
inherit from.

Core objects, because they also expose themselves as constructors,
have also a `prototype' property that refers to an object O with
properties (their prototype object). The properties of O are
inherited through the prototype chain by objects which have their
[[Prototype]] property as referring to O, or, in other words, have
O as their [[Prototype]] property.

Those are two _different_ objects.


I already know this.
The rest of your post (with some exceptions, below) hinges around your
understanding of the phrase 'original Object prototype object' and that
it differs from mine. As your other points derive from that, there's
little value in addressing them (I would be arguing against points that
I would otherwise agree with).

[snip]
Assuming for the moment that I'm correct, that would make this
statement [that the arguments object inherits from an augmented
Object prototype object] false: it /shouldn't/ be possible (except
through extensions to the language) to use the properties of an
augmented Object prototype object. [...]


Exactly. This is _proof_ /that/ you are wrong.


No, it isn't. A proof that I was wrong would necessitate an statement
that corrects some misunderstandin g of the word 'original' and its
implications in the context I have outlined.

original (adjective)

1. first or earliest
2. fresh and unusual; not copied from or based on something
else
3. able to think of or carry out new ideas or concepts
4. being the first and genuine form of something, from which a
copy or translation is made

Its use implies, intended or otherwise, that there may be a difference
between the object that exists during execution, and that described in
the specification.

In case you're confusing the issue, I'm not arguing that other native
objects (such as Function or String instances) cannot inherit from an
augmented 'Object prototype object'. The word 'original' is not included
with their use of that phrase.

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Feb 19 '06 #25
Michael Winter wrote:
[...] However, for the arguments object, I can't think of a particular
reason why one would want it to inherit properties from an augmented
Object prototype object.


Have you even read the thread? The whole point of this exercise was to
use methods of Array.prototype such as shift() and join() for `arguments'.
The goal was to achieve that always, not only if `arguments' (undoubtedly
as a conforming extension of ECMAScript) inherits from Array.prototype .

news:56******** ********@Pointe dEars.de
And especially in the case of a Function object that doesn't happen
to have an object as a prototype -
Not true.

| 13.2 Creating Function Objects
|
| [...]
| 9. Create a new object as would be constructed by the expression new
| Object().
| [...]
| 11. Set the prototype property of F to Result(9). This property is
| given attributes as specified in section 15.3.5.2.
| [...]
| 15.3.2.1 new Function (p1, p2, ... , pn, body)
| [...]
| A prototype property is automatically created for every function, to
| provide for the possibility that the function will be used as a
| constructor.
| [...]
| 15.3.3 Properties of the Function Constructor
|
| The value of the internal [[Prototype]] property of the Function
| constructor is the Function prototype object (section 15.3.4).
|
| Besides the internal properties and the length property (whose value is
| 1), the Function constructor has the following properties:
|
| 15.3.3.1 Function.protot ype
|
| The initial value of Function.protot ype is the Function prototype object
| (section 15.3.4).
|
| This property has the attributes { DontEnum, DontDelete, ReadOnly }.
|
| 15.3.4 Properties of the Function Prototype Object
| [...]
|
| 15.3.5.2 prototype
|
| The value of the prototype property is used to initialise the internal
| [[Prototype]] property of a newly created object before the Function
| object is invoked as a constructor for that newly created object. This
| property has the attribute { DontDelete }.

The only difference here is that the phrase "Properties of the Function
Constructor" is used instead of the phrase "Properties of the Function
Object". However, since only constructors are specified to have a native
`prototype' property, regarding that property both phrases are equivalent.
why would something outside the mold of all other objects being created
have to be used in this case?


That's a question I can't answer. However, the absence of an object for
the prototype property would be a rather exceptional event, so perhaps
the language designers decided on an exceptional way of dealing with it.
I'm not the person to ask: I've only made an observation.


Another wrong observation at that.
PointedEars
Feb 19 '06 #26
On 19/02/2006 01:48, Thomas 'PointedEars' Lahn wrote:
Michael Winter wrote:
[...] However, for the arguments object, I can't think of a
particular reason why one would want it to inherit properties from
an augmented Object prototype object.
Have you even read the thread?


Considering that I contributed an answer to the OP, that's an extremely
stupid question to ask (rhetorically or otherwise). Please refrain from
remarks like that in the future, Thomas.
The whole point of this exercise was to use methods of
Array.prototype such as shift() and join() for `arguments'.


But augmentation of the Object prototype object is not necessary for
this, and in fact it would be inappropriate to do so (objects, in
general, are not shifted or joined).

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Feb 19 '06 #27
Michael Winter wrote:
In case you're confusing the issue, I'm not arguing that other native
objects (such as Function or String instances) cannot inherit from an
augmented 'Object prototype object'. The word 'original' is not included
with their use of that phrase.


If one was to follow this logic, and the specification to the letter, it
would mean that an implementation would have to retain both the "original
Object prototype object" (and keep memory allocated for it) and another
Object prototype object that can be subject to augmentation, just for the
sake of `arguments' which is not even needed if control never enters the
execution context for function code. Which also would have to apply for
the prototype objects of Function, Array, String, Boolean, Number, Date,
RegExp and Error objects as well, because this particular phrase is also
used in their definitions (ECMAScript 3 Final, 13.2, 13.2.2, 15.4.2.1,
15.4.2.2, 15.5.2.1, 15.6.2.1, 15.7.2.1, 15.9.3.1, 15.9.3.2, 15.9.3.3,
15.10.4.1, 15.11.1.1, and 15.11.2.1).

I can understand why _all_ implementors chose not to follow the
specification to the letter (t)here so far. If they did, it would have
rendered all augmentation of core object's prototype objects meaningless,
thereby reducing the flexibility of the language considerably, while
allocating more memory than needed in the usual case. That said, this
design decision is also entirely in conformance with ECMAScript.
We can live with it.
PointedEars
Feb 19 '06 #28
Michael Winter wrote:
On 19/02/2006 01:48, Thomas 'PointedEars' Lahn wrote:
Michael Winter wrote:
[...] However, for the arguments object, I can't think of a
particular reason why one would want it to inherit properties from
an augmented Object prototype object.
Have you even read the thread?


Considering that I contributed an answer to the OP, that's an extremely
stupid question to ask (rhetorically or otherwise). [...]


No, it is not, given your extremely stupid statement above. (Hey, I am
only using your rhetoric...)
The whole point of this exercise was to use methods of
Array.prototype such as shift() and join() for `arguments'.


But augmentation of the Object prototype object is not necessary for
this,


But a viable and more efficient approach, since `arguments' is recreated
on every call. You are free to augment `arguments' only on each and
every method call; I prefer to consider other possibilities as well.
and in fact it would be inappropriate to do so (objects, in general, are
not shifted or joined).


Nonsense. Those methods manipulate the properties of objects with numerical
name. The property values are not necessarily object references. In fact,
the whole point of reusing methods of Array.prototype is to handle
properties of objects with numerical name as if they were array elements.

So instead of writing a for-loop that concatenates (or pushes to an array,
if you wish) the values of all properties with numerical name, you just
augment Object.prototyp e or the target object itself and call join() on
the target object with a feasible separator. There is undoubtedly an
uncompared elegance and efficiency to this programming style.
PointedEars
Feb 19 '06 #29
Michael Winter wrote:
On 18/02/2006 01:16, ro********@gmai l.com wrote:
Michael Winter wrote:
[snip]
As I've always understood the 'original Object prototype' phrase
[...] the arguments object may only ever have the properties as
described in 15.2.3.1. That is, because it's [[Prototype]] property
is the /original/ Object prototype object, modifications to that
prototype will not be seen with an arguments object. [...]


But to accept that position, 15.2.3.1:

"Object.prototy pe - The initial value of Object.prototyp e is the
Object prototype object (15.2.4)."

which also seems rather explicit, has to be reconciled.


I don't believe that they conflict, as such, but...


Well, in my interpretation they do, because of the use of the word
'the' -- in my reading, and by general context provided by the
document, I'm inclined to take that as "the one, and the only". That
is, I don't see any suggested or specified way of maintaining an object
that holds the original properties.

In addition, it seems most reasonable in the generation of the initial
prototype hierarchy, that there be a single prototype object (with
internal [[Prototype]] that terminates in null) to serve as the mother
of all inheritance.
If this is not an assignment of the original, it's a nebulous and
extremely sloppy indication that it's actually a copy [...]


...I do agree that it's not presented very well, and I think that this
is the crux of the problem. If I continue your quotation of 15.2.3.1, we
find:

This property has the attributes { DontEnum, DontDelete,
ReadOnly }.

which means that the Object.prototyp e property can never be deleted or
reassigned, yet the description of the property above uses the word,
'initial'. Why say that value of the property /begins/ with the Object
prototype object if that's the only value that it can ever have? The
inclusion of 'initial' is redundant at best, but without the attribute
description above, its implication is misleading.


I think it is redundant, but it's at the very least consistent with
indication of of initialization of properties that is used in the
specification. I've tended to read that as "initialize d to", given the
usage, rather than taking implication regarding potential subsequent
mutation (that appear in some cases to be constrained by {Don't Delete}
and {Read Only}).
[snip]
This, then, raises the question of what possible reason would there be
making this type of special condition of 'original inheritance only'
for these two cases.


It is possible that this problem of language also applies to the use of
'original'. However, for the arguments object, I can't think of a
particular reason why one would want it to inherit properties from an
augmented Object prototype object.
And especially in the case of a Function object that doesn't happen
to have an object as a prototype - why would something outside the
mold of all other objects being created have to be used in this case?


That's a question I can't answer. However, the absence of an object for
the prototype property would be a rather exceptional event, so perhaps
the language designers decided on an exceptional way of dealing with it.
I'm not the person to ask: I've only made an observation.


Perhaps, but when ambiguity presents, I generally prefer to take the
path of least resistance; i.e., why try to make things more complicated
than absolutely necessary. ;-)
It doesn't add up. The whole thing has the appearance of something that
was backed off in the production of the standard, but not completely.


Perhaps, but of the possible places to retain the distinction, the two
cases that I pointed to are about the only reasonable parts of the
specification where this behaviour could be applied (the only other
possibility that I can see is the [[Prototype]] property of the Math
object).

The similar phrase, 'Object prototype object', occurs elsewhere in the
specification where the inheritance of used-defined properties would be
undoubtedly beneficial.
In other words, it appears to me that the word 'original' should have
been removed in a couple of places, but was overlooked.


It's quite a coincidence that only these two occurrences exist, and do
so in places where the lack of inheritance is more-or-less inconsequential .


Have to agree. That lends more weight to the consistency approach, as
opposed to creation of exceptions for reasons yet to be substantiated.

Thanks for the reasoned and reasonable response.

../rh

Feb 19 '06 #30

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

25
9126
by: Sabyasachi Basu | last post by:
While trying to port some stuff from Unix to Windows, I encountered a strange behaviour of function macros with empty arguments. Here is a small snippet which illustrates the problem: #include <iostream> #include <string> using namespace std; #define B(X, Y) Y
7
23551
by: Newbie_sw2003 | last post by:
Where should I use them? I am giving you my understandings. Please correct me if I am wrong: MACRO: e.g.:#define ref-name 99 The code is substituted by the MACRO ref-name. So no overhead. Execution is faster. Where will it be stotred?(Is it in bss/stack/?) FUNCTION:
0
8797
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9309
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
9171
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
9010
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
7946
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
6629
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
4462
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
1
3156
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
3
2107
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.