• Log InLog In
  • Register
Liquid`
Team Liquid Liquipedia
EST 21:23
CET 03:23
KST 11:23
  • 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
RSL Season 3 - Playoffs Preview0RSL Season 3 - RO16 Groups C & D Preview0RSL Season 3 - RO16 Groups A & B Preview2TL.net Map Contest #21: Winners12Intel X Team Liquid Seoul event: Showmatches and Meet the Pros10
Community News
Weekly Cups (Nov 24-30): MaxPax, Clem, herO win2BGE Stara Zagora 2026 announced15[BSL21] Ro.16 Group Stage (C->B->A->D)4Weekly Cups (Nov 17-23): Solar, MaxPax, Clem win3RSL Season 3: RO16 results & RO8 bracket13
StarCraft 2
General
Chinese SC2 server to reopen; live all-star event in Hangzhou Maestros of the Game: Live Finals Preview (RO4) BGE Stara Zagora 2026 announced Weekly Cups (Nov 24-30): MaxPax, Clem, herO win SC2 Proleague Discontinued; SKT, KT, SGK, CJ disband
Tourneys
RSL Offline FInals Sea Duckling Open (Global, Bronze-Diamond) $5,000+ WardiTV 2025 Championship Constellation Cup - Main Event - Stellar Fest RSL Revival: Season 3
Strategy
Custom Maps
Map Editor closed ?
External Content
Mutation # 502 Negative Reinforcement Mutation # 501 Price of Progress Mutation # 500 Fright night Mutation # 499 Chilling Adaptation
Brood War
General
BW General Discussion Which season is the best in ASL? Data analysis on 70 million replays BGH Auto Balance -> http://bghmmr.eu/ [ASL20] Ask the mapmakers — Drop your questions
Tourneys
[BSL21] RO16 Group D - Sunday 21:00 CET [BSL21] RO16 Group A - Saturday 21:00 CET [Megathread] Daily Proleagues [BSL21] RO16 Group B - Sunday 21:00 CET
Strategy
Current Meta Game Theory for Starcraft How to stay on top of macro? PvZ map balance
Other Games
General Games
ZeroSpace Megathread Stormgate/Frost Giant Megathread Nintendo Switch Thread The Perfect Game Path of Exile
Dota 2
Official 'what is Dota anymore' discussion
League of Legends
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
Mafia Game Mode Feedback/Ideas TL Mafia Community Thread
Community
General
Things Aren’t Peaceful in Palestine Russo-Ukrainian War Thread US Politics Mega-thread The Big Programming Thread Artificial Intelligence Thread
Fan Clubs
White-Ra Fan Club
Media & Entertainment
[Manga] One Piece Movie Discussion! Anime Discussion Thread
Sports
2024 - 2026 Football Thread Formula 1 Discussion NBA General Discussion
World Cup 2022
Tech Support
Computer Build, Upgrade & Buying Resource Thread
TL Community
Where to ask questions and add stream? The Automated Ban List
Blogs
James Bond movies ranking - pa…
Topin
Esports Earnings: Bigger Pri…
TrAiDoS
Thanks for the RSL
Hildegard
Saturation point
Uldridge
Customize Sidebar...

Website Feedback

Closed Threads



Active: 1776 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
Replay Cast
00:00
WardiTV Mondays #62
CranKy Ducklings122
LiquipediaDiscussion
[ Submit Event ]
Live Streams
Refresh
StarCraft 2
PiGStarcraft507
elazer 127
Nathanias 76
CosmosSc2 59
StarCraft: Brood War
Artosis 724
Larva 175
Bale 64
Noble 16
Dota 2
monkeys_forever870
NeuroSwarm78
League of Legends
JimRising 411
C9.Mang0324
Other Games
summit1g13593
tarik_tv5146
Day[9].tv787
shahzam540
Maynarde117
Mew2King101
ViBE44
ToD41
Organizations
Other Games
gamesdonequick920
StarCraft 2
Blizzard YouTube
StarCraft: Brood War
BSLTrovo
sctven
[ Show 15 non-featured ]
StarCraft 2
• Hupsaiya 65
• AfreecaTV YouTube
• intothetv
• Kozan
• IndyKCrew
• LaughNgamezSOOP
• Migwel
• sooper7s
StarCraft: Brood War
• RayReign 37
• BSLYoutube
• STPLYoutube
• ZZZeroYoutube
League of Legends
• Doublelift4830
Other Games
• imaqtpie1255
• Day9tv787
Upcoming Events
The PondCast
7h 37m
OSC
13h 37m
Demi vs Mixu
Nicoract vs TBD
Babymarine vs MindelVK
ForJumy vs TBD
Shameless vs Percival
Replay Cast
21h 37m
Korean StarCraft League
2 days
CranKy Ducklings
2 days
WardiTV 2025
2 days
SC Evo League
2 days
BSL 21
2 days
Sziky vs OyAji
Gypsy vs eOnzErG
OSC
2 days
Solar vs Creator
ByuN vs Gerald
Percival vs Babymarine
Moja vs Krystianer
EnDerr vs ForJumy
sebesdes vs Nicoract
Sparkling Tuna Cup
3 days
[ Show More ]
WardiTV 2025
3 days
OSC
3 days
BSL 21
3 days
Bonyth vs StRyKeR
Tarson vs Dandy
Replay Cast
4 days
Wardi Open
4 days
StarCraft2.fi
4 days
Monday Night Weeklies
4 days
Replay Cast
4 days
WardiTV 2025
5 days
StarCraft2.fi
5 days
PiGosaur Monday
5 days
StarCraft2.fi
6 days
Tenacious Turtle Tussle
6 days
Liquipedia Results

Completed

Proleague 2025-11-30
RSL Revival: Season 3
Light HT

Ongoing

C-Race Season 1
IPSL Winter 2025-26
KCM Race Survival 2025 Season 4
YSL S2
BSL Season 21
CSCL: Masked Kings S3
Slon Tour Season 2
Acropolis #4 - TS3
META Madness #9
SL Budapest Major 2025
ESL Impact League Season 8
BLAST Rivals Fall 2025
IEM Chengdu 2025
PGL Masters Bucharest 2025
Thunderpick World Champ.
CS Asia Championships 2025
ESL Pro League S22
StarSeries Fall 2025
FISSURE Playground #2

Upcoming

BSL 21 Non-Korean Championship
Acropolis #4
IPSL Spring 2026
Bellum Gens Elite Stara Zagora 2026
HSC XXVIII
RSL Offline Finals
WardiTV 2025
Kuram Kup
PGL Cluj-Napoca 2026
IEM Kraków 2026
BLAST Bounty Winter 2026
BLAST Bounty Winter Qual
eXTREMESLAND 2025
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 © 2025 TLnet. All Rights Reserved.