• Log InLog In
  • Register
Liquid`
Team Liquid Liquipedia
EDT 01:49
CEST 07:49
KST 14:49
  • Home
  • Forum
  • Calendar
  • Streams
  • Liquipedia
  • Features
  • Store
  • EPT
  • TL+
  • StarCraft 2
  • Brood War
  • Smash
  • Heroes
  • Counter-Strike
  • Overwatch
  • Liquibet
  • Fantasy StarCraft
  • TLPD
  • StarCraft 2
  • Brood War
  • Blogs
Forum Sidebar
Events/Features
News
Featured News
Code S Season 1 - RO8 Preview3[ASL21] Ro8 Preview Pt2: Progenitors8Code S Season 1 - RO12 Group A: Rogue, Percival, Solar, Zoun13[ASL21] Ro8 Preview Pt1: Inheritors16[ASL21] Ro16 Preview Pt2: All Star10
Community News
Maestros of The Game 2 announcement and schedule !7Weekly Cups (April 27-May 4): Clem takes triple0RSL Revival: Season 5 - Qualifiers and Main Event12Code S Season 1 (2026) - RO12 Results12026 GSL Season 1 Qualifiers25
StarCraft 2
General
Code S Season 1 - RO8 Preview Behind the Blue - Team Liquid History Book Weekly Cups (April 27-May 4): Clem takes triple Blizzard Classic Cup @ BlizzCon 2026 - $100k prize pool Code S Season 1 (2026) - RO12 Results
Tourneys
Maestros of The Game 2 announcement and schedule ! GSL Code S Season 1 (2026) Sea Duckling Open (Global, Bronze-Diamond) RSL Revival: Season 5 - Qualifiers and Main Event Sparkling Tuna Cup - Weekly Open Tournament
Strategy
Custom Maps
[D]RTS in all its shapes and glory <3 [A] Nemrods 1/4 players
External Content
Mutation # 524 Death and Taxes The PondCast: SC2 News & Results Mutation # 523 Firewall Mutation # 522 Flip My Base
Brood War
General
Do we have a pimpest plays list? BGH Auto Balance -> http://bghmmr.eu/ (Spoiler) Asl ro8 D winner interview BW General Discussion AI Question
Tourneys
[ASL21] Ro8 Day 4 Small VOD Thread 2.0 [BSL22] RO16 Group Stage - 02 - 10 May [ASL21] Ro8 Day 3
Strategy
Simple Questions, Simple Answers Fighting Spirit mining rates What's the deal with APM & what's its true value Any training maps people recommend?
Other Games
General Games
Path of Exile Nintendo Switch Thread Stormgate/Frost Giant Megathread OutLive 25 (RTS Game) Dawn of War IV
Dota 2
The Story of Wings Gaming
League of Legends
G2 just beat GenG in First stand
Heroes of the Storm
Simple Questions, Simple Answers Heroes of the Storm 2.0
Hearthstone
Deck construction bug Heroes of StarCraft mini-set
TL Mafia
Vanilla Mini Mafia Mafia Game Mode Feedback/Ideas TL Mafia Community Thread Five o'clock TL Mafia
Community
General
European Politico-economics QA Mega-thread US Politics Mega-thread The Letting Off Steam Thread Russo-Ukrainian War Thread 3D technology/software discussion
Fan Clubs
The IdrA Fan Club
Media & Entertainment
Anime Discussion Thread [Manga] One Piece [Req][Books] Good Fantasy/SciFi books
Sports
2024 - 2026 Football Thread McBoner: A hockey love story Formula 1 Discussion
World Cup 2022
Tech Support
streaming software Strange computer issues (software) [G] How to Block Livestream Ads
TL Community
The Automated Ban List
Blogs
How EEG Data Can Predict Gam…
TrAiDoS
ramps on octagon
StaticNine
Funny Nicknames
LUCKY_NOOB
Customize Sidebar...

Website Feedback

Closed Threads



Active: 1747 users

The Big Programming Thread - Page 486

Forum Index > General Forum
Post a Reply
Prev 1 484 485 486 487 488 1032 Next
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks.
Danglars
Profile Blog Joined August 2010
United States12133 Posts
May 31 2014 20:41 GMT
#9701
On June 01 2014 05:35 3FFA wrote:
Show nested quote +
On May 31 2014 17:16 spinesheath wrote:
On May 31 2014 09:23 FFGenerations wrote:
its fucking BRILLIANT tutorial

Make sure you don't read this one tutorial and then think you know everything. Learn from multiple sources and critically question each one. Internet tutorials are not something you should blindly depend upon. Neither is any other single source.

What about college/university?
Wouldn't that be a case of several teachers and several courses? In fact, that's probably the best place to learn to critically think for yourself between different approaches to solving the same problem/engineering the design.
Great armies come from happy zealots, and happy zealots come from California!
TL+ Member
Blisse
Profile Blog Joined July 2010
Canada3710 Posts
Last Edited: 2014-06-01 04:18:49
June 01 2014 03:45 GMT
#9702
You have to force yourself to do that - that's not really a result from being in higher education. Lots of students do the bare minimum.

Anecdote time, I was working with a classmate on our operating system and we gave him the job of writing a bit of the basic scheduler (basically an array of queues simulating priority queues). Instead of abstracting the queue structure into its own class and then writing his scheduler to use that, he just wrote the queue lookups as part of the scheduler functions. For example, to set a process as ready he would create a boolean Found variable and then iterate through his queue with a for loop until he found it and then had an if statement afterwards to check if Found or not... then he would do more processing, i.e. the real work. When I confronted him about it he said that he doesn't like C and he'll refactor it later, which he never did. There are so many stories like this from other programmers I know, it's a bit silly.

It might be just my perception of things, but I really find it weird that so many people don't actually like writing really clean code.


I digress a bit, but yeah, I don't really find tutorials that useful anymore. Very rarely do I actually see tutorials show me code that I'm like, damn that's a sick way of doing it (i.e. that way of designing your code is really good! I dont see any flaws). It's usually better to go through Github repos or sample code (and sometimes I don't even find good sample code). Tutorials though are really good at showing you one way, the author's way, of how a problem can be solved. It's really up to you to mash the tutorial with your programming knowledge to design the code decently.

For example, if you're making an Android project and you make a custom Control, like idk, a simple Calendar control or a custom Picker. Does that Picker need to be in your Android project? Or can you make it in a new independent project and link it in your build? Yes I know packages exist, but should your Calendar really be in the same codebase as your project? Sometimes yes, sometimes no, I don't think any tutorials actually talk about stuff like this.



As a side note, I'm just going to write a proper JSON-RPC library in C# instead. I've kept my Dictionary String -> Func in the meantime because in my opinion it has the clearest representation of how the structure behaves. It's a judgment call based on how much time I have and other more important parts of the project to do :d The dictionary doesn't change at run-time and it doesn't need to be updated so I don't see a problem with it at the moment other than it feels funky. Thanks for the responses though, I like the reflection route though that makes things very unclearly why they're being invoked (plus debugging's a bit harder), and I was going to do the factory route when I realized it was a bit of overengineering - I would have to write a lot of wrapper functions unnecessarily :3
There is no one like you in the universe.
spinesheath
Profile Blog Joined June 2009
Germany8679 Posts
June 01 2014 06:30 GMT
#9703
On June 01 2014 05:35 3FFA wrote:
Show nested quote +
On May 31 2014 17:16 spinesheath wrote:
On May 31 2014 09:23 FFGenerations wrote:
its fucking BRILLIANT tutorial

Make sure you don't read this one tutorial and then think you know everything. Learn from multiple sources and critically question each one. Internet tutorials are not something you should blindly depend upon. Neither is any other single source.

What about college/university?

Judging from my own experience with those, only good for getting a piece of paper that says you were there. You might have better luck with it. Certainly not trustworthy as a single source.
If you have a good reason to disagree with the above, please tell me. Thank you.
nunez
Profile Blog Joined February 2011
Norway4003 Posts
Last Edited: 2014-06-01 07:39:03
June 01 2014 07:07 GMT
#9704
have been working with sockets (reading advanced programming in unix environment, great book) for a while for an exam (didn't get any questions about it...). having some fun with the interface for my socket wrapper (in addition to your regular function calls). using some helper types to construct a one-two punch with chaining.

unlike your usual calls:

function name ( socket name 0, argument name 0, argument name 1, ... )
function name ( socket name 1, argument name 0, argument name 1, ... )
...

the syntax for the chained calls is:
function name [ socket name 0 ] ( argument name 0, argument name 1, ... )
                        [ socket name 1 ] ( argument name 0, argument name 1, ... )
                        ...

for a no chained send on socket 0 with 2 const buffers f.ex:
snd [ socket 0 ] ( const buffer 0, const buffer 1 )

they consist of an array subscript operator call to a const primer for desired function with the socket you wanna operate on... and then a function call operator with the arguments you wanna call it with on the returned functor. the returned functor finally returns a reference back to the const primer so you can chain.

int main(){
std::string m0("team "),m1("liquid\n"); //messages to send, implicitly cast to cbuf_t
std::vector<char> m2(m0.size()),m3(m1.size()),m4(m0.size()),m5(m1.size()); //buffers to receive on, implictly cast to buf_t
try{
sck_t<unix,dgram> s0,s1,s2; //std datagram unix socket
adr_t<unix> a0("sck_file"); //file to com through

bnd [s0](a0); //bind s0 to a0

con
[s1](a0)
[s2](a0)
; //'connect' (just sets default receiver since it's dgram) s1 and s2 to a0

snd
[s1](m0,m1)
[s2](m0,m1)
; //send m0 and m1 through s1, then m0 and m1 through s2

rcv
[s0](m2,m3,m4,m5)
; //receive all 4 messages on the respective buffers

ulnk(a0); //unlink the file
}catch(std::exception const& e){
std::cout<<e.what()<<std::endl;
}
std::cout<<m2.data()<<m3.data()<<m4.data()<<m5.data();
//prints
//team liquid
//team liquid
}


the types facilitating one-two punches look like so:
class snd_pt{ //primer type
public:
template<class sck_t>
class snd_et{ //executable type
friend class snd_pt; //primer class only one that can construct this
snd_pt const& r; //ref to primer
sck_t const& s;
snd_et(snd_pt const& r_,sck_t const& s_):r(r_),s(s_){}
public:
...
//executable calls
template<class cbuf_t>
snd_pt const& operator()(cbuf_t&& cbuf)const{ //only final call will return to outer scope
snd(s,std::forward<cbuf_t>(cbuf)); //call snd on socket with buf
return r; //return primer for chaining
}
template<class cbuf_t,class... cbuf_ts>
snd_pt const& operator()(cbuf_t&& cbuf,cbuf_ts&&... cbufs)const{ //call then recurse
(*this)(std::forward<cbuf_t>(cbuf));
(*this)(std::forward<cbuf_ts>(cbufs)...);
}
};
//primer call
template<class sck_t>
decltype(auto)
operator[](sck_t const& s)const{
return snd_et<sck_t>(*this,s);
}
};

const snd_pt snd; //make a const primer ready to use


it has bugs (const& binds to temporary f.ex), is a lot of hassle and has a lot of caveats (these types exist only to facilitate the syntax within a given scope for a given thread) and some overhead(not a lot i think, nothing is being copied). however (i hope) i can generalize it pretty easily by templating on function signatures and taking function pointer in constructor instead of typing explicitly, and the syntax is so god damned cute and expressive (in my eyes) that i wanted to show.

i'll make a better post on wrapper when i'm done, hopefully in a couple of weeks.
conspired against by a confederacy of dunces.
spinesheath
Profile Blog Joined June 2009
Germany8679 Posts
Last Edited: 2014-06-01 07:20:09
June 01 2014 07:18 GMT
#9705
You really should stop using abbreviations like that.
Source: every single book/article/talk on clean code and me having to decode your abbreviation before I can think about the meaning.
If you have a good reason to disagree with the above, please tell me. Thank you.
nunez
Profile Blog Joined February 2011
Norway4003 Posts
Last Edited: 2014-06-01 07:35:43
June 01 2014 07:22 GMT
#9706
haha, i should, but i write for my own sadistic pleasure.

however i think con,rcv,snd,bnd,lsn,acc,sck_t,adr_t,buf_t,cbuf_t are fine when it's in the context of a socket wrapper.
it's unambiguous... if you have to spend time decoding it you probably couldn't give much critique beyond it being too terse (which is valid ofc). i will squeeze a vowel in there for next time.

the helper types are impossible, it's a quick sketch (but i doubt i'll deviate from my terseness).

regardless the piece de resistance is the syntax of the socket calls.
conspired against by a confederacy of dunces.
Blisse
Profile Blog Joined July 2010
Canada3710 Posts
Last Edited: 2014-06-01 07:34:45
June 01 2014 07:34 GMT
#9707
sadistic pleasure lolol :3

i have been doing sockets too! they're really fun

yeah, your code is impossible to read :d
There is no one like you in the universe.
nunez
Profile Blog Joined February 2011
Norway4003 Posts
June 01 2014 07:36 GMT
#9708
even the first blob? what's so hard about the first blob?
conspired against by a confederacy of dunces.
spinesheath
Profile Blog Joined June 2009
Germany8679 Posts
June 01 2014 07:41 GMT
#9709
It doesn't really matter if you know the context or not. It's unnecessary mind mapping of abbreviations and words. It makes it harder for people less familiar with the context. It increases the risk of mixing up the names of two things.
If you have a good reason to disagree with the above, please tell me. Thank you.
nunez
Profile Blog Joined February 2011
Norway4003 Posts
Last Edited: 2014-06-01 08:40:24
June 01 2014 08:11 GMT
#9710
it matters if you know the context, the 4 types and 6 functions have 1 to 1 (1 to 2, size_t and void* / const void* in the case of buf_t and cbuf_t) mappings with your run-of-the-mill socket shenanigans. the interfaces are simpler, i cut out functionality or hid it with default behaviour (protocol, getting adresses of senders, backlog) and abstracted (adr_t,buf_t) and the socket is no longer an ambiguous int, but an explicit socket_t<socket_domain,socket_type> (so many redundant vowels and repetitions) [it implicitly converts to an int].

it's completely unambiguous in 3 letters and a postfix underscore t for types and prefix c for const, there is no way you could mix up the names. it's literally 12 things - 4 types, 2 parameters, 6 functions. i could name over 15 thousand things with 3 letters(no repeated letters, granted some ambiguity)!

i agree it makes it harder to understand for ppl who're not familiar enough with context (hence comments), and even if you are you might still think it's heinous to look at and harder to read. whether or not it's unnecessary depends on context as well. for me it saves time and brings me great pleasure.

regardless the function call syntax would be the same, and your fdbck is duly noted.
conspired against by a confederacy of dunces.
Blisse
Profile Blog Joined July 2010
Canada3710 Posts
Last Edited: 2014-06-01 08:58:02
June 01 2014 08:54 GMT
#9711
your code's not THAT bad, it's definitely readable in terms of logic and design, and syntactically if i took the time to map all the shortened names to the full words.

spines's point is just that you have to do a bit of extra work to convert the abbreviation to its full form, which makes things a chore to read.

you usually don't want people reading your code to do more work in terms of figuring out function and variable names on top of already debugging the logic. hence the reason it's suggested to not use abbreviations for variable names. if your short term memory can hold 7 objects, holding the abbreviation to real word takes up a valuable space. if you've embedded the variable into medium long term memory then it's not such a big deal for you, but new people jumping in won't have the best time.

I'm sure you already knew that though so there's really no problem here.
There is no one like you in the universe.
nunez
Profile Blog Joined February 2011
Norway4003 Posts
Last Edited: 2014-06-01 10:20:14
June 01 2014 10:13 GMT
#9712
hehe, yes, and i agree that it would be hard, and ofc there is no problem, i appreciate the feedback. i have no qualms adapting to whateever is the agreed upon standard when i am coding for or with other people.

however! this is a socket wrapper... it is providing another interface for sys/socket.h through simplification, assumption, abstraction, different error handling and ofc the chaining syntax;

namespace SCK vs global namespace, uses prefixes like AF_ SOCK_ etc...
sck_t<domain,type> s; vs int fd=socket(domain,type,0);
adr_t<domain> vs sockaddr_** (un for AF_UNIX, in for AF_INET etc)
buf_t / cbuf_t vs void*, size_t / const void*, size_t

unix vs AF_UNIX (a socket domain)
dgram vs SOCK_DGRAM (a socket type)

acc - accept
rcv - recv
snd - send
bnd - bind
con - connect
lsn - listen

if you can't effortlessly guess what functions acc, con and lsn with supplied arguments and their types does in the context of a socket wrapper, or start mixing up types or functions, your initial feedback can only ever amount to 'i like the code to look more like this'.

the confusion does not stem from the abbreviation, it stems from your lack of familiarity with the context! you don't know the rules of the game, and the names of the pieces won't teach you. even if acc was named the entire contents of 'man 2 accept' in camel case you would still have 0 clue how to use it for something useful except making the kernel produce error codes.
conspired against by a confederacy of dunces.
Prillan
Profile Joined August 2011
Sweden350 Posts
June 01 2014 10:19 GMT
#9713
On June 01 2014 19:13 nunez wrote:
hehe, yes, and i agree that it would be hard.

but this is a socket wrapper... it is providing another interface for sys/socket.h through simplification, assumption, abstraction, different error handling and ofc the chaining syntax;

namespace SCK vs global namespace, uses prefixes like AF_ SOCK_ etc...
sck_t<domain,type> s; vs int fd=socket(domain,type,0);
adr_t<domain> vs sockaddr_** (un for AF_UNIX, in for AF_INET etc)
buf_t / cbuf_t vs void*, size_t / const void*, size_t

unix vs AF_UNIX (a socket domain)
dgram vs SOCK_DGRAM (a socket type)

acc - accept
rcv - recv
snd - send
bnd - bind
con - connect
lsn - listen

if you can't effortlessly guess what functions acc, con and lsn with supplied arguments and their types does in the context of a socket wrapper, or start mixing up types or functions, your initial feedback can only ever amount to 'i like the code to look more like this', which i do appreciate, but...

the confusion does not stem from the abbreviation, it stems from your lack of familiarity with the context! you don't know the rules of the game, and the names of the pieces won't teach you. even if acc was named the entire contents of 'man 2 accept' in camel case you would still have 0 clue how to use it for something useful except making the kernel produce error codes.

Of course we understand what the abbreviations stand for, that's not the problem. The problem is that it makes the brain take a detour when reading the code.
TheBB's sidekick, aligulac.com | "Reality is frequently inaccurate." - Douglas Adams
netherh
Profile Blog Joined November 2011
United Kingdom333 Posts
June 01 2014 10:28 GMT
#9714
On June 01 2014 17:11 nunez wrote:
it matters if you know the context, the 4 types and 6 functions have 1 to 1 (1 to 2, size_t and void* / const void* in the case of buf_t and cbuf_t) mappings with your run-of-the-mill socket shenanigans. the interfaces are simpler, i cut out functionality or hid it with default behaviour (protocol, getting adresses of senders, backlog) and abstracted (adr_t,buf_t) and the socket is no longer an ambiguous int, but an explicit socket_t<socket_domain,socket_type> (so many redundant vowels and repetitions) [it implicitly converts to an int].

it's completely unambiguous in 3 letters and a postfix underscore t for types and prefix c for const, there is no way you could mix up the names. it's literally 12 things - 4 types, 2 parameters, 6 functions. i could name over 15 thousand things with 3 letters(no repeated letters, granted some ambiguity)!

i agree it makes it harder to understand for ppl who're not familiar enough with context (hence comments), and even if you are you might still think it's heinous to look at and harder to read. whether or not it's unnecessary depends on context as well. for me it saves time and brings me great pleasure.

regardless the function call syntax would be the same, and your fdbck is duly noted.


People generally use an auto-completion tool if they want to save typing. That way you can give things long unambiguous names that make it immediately apparent to everyone what the type is, and still only have to type three letters!

Your current system messes with auto-completion too, because when I type "soc" expecting to find a socket, or "add" expecting to find address, I don't get the right type.

And what does fdbck stand for? Google indicates something to do with the Netherlands, but who knows? All I know is it's not a type because it doesn't have _t.
nunez
Profile Blog Joined February 2011
Norway4003 Posts
Last Edited: 2014-06-01 10:56:34
June 01 2014 10:50 GMT
#9715
i interpreted both blisse and spine as having trouble with the abbreviations to the point where they would have to invest to understand code.

the brain takes a detour? the brain? a detour? luckily the brain can map several words to the same concept, and it doesn't have to linearly jump from the shortest word to the longest word to do it, especially when both words unambiguously conveys the same semantics in the given context! if you don't immediately understand what con means, when it conveys the semantics even clearer through the type of the argument and the return type, it is not the name that is lacking, it's your ability to parse the context.

the shorter the word the faster i can read it and type it, without having to engage in a slow and error prone visual feedback process with the computer screen.

bloody conformists! ;>
conspired against by a confederacy of dunces.
Prillan
Profile Joined August 2011
Sweden350 Posts
June 01 2014 10:58 GMT
#9716
On June 01 2014 19:50 nunez wrote:
i interpreted both blisse and spine as having trouble with the abbreviations to the point where they would have to invest to understand code.

the brain takes a detour? the brain? a detour? luckily the brain can map several words to the same concept, and it doesn't have to linearly jump from the shortest word to the longest word to do it, especially when both words unambiguously conveys the same semantics in the given context! if you don't immediately understand what acc means, when it conveys the semantics even clearer through the type of the argument and the return type, it is not the name that is lacking, it's your ability to parse the context i think.

the shorter the word the faster i can read it and type it, without having to engage in a slow and error prone visual feedback process with the computer screen.

bloody conformists! ;>

Yes.

We haven't seen the abbreviations as much as you have so the mapping in our brains are not yet there. This means that we have to map the words consciously, hence it will take longer to read and understand.

the shorter the word the faster i can read it and type it

No, when the brain is trained to read words it doesn't read each letter individually but rather the entire word at the same time. The difference between adr and address is negligible.


All this said, I too use abbreviations in my private code since I'm the only one expected to read it.
TheBB's sidekick, aligulac.com | "Reality is frequently inaccurate." - Douglas Adams
Rollin
Profile Joined March 2011
Australia1552 Posts
June 01 2014 11:00 GMT
#9717
On June 01 2014 19:28 netherh wrote:
Show nested quote +
On June 01 2014 17:11 nunez wrote:
it matters if you know the context, the 4 types and 6 functions have 1 to 1 (1 to 2, size_t and void* / const void* in the case of buf_t and cbuf_t) mappings with your run-of-the-mill socket shenanigans. the interfaces are simpler, i cut out functionality or hid it with default behaviour (protocol, getting adresses of senders, backlog) and abstracted (adr_t,buf_t) and the socket is no longer an ambiguous int, but an explicit socket_t<socket_domain,socket_type> (so many redundant vowels and repetitions) [it implicitly converts to an int].

it's completely unambiguous in 3 letters and a postfix underscore t for types and prefix c for const, there is no way you could mix up the names. it's literally 12 things - 4 types, 2 parameters, 6 functions. i could name over 15 thousand things with 3 letters(no repeated letters, granted some ambiguity)!

i agree it makes it harder to understand for ppl who're not familiar enough with context (hence comments), and even if you are you might still think it's heinous to look at and harder to read. whether or not it's unnecessary depends on context as well. for me it saves time and brings me great pleasure.

regardless the function call syntax would be the same, and your fdbck is duly noted.


People generally use an auto-completion tool if they want to save typing. That way you can give things long unambiguous names that make it immediately apparent to everyone what the type is, and still only have to type three letters!

Your current system messes with auto-completion too, because when I type "soc" expecting to find a socket, or "add" expecting to find address, I don't get the right type.

And what does fdbck stand for? Google indicates something to do with the Netherlands, but who knows? All I know is it's not a type because it doesn't have _t.

I'm guessing feedback with no vowels (I think he was being sassy).
Throw off those chains of reason, and your prison disappears. | Check your posting frequency timeline: http://www.teamliquid.net/mytlnet/post_activity_img.php
netherh
Profile Blog Joined November 2011
United Kingdom333 Posts
Last Edited: 2014-06-01 11:09:52
June 01 2014 11:05 GMT
#9718
On June 01 2014 19:50 nunez wrote:
i interpreted both blisse and spine as having trouble with the abbreviations to the point where they would have to invest to understand code.

the brain takes a detour? the brain? a detour? luckily the brain can map several words to the same concept, and it doesn't have to linearly jump from the shortest word to the longest word to do it, especially when both words unambiguously conveys the same semantics in the given context! if you don't immediately understand what acc means, when it conveys the semantics even clearer through the type of the argument and the return type, it is not the name that is lacking, it's your ability to parse the context i think.

the shorter the word the faster i can read it and type it, without having to engage in a slow and error prone visual feedback process with the computer screen.

bloody conformists! ;>


To be blunt, your whole code snippet seems like you're trying to save yourself from typing connect twice in a row. But you're doing 100x the typing you'll ever save just to get it set up. (And then it needs to be maintained...)

Anyway, I do feel you could do the same thing with functions that take tuples as arguments, instead of the "primer" types and operator[]:


connect({s1, a0}, {s2, a0});
send({s1, {m0, m1}}, {s2, {m0, m1}});


Edit: I don't actually know if you can nest initializer lists like that, but you could probably just flatten it into {s1, m0, m1} if necessary.
nunez
Profile Blog Joined February 2011
Norway4003 Posts
Last Edited: 2014-06-01 14:14:31
June 01 2014 11:25 GMT
#9719
@prill
yes, if you are not familiar enough with the context then it would take a negligible effort to connect the dots, which would then dwarfed by the effort you'd have to make to actually understand the semantics of the call...

if you are familliar with the context then the effort it would take would be negligible even in relation to the previous negligible effort, followed by an equally negligible boost in reading and writing speed and more expressive code. it is unambiguous and crystal clear, there is no confusion. maybe you think it's ugly, i wouldn't blame you, it's a pet project. i'm glad to hear you're a fellow abbreviator.

imagine if you had to write receive instead of recv... oh my god, the humanity.

@rollin
haha, i think netherth was being sassy too!

@nerterth
initializer lists could work as well (and tuples also great), with the added bonus that you could pass sets to operators that only take one arg. it does look clunkier and less expressive though. is {s0,a0} being connected with {s1,a1} f.ex? what was cute about the syntax was that the socket was distinctly separated from the arguments it was gonna work on. it's expressive. chaining operators should be very familiar c++...

std::cout<<"hello world"<<std::endl;

the reason it's tricky is because i implemented it tricky (a fast sketch). you could make it very easy and then rely on the user to be a good boy too. also like i said i don't think would be that difficult to generalize it into two types, and resolve the types in the function call operator from the type of the supplied function pointer. it's a personal project, if i get a better idea i just chuck it out.

it'll prolly be like tops 40 lines of code for a general type.

conspired against by a confederacy of dunces.
nunez
Profile Blog Joined February 2011
Norway4003 Posts
Last Edited: 2014-06-01 15:16:15
June 01 2014 14:14 GMT
#9720
@nerterth
here's the more general version of the one-two punch of array subscript operator and function call operator, sc2 themed.

the infestor_t is the primer and the fungaled_t is the executor.
the fungal_t (i hope) can't be moved from callsite, so hard to misuse.
since it inherits the damage_t calls to function call operators will resolve to the damage_t instead.
there's no chaining here, but it will be easy to add and is "totally safe" since we are not allowed to move from callsite anymore (and the infestor_t wont go out of scope).

the rest is just added to produce the contrived example.

~20 loc by my count (way spread out here, only infestor_t is the relevant type). can inject behaviour through template parameter (here damage_t) and through the type of unit the array subscript operator is called with (here unit_t). like in this example the template parameter can also be dependant on the latter (get race and armor).

maybe ~20 more to specialize behaviour for sockets or sth.

//unit race modifier, higher is better
enum race_t{zerg,terran,protoss};
//unit armor modifier, higher is better
enum armor_t{light,medium,heavy};

//unit type, all information in type
template<race_t race,armor_t armor> struct unit_t{};

//shape template
template<class> class damage_t;

//damage class calculates the damage done by a fungal over intervals of time
template<race_t race,armor_t armor>
class damage_t<unit_t<race,armor>>{
//max damage per time unit
const int max_damage=5;
public:
//all info in type, don't need no variable
damage_t(unit_t<race,armor>const&){}
//calculate damage for over given interval
int operator()(int interval_j){
return (max_damage-race-armor)*interval_j;
}
template<class... int_ts>
int operator()(int interval_0,int_ts... intervals){
//sum all the damages over intervals
int total_damage=(*this)(interval_0)+(*this)(intervals...);
return total_damage;
}
};

//infestor_t catches a unit_t through its array subscript operator and entangles him in a fungal_t.
//it roots unit to callsite, while wrapping him damage_t allowing to deal damage over time intervals through
//damage_t function call operator.
//have to decay unit_t so we don't instantiate unspecified damage_t<unit_t&> or whatevs instead of damage_t<unit_t>.

template<template<class> class damage_t>
class infestor_t{
public:
template<class unit_t>
class fungaled_t:public damage_t<std::decay_t<unit_t>>{
//only the infestor_t can create a fungaled_t
friend class infestor_t;

//the fungal being casted on unit when array subscript operator is called
explicit fungaled_t(unit_t&& unit):damage_t<std::decay_t<unit_t>>(std::forward<unit_t>(unit)){}

//land fungal and lock unit_t in place at the callsite when we return through return value optimization/cpy elision
fungaled_t(fungaled_t&& fungaled):damage_t<std::decay_t<unit_t>>(std::move(fungaled)){}

public:
//fungaled_t literally can not be moved or copied besides when being returned and fungaled at callsite.
fungaled_t(fungaled_t const&)=delete;
fungaled_t& operator=(fungaled_t const&)=delete;
fungaled_t& operator=(fungaled_t&&)=delete;
};

//unit walks into our array subscript operator
template<class unit_t>
decltype(auto)
operator[](unit_t&& unit)const{
//cast fungal, it "lands" at call site after we return.
return fungaled_t<unit_t>(std::forward<unit_t>(unit));
}

};

int main(){
try{
infestor_t<damage_t> infestor;

typedef unit_t<zerg,light> light_zerg_t;
light_zerg_t zergling; //weakest unit in the game
std::cout<<infestor[zergling](1,1,1)<<std::endl; //does (5)*(1+1+1)=15 damage.

typedef unit_t<protoss,heavy> heavy_protoss_t;
heavy_protoss_t sentry; //strongest unit in the game
std::cout<<infestor[sentry](1,1,1)<<std::endl; //does (5-2-2)*(1+1+1)=3 damage;

auto cheat_sentry=infestor[sentry]; //compiler error, not allowed to move or copy from callsite!

}catch(std::exception const& e){
std::cout<<e.what()<<std::endl;
}
}

sry formatting here failed. i don't think it's that hard to make a skinny framework to facilitate it, but doesn't mean it's any good ofc. it lets you write socket operations in a tiny, tiny EDSL, which is cool, at the cost of the awkwardness in producing it.
conspired against by a confederacy of dunces.
Prev 1 484 485 486 487 488 1032 Next
Please log in or register to reply.
Live Events Refresh
Next event in 4h 11m
[ Submit Event ]
Live Streams
Refresh
StarCraft 2
WinterStarcraft431
Nina 134
ProTech117
-ZergGirl 68
StarCraft: Brood War
GuemChi 6199
Mind 613
Snow 136
yabsab 71
910 66
JulyZerg 58
Nal_rA 36
SilentControl 36
Noble 35
Bale 10
[ Show more ]
ZergMaN 9
Icarus 6
Dota 2
NeuroSwarm115
Counter-Strike
m0e_tv687
Super Smash Bros
hungrybox287
Other Games
C9.Mang0550
monkeys_forever332
Sick104
Mew2King86
Organizations
Other Games
gamesdonequick873
BasetradeTV315
StarCraft: Brood War
UltimateBattle 67
StarCraft 2
Blizzard YouTube
StarCraft: Brood War
BSLTrovo
[ Show 12 non-featured ]
StarCraft 2
• AfreecaTV YouTube
• intothetv
• Kozan
• IndyKCrew
• LaughNgamezSOOP
• Migwel
• sooper7s
StarCraft: Brood War
• BSLYoutube
• STPLYoutube
• ZZZeroYoutube
League of Legends
• Nemesis2951
• Stunt512
Upcoming Events
Escore
4h 11m
The PondCast
4h 11m
WardiTV Invitational
5h 11m
Zoun vs Ryung
Lambo vs ShoWTimE
Big Brain Bouts
10h 11m
Fjant vs Bly
Serral vs Shameless
OSC
16h 11m
Replay Cast
18h 11m
CranKy Ducklings
1d 4h
RSL Revival
1d 4h
SHIN vs Bunny
ByuN vs Shameless
WardiTV Invitational
1d 5h
Krystianer vs TriGGeR
Cure vs Rogue
uThermal 2v2 Circuit
1d 9h
[ Show More ]
BSL
1d 13h
Artosis vs TerrOr
spx vs StRyKeR
Replay Cast
1d 18h
Sparkling Tuna Cup
2 days
RSL Revival
2 days
Cure vs Zoun
Clem vs Lambo
WardiTV Invitational
2 days
BSL
2 days
Dewalt vs DragOn
Aether vs Jimin
GSL
3 days
Afreeca Starleague
3 days
Soma vs Leta
Wardi Open
3 days
Monday Night Weeklies
3 days
OSC
3 days
CranKy Ducklings
4 days
Afreeca Starleague
4 days
Light vs Flash
Replay Cast
5 days
Replay Cast
5 days
The PondCast
6 days
Replay Cast
6 days
Liquipedia Results

Completed

Proleague 2026-05-05
WardiTV TLMC #16
Nations Cup 2026

Ongoing

BSL Season 22
ASL Season 21
CSL 2026 SPRING (S20)
IPSL Spring 2026
KCM Race Survival 2026 Season 2
Acropolis #4
Escore Tournament S2: W6
SCTL 2026 Spring
RSL Revival: Season 5
2026 GSL S1
BLAST Rivals Spring 2026
IEM Rio 2026
PGL Bucharest 2026
Stake Ranked Episode 1
BLAST Open Spring 2026
ESL Pro League S23 Finals
ESL Pro League S23 Stage 1&2

Upcoming

KK 2v2 League Season 1
BSL 22 Non-Korean Championship
YSL S3
Escore Tournament S2: W7
Escore Tournament S2: W8
CSLAN 4
Kung Fu Cup 2026 Grand Finals
HSC XXIX
uThermal 2v2 2026 Main Event
Maestros of the Game 2
2026 GSL S2
BLAST Bounty Summer 2026: Closed Qualifier
Stake Ranked Episode 3
XSE Pro League 2026
IEM Cologne Major 2026
Stake Ranked Episode 2
CS Asia Championships 2026
IEM Atlanta 2026
Asian Champions League 2026
PGL Astana 2026
TLPD

1. ByuN
2. TY
3. Dark
4. Solar
5. Stats
6. Nerchio
7. sOs
8. soO
9. INnoVation
10. Elazer
1. Rain
2. Flash
3. EffOrt
4. Last
5. Bisu
6. Soulkey
7. Mini
8. Sharp
Sidebar Settings...

Advertising | Privacy Policy | Terms Of Use | Contact Us

Original banner artwork: Jim Warren
The contents of this webpage are copyright © 2026 TLnet. All Rights Reserved.