flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Heap > FASMG. access namespaces with index

Author
Thread Post new topic Reply to topic
ProMiNick



Joined: 24 Mar 2012
Posts: 89
Location: Russian Federation, Sochi
FASMG. access namespaces with index
Is it possible to provide access to namespace and its descendants throw its index?

general namespace and its descendants will have positive index from 0 for general up to 2^31.
local/blank namespaces will have same limit of negative indexes.

sintax of indexed access to namespaces could be "\Index.subitem" or "\index.\subindex".So "\0.anything" and just "anything" would mean the same.

_________________
I don`t like to refer by "you" to one person.
My soul requires acronim "thou" instead.
Post 12 Oct 2017, 07:00
View user's profile Send private message Send e-mail Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6676
Location: Kraków, Poland
One of my principal assumptions for the namespace features in fasmg was that they should be strongly relative - that is, you can embed an entire source in another namespace (for example to provide a separation from another one) and it should not be able to "notice" that its namespace is no longer the "true" root. All references have to be relative.
Post 12 Oct 2017, 07:29
View user's profile Send private message Visit poster's website Reply with quote
ProMiNick



Joined: 24 Mar 2012
Posts: 89
Location: Russian Federation, Sochi
What mean it should not be able to "notice"?
If sequence .. in current namespace points to somewhere else that mean it isn`t "true" root, is it?
Post 12 Oct 2017, 07:43
View user's profile Send private message Send e-mail Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6676
Location: Kraków, Poland

ProMiNick wrote:
What mean it should not be able to "notice"?
If sequence .. in current namespace points to somewhere else that mean it isn`t "true" root, is it?

The .. sequence refers to a subspace of current namespace. There is no way to refer to the "parent" namespace in fasmg. The encapsulation provides a sandbox that you cannot simply break. If you put two "programs" in two parallel namespaces, they cannot access each others namespace unless the container provides explicitly with a way to do so - this is by design.
Post 12 Oct 2017, 07:50
View user's profile Send private message Visit poster's website Reply with quote
ProMiNick



Joined: 24 Mar 2012
Posts: 89
Location: Russian Federation, Sochi
Ok, from child namespace it is impossible. From general namespace is it possible to declare tree of descendant namespaces with blank|local ones, so way that each child can acces whole that tree and each subelement of that tree?
Post 12 Oct 2017, 08:20
View user's profile Send private message Send e-mail Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6676
Location: Kraków, Poland

ProMiNick wrote:
Ok, from child namespace it is impossible. From general namespace is it possible to declare tree of descendant namespaces with blank|local ones, so way that each child can acces whole that tree and each subelement of that tree?

Yes, if you define a global symbol that is not redefined locally in any of the child namespaces, then you can use it access entire local tree from anywhere within that scope:

Code:
root = 'root'
namespace root
        a.b = '!'
        namespace a
                c = root.a.b
        end namespace
        display root.a.c
end namespace

Note that if you then take that entire source and embed it within another namespace, perhaps in a larger project, it is going to work the same, no matter that the "root" variable would be in a child namespace of some larger project. This is the "relativity" I mentioned.
Post 12 Oct 2017, 09:08
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 891
I wish C++ had namespaces like this (and disabled that ADL crap), would be much more useful than the current design. Razz
Post 12 Oct 2017, 11:00
View user's profile Send private message Reply with quote
TheRaven



Joined: 22 Apr 2008
Posts: 77
Location: U.S.A.
Not being argumentative, but C++ has the "using" directive for namespaces like the standard (std) library (not standard template library so don't go there). I think that you could possibly get namespaces to behave as the assembler (FAsm) example above using TypeDef stuff in C/C++ too, but C++ can be a hair pulling festival. Regardless, enjoy the fact that FAsm has namespace functionality --very awesome.

As far as ADL --never felt compelled to go that deep into C++, but have seen/read many posts concerning ADL and few were positive.

FAsmG is getting to a point where compiler design isn't simply realistic, but should become exponentially easier. Mapping HLL to LLL using simple macros (translation layer) is getting far more accessible with the FAsmG macro system. I would laugh my azz off about compilers being designed with macro (static HLL compilers may be the ones that become obsolete).

FAsmG.everywhere framework --LOL
it could, and probably will happen. I can't wait.
Post 09 Dec 2017, 22:35
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 891
ADL effectively "disables" namespaces for functions who have parameters taking types that are defined in the same namespace.

I find it a moronic feature because if you don't want the namespace, then don't use the namespace. ADL is the language telling you "I know what you want better than you, you probably don't want a namespace here you sucker, so I'll forcefully do it with no way for you to disable it, haha!"

With templates it's even worse since you don't even control what they get instantiated with (that's up to the user of them). You have to do ugly shit like (func)(args) when calling just to protect yourself against ADL.

ADL is a "feature" because idiots wanted to place their abuse of the shift operators into the std namespace and then act as if they're not in std namespace. So why couldn't they just place them in the fucking global namespace instead of this monstrosity?

Motto is simple: if you don't want namespaces, don't use namespaces. C++ committee can't seem to get this basic principle straight.
Post 10 Dec 2017, 12:40
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15302
Location: Bigweld Industries
I am a complete noob when it comes to C/C++ stuff.

So for someone who doesn't understand what it is all about, I visit the WP page here: https://en.wikipedia.org/wiki/Argument-dependent_name_lookup

And it tells me this code can't compile without ADL

Code:
#include <iostream>
#include <string>

int main()
{
    std::string str = "hello world";
    std::cout << str;
}

So how do I define operator<< and make it compile without ADL?

Note: This is a genuine question. I don't understand
Post 10 Dec 2017, 12:50
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 891
Place it in the global namespace (where main is). I mean, you call it without qualifying the namespace, that's the most sensible approach.

But no, they wanted to place it in std namespace while still having that compile without specifying the std namespace. So, why place it in a namespace again if you don't want it to be in a namespace?

When you place something in a namespace, you want it that way. ADL defeats the concept of namespaces because of their incompetency.

"But I don't want to pollute the global namespace", well guess what ADL does pollute the global lookup regardless and it is forced upon everybody. Sickening.

Consider:

Code:
namespace Awesome {
  struct S {};
  void superFunction(S*);
}

void superFunction(Awesome::S*);

int main()
{
  Awesome::Sblah = nullptr;
  superFunction(blah);
}

Fails to compile.

Because ADL brings into lookup Awesome::superFunction implicitly, defeating the whole purpose of the namespace. Clearly you meant to use the global superFunction since it's in same namespace as main, but nope. Language decided that since it takes an Awesome::S related parameter, you definitely want to use Awesome's namespace implicitly!!! "Ambiguity". ADL is a lookup pollution already.

You need to write something like (one of):

Code:
::superFunction(blah)
(superFunction)(blah)

and then it compiles. WTF?


Last edited by Furs on 10 Dec 2017, 14:56; edited 1 time in total
Post 10 Dec 2017, 14:44
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15302
Location: Bigweld Industries
If I define operator<< in the global namespace can I still use it for strings with cout and for numbers to left shift integers?
Post 10 Dec 2017, 14:55
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 891
Yeah, it's a binary operator so you can make it take those parameters, and since C++ supports overloading, it won't clash with other operator<< in the global namespace (unless they have the same type, but then, why would someone else use your namespace's type in operator<< in the first place? it's an ambiguity with ADL too and fails to compile anyway)

Well you can make operators also in the class itself which implicitly take the class as the "Left-hand side" of the binary operator -- no ADL is performed there, since ADL is only performed on "free" functions (functions not within a class).

You also see "best practices" idoms such as "don't put types and functions in the same namespace unless they are related and you want ADL to work". Basically a thing that wouldn't be needed if ADL wasn't a thing.

In other words, complicate your entire hierarchy because of some incompetent decision that they just won't deprecate or at least allow to selectively remove via a keyword or whatever. Whoever thought it up was braindead.

Might as well say "put functions associated with a type that you want called without qualifying their namespace into the global namespace" and simplify the whole language without cancer like ADL.
Post 10 Dec 2017, 14:57
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15302
Location: Bigweld Industries
I can see that sometimes ADL is useful, and sometimes it is annoying. I just hope the error messages are sufficiently detailed to explain to the poor (l)user what is causing the problem.


Last edited by revolution on 11 Dec 2017, 01:02; edited 1 time in total
Post 10 Dec 2017, 15:02
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 891
I don't know if it's ever useful since there's an alternative without any extra feature. But still, at least they need to give us a way to disable it.

Even better: make it disabled by default and ONLY enable it on functions you intentionally mark as "ADL lookup-able", for example, with a keyword on the function's declaration like "export" since that keyword already exists.
Post 10 Dec 2017, 15:05
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15302
Location: Bigweld Industries
What if I have another string library and it uses operator<< to rotate the string (or whatever alternate operation I need) instead of concatenating, do I define both in the global namespace?
Post 11 Dec 2017, 01:00
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 891
Yeah, there's no difference compared to ADL in this respect. It will work since functions can be overloaded based on types of arguments (of course, we do assume the library uses its own string type/class).

If it failed to overload in the global namespace for whatever reason, it would also give an ambiguous error with ADL, just as I shown in the example before (they both take the same type).

The difference is that with global namespace you get an error immediately to fix it (can't overload function with same type), with ADL you only get error when you actually end up using it because it finds two functions with the same signature so it's ambiguous to the compiler (so IMO it's even worse even for operators).
Post 11 Dec 2017, 12:55
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.